План базовой ветки ALM — цель ветки выпуска?

Команда Microsoft ALM описывает план Basic Branch как нуждающийся в ветвях MAIN, DEV и RELEASE.

Я работаю над внедрением ветвления/слияния для новой команды, которая в настоящее время использует систему управления версиями без каких-либо ветвей.

Мне было интересно, как на самом деле используется ветвь RELEASE.

Можно ли внести изменения в ветку DEV, а затем объединить их с веткой MAIN без необходимости в ветке RELEASE? MAIN по-прежнему будет доступен только для чтения. По сути, это будет ветка RELEASE. Причина, по которой я говорю это, заключается в том, что у нас не так много изменений, но я хочу изолировать стабильный код от новых изменений. Наша концепция «релиза» еще недостаточно определена. Я все еще работаю над этим.

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

Я был бы признателен за некоторые комментарии о стратегии использования только веток MAIN и DEV.


tfs branch branching-and-merging branching-strategy alm
person Issa Fram    schedule 13.08.2014    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Обычно ветки релиза используются для «сохранения». По сути то же самое, что и этикетка.

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

  • Метки в TFS изменяемы, что означает, что кто-то может изменить метку, и не будет контрольного журнала.
  • Конечно, ветки также изменяемы (изменения могут быть зарегистрированы), но это можно заблокировать с помощью разрешений для конкретной ветки.
  • Кроме того, если в ветку Release внесены изменения (чего никогда не должно быть), по крайней мере, у вас есть контрольный журнал в истории.
  • Несмотря на то, что ветвь выглядит как тяжеловесная операция, создающая копию всей вашей кодовой базы, на самом деле TFS просто создает новый указатель на те же файлы, поэтому стоимость хранения тривиальна.
person Dylan Smith    schedule 13.08.2014
comment
Я всегда понимаю причину в целом, но для команды, которая выпускает код всякий раз, когда они вносят изменения без реального SDLC, это может быть сложно понять. Как вы думаете, я должен вводить ветки в более медленном темпе? Может быть, начать с MAIN/DEV и познакомить команду с Agile-методами через SCRUM, сливая DEV с MAIN после каждого спринта? Потом, когда они поймут, что я могу ввести ветку RELEASE в Source Control и показать важность релиза? - person Issa Fram; 13.08.2014
comment
Обычно ветки релиза не создаются обычными разработчиками, они создаются как часть процесса релиза. Независимо от того, как часто вы выпускаете, у вас должен быть стандартный повторяемый процесс выпуска (может быть ручной или автоматический, и он не должен быть сложным), и одним из шагов этого процесса выпуска должно быть создание ветки выпуска. - person Dylan Smith; 14.08.2014

arrow_upward
2
arrow_downward

Я пошел другим путем, когда внедрил TFS на клиенте (заменил SVN). Что я сделал, так это представил ветку MAIN и ветку RELEASE, а не ветку DEV изначально, так как это показалось команде очень запутанным. Также сложно изначально передать цель ветки DEV команде, знакомой с SVN.

Основная цель нашей ветки RELEASE состояла в том, чтобы сохранить исторический заполнитель, как сказано в другом ответе. В настоящее время мы используем Git, и у нас есть сервер CI, который выполняет процесс выпуска и переходит к выпуску/$version_number. Я думаю, что эту концепцию будет легче понять и донести до вашей команды. то есть автоматически создавать ветки релиза, когда вы действительно выпускаете.

person agartee    schedule 13.08.2014