Рекомендации по эффективной стратегии ветвления TFS

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

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

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

  • Разработчик работает локально.
  • Отправляет код в среду «Разработки» (чтобы мы все могли посмотреть на код, посмотреть, насколько хорошо он интегрируется в среду и т. д.)
  • Когда тестирование готово, мы нажимаем «Тест» — это код, который был одобрен для перемещения вверх по конвейеру, и поэтому среда намного более стабильна, чем «Разработка».
  • Затем мы передаем его на сервер UAT, который, по сути, является имитацией живого сервера, чтобы быть максимально стабильным и репрезентативным для живого выпуска. Код, одобренный для перемещения сюда, встречается НЕ часто.
  • Наконец, производственные среды.

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

ГЛАВНАЯ -> ЭТАП -> ТЕСТ -> РАЗРАБОТКА

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

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

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

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


tfs version-control branching-strategy corporate
person Krishan Patel    schedule 20.03.2016    source источник

Ответы (2)


arrow_upward
3
arrow_downward

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

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

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

person Angshuman    schedule 21.03.2016
comment
спасибо, я видел наглядные диаграммы, но не заметил pdf. Сейчас буду читать! - person Krishan Patel; 21.03.2016

arrow_upward
2
arrow_downward

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

               Main
             |     |
             |     |
            DEV  Release

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

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

person Isaiah4110    schedule 21.03.2016