Эффективный совет стратегии ветвления TFS

Question

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

Наш код состоит из одной большой части программного обеспечения и нескольких других сопутствующих бизнес-приложений.

У нас есть четыре среды, которые мы постоянно поддерживаем, а наш «конвейер» - это так.

• Разработчик действительно работает локально.
• Выводит код в среду разработки (так что мы все можем посмотреть на код, посмотреть, насколько он интегрируется в среду и т. Д.)
• Когда тестирование готово, мы нажимаем «Test» - это код, который имеет были одобрены для перемещения по трубопроводу, и поэтому среда намного более стабильна, чем «Разработка».
• Далее мы передаем его на сервер UAT, который по существу является имитацией сервера в реальном времени, как можно более стабильным и представителем live release . Код, одобренный для перехода сюда, не является частым.
• И наконец, производственные условия.

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

ГЛАВНАЯ -> ЭТАП -> TEST -> DEV

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

От ветви dev мы отрываем наши локальные ветви, и любые исправления поступают непосредственно из ветви UAT.

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

Любая помощь очень ценится.

Answer 1

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

   Main 
      |  | 
      |  | 
      DEV Release 

развития будет происходить в отрасли DEV, когда он будет готов к UAT мы объединяем его в MAIN, а затем создать филиал релиза , Вы можете использовать ветвь DEV для следующей версии разработки на этом этапе, и все исправления ошибок для текущей версии будут теперь происходить в ветви релиза. Отделение Release также будет использоваться для развертывания PROD.

Что касается того, будет ли это работать для вас или нет, это будет зависеть от ваших конкретных потребностей, но 80% проектов, с которыми я работал, использует вышеупомянутую стратегию ветвления.

Answer 2

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

Но если ситуация требует, не ускользает. Если вы не просмотрели документ branching strategy от ALM-рейнджеров для TFS, пожалуйста, посмотрите. Это должно помочь вам.

Я думаю, что стратегия, за которой вы следите, не является линейным ветвлением, а скорее тем, что изображено ниже. В более сложном корпоративном программном обеспечении стратегия ветвления сводится к этому.