Стратегии ветвления и слияния

Мне поручено разработать стратегию для ветвления, слияния и выпуска в течение следующих 6 месяцев.

Усложнение происходит из-за того, что мы будем запускать несколько проектов с разными изменениями кода и разными датами выпуска, но примерно с теми же датами начала разработки.

В настоящее время мы используем VSS для управления кодом, но знаем, что он, вероятно, вызовет некоторые проблемы и будет перенесен на TFS до начала новой разработки.

Какие стратегии я должен использовать и какие вещи следует рассматривать перед установкой плана?

Извините, если это неясно, не стесняйтесь задавать вопросы, и я при необходимости обновляю дополнительную информацию.

Ответ 1

Это единственный лучший шаблон управления исходным кодом, с которым я столкнулся. Это подчеркивает важность того, чтобы багажник был свободен от мусора (в багажнике нет мусора). Разработка должна выполняться в ветвях разработки, и регулярные слияния (после того, как код был протестирован) должны быть возвращены в ствол (Рис. 1), но модель также позволяет исправлять исходный код, пока он находится в стадии разработки (Рис. 2). Я определенно рекомендую прочитать пост полностью, чтобы полностью понять.

     Pic 1

     Pic 2

Изменить: фотографии определенно путают без слов. Я мог бы объяснить, но я в основном буду копировать оригинального автора. Сказав это, я, вероятно, должен был выбрать лучшую картину для описания процесса слияния, так что, надеюсь, это поможет. Тем не менее, я бы порекомендовал прочитать пост:

Ответ 2

Самый простой и обычный способ, которым я видел ветвящиеся работы, - это два предпосылки. Багажник и релиз. Я думаю, что это известно как философия "Нестабильная магистральная, стабильная ветвь".

Магистральный - ваш основной источник. Это содержит "последний и самый большой" код и выглядит перспективным. Обычно он не всегда стабилен.

Release - это ассоциация "один-ко-многим" со стволом. Существует один багажник, но много выпусков, которые происходят из ствола. Релизы обычно начинаются с ветки соединительной линии, как только достигнут конкретный функциональный рубеж, поэтому "единственные" вещи, оставшиеся для конкретного развертывания, должны быть просто исправлены. Затем вы вставляете соединительную линию, даете ей ярлык (например, 1.6 Release - это наша последняя версия Release), создавайте и отправляйте выпуск в QA. В этот момент мы также нажимаем номер версии (обычно младший номер) туловища, чтобы убедиться, что у нас нет двух выпусков с одинаковым номером.

Затем вы начинаете цикл тестирования в своей ветки релиза. Когда будет проведено достаточное тестирование, вы примените исправления ошибок к ветки релиза, объедините их обратно в магистраль (чтобы обеспечить исправление ошибок!), А затем повторно выпустите сборку ветки. Этот цикл с QA продолжается до тех пор, пока вы не будете счастливы, и выпуск, наконец, будет предоставлен клиенту (-ам). Любые отчеты об ошибках от клиента (ов), которые являются точными (то есть они являются ошибкой!), Запускают другой цикл QA с соответствующей веткой.

Когда вы создаете будущие выпуски, рекомендуется также попытаться переместить более старых клиентов на более новые ветки, чтобы уменьшить потенциальное количество ветвей, которые могут возникнуть для исправления ошибок.

Используя эту технику, вы можете развернуть решения, используя вашу технологию, для различных клиентов, которым требуются разные уровни обслуживания (начиная с наименьшего первого), вы можете изолировать существующие развертывания от "опасного" нового кода в багажнике и наихудшего слияния сценарий - одна ветвь.

Ответ 3

Моя первая рекомендация - прочитать Eric Sink Source HOWTO - в частности branches и разделение ветвей.

У нас есть 3 контейнера - DEV, MAIN и RELEASE для нашей работы. MAIN содержит весь наш "готовый к выпуску" код, и мы склонны считать его "стабильным". DEV/Iteration (или DEV/Feature, или DEV/RiskyFeatureThatMightBreakSomeoneElse) являются ветвями от MAIN и объединяются, когда Iteration/Feature готова продвигаться дальше среды DEV. У нас также есть сборки TFS, созданные из ветки DEV/Iteration и MAIN.

Наш контейнер RELEASE содержит пронумерованные выпуски (похожие на контейнер "теги", используемый во многих репозиториях Subversion). Мы просто берем ветку из MAIN каждый раз - мне нравится говорить, что мы "разрезаем" ветку RELEASE, чтобы обозначить это, не должно быть много активности, которая происходит после завершения слияния.

Что касается VSS- > TFS - Microsoft поддерживает путь обновления, который должен сохранять историю версий, но если вам не нужна эта история, я бы просто получил последнюю версию VSS, проверил ее в TFS и архивировал репозиторий VSS.

Один последний отзыв - ознакомьтесь с членами вашей команды с контролем источника. Они должны понимать ветвление и слияние, иначе вы будете делать много работы по очистке:).

Удачи!

Ответ 4

Книга подрывной книги описывает некоторые общие шаблоны ветвления. Возможно, вы также можете применить их к TFS.