Являются ли контролируемые / рекламные ветви ценными?

Question

Я работаю в SCM и работаю с различными инструментами (Subversion, Clearcase, TFS, Perforce) и технологиями (в основном .NET, Java). До того, как я начал работать, обычным делом было создание контролируемого филиала.

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

Контролируемая сборка: -Строительный движок, который берет код из контролируемой ветви и создает артефакт, который разработчики не могут изменить.

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

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

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

Вопросы:

Должен ли я рекомендовать перейти от текущей стратегии контролируемой ветви? Я пропускаю другие льготы?

Answer 1

Я бы не рекомендовал использовать ответвления в качестве механизма продвижения, если только вы не собираетесь вносить множество изменений из метки, сливаемой в указанную ветвь.
Ветвь должна изолировать усилия по разработке (т. Е. Что-то, где файлы модифицируются и фиксируются новые версии)

Метка, связанная с какими-либо метаданными (атрибуты ClearCase, свойства SVN, заметки Git и т. Д.) Должна быть достаточной для мониторинга продвижения указанной метки (с ее неизменным содержимым) на различных уровнях продвижения.

Answer 2

Мы используем контролируемую ветвь (MAIN) в качестве официальной ветки сборки.Разработчикам разрешен доступ к этой ветви только через операцию слияния из ветви разработки.Кроме того, код ветки MAIN объединяется с веткой BUGFIX, которая посвящена исправлениям ошибок для нашего текущего выпуска программного обеспечения, и веткой PROD, где код помечается отдельно для каждого выпуска.

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

Когда у нас возникают проблемы со сборкой в ​​нашей ветке MAIN, мы также непреклонны в том, что разработчики исправляют эти ошибки в ветке разработки и объединяют разрешение в MAIN в рамках наших политик SCM.