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

Question

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

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

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

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

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

Answer 1

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

     Pic 1

     Pic 2

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

Answer 2

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

Магистраль является вашим основным источником. Он содержит «последний и самый лучший» код и рассчитан на будущее. Обычно это не всегда стабильно.

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

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

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

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

Answer 3

Моей первой рекомендацией было бы прочитать Source Control HOWTO Эрика Синка - в частности, ветви и ветви объединения главы.

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

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

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

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

Удачи!

Answer 4

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