Два подхода к управлению версиями (TFS): нужен совет

Question

Мы достигли той точки в нашем проекте, когда нам необходимо произвести развертывание в производственной среде, но также необходимо постоянно совершенствовать будущие функции. Наш источник контроля в настоящее время имеет одну ветку разработки. В моей предыдущей компании была создана система из 3 филиалов: разработка, интеграция, производство. Разработка функций проводилась в среде разработки, тестирование в Integration и Production всегда было кодом, работающим в текущей производственной среде (за исключением краткого промежутка времени, когда было выполнено слияние из Integaration в Production и развертывание было выполнено).

Каждый раз, когда происходило изменение производства или слияние с производством, которое было развернуто в реальном времени, новая ветвь архива снималась с производства и получала номер версии. Любое изменение в более высокой ветке было объединено, поэтому изменения в Производстве вернутся, например, в Разработка. Это работало, но я всегда не видел необходимости в постоянном отделении интеграции и производства.

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

Я слышал, что эта модель распространена, но в системе, которую я сейчас настраиваю, я предлагаю следующее:

Иметь ветку разработки, создавать новую ветку выпуска каждый раз, когда разработка готова к следующему развертыванию в производство. Ветвям релиза присваивается номер версии, а затем снова ветвится ветвь архива. Тестирование проводится в ветке Release. После развертывания все производственные исправления вносятся в ветку Release, затем создается новая ветвь архива с небольшим приращением номера версии после утверждения развертывания. Когда новое развертывание из разработки готово, создается новая ветвь выпуска ...

Для меня это проще и, на самом деле, лучше: ветки NO Integaration (без слияний) НЕТ и есть свежая ветвь Production (Release) для каждого развертывания и обслуживает текущие версии Production. Что мне не хватает? Зачем идти на модель развития, интеграции, производства?

Спасибо

Answer 1

Преимущество системы с тремя ветвями состоит в том, что ваши разработчики, тестировщики и клиенты имеют собственную изолированную версию / ветвь кода. Это обеспечивает «закрытую» разработку, в которой функции могут быть переведены в следующую ветвь, только когда они проходят определенную шкалу полноты / качества, что дает высокую уверенность в том, что ветвь релиза всегда находится в состоянии соответствия для отправки клиенту.

Плюсы:

• У вас (почти) всегда есть сборка, которую можно отправить клиенту в любой момент.
• У ваших тестеров (почти) всегда есть рабочая сборка для тестирования
• Ветвь релиза стабильна, поэтому вам не нужно часто исправлять ошибки и объединять их в ветки test / dev.

Минусы:

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

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

На самом деле, когда вы выпускаете релиз, нет необходимости в том, чтобы кодировать его в ветвь архива - все, что вам нужно сделать, это пометить код, когда вы делаете релиз, чтобы получить надежный «снимок», который вы можете восстановить. в будущем.

Answer 2

Ваше предложение не слишком далеко от рекомендаций. Основное различие в модели заключается в том, что вы предлагаете разрабатывать непосредственно на том, что раньше было «интеграционной» веткой. Многие люди предлагают снять ветку с этой ветви, чтобы продолжить свою работу, а затем объединиться. Но это зависит от размера вашей команды.

Бесценный ресурс для работы с ветвлением TFS находится здесь:

http://tfsbranchingguideiii.codeplex.com/

Answer 3

Ваше предложение звучит именно так, как я работаю:

• Я развиваюсь в основной ветке, пока мои разработки не будут готовы
• Затем создается ветка релиза, скажем, релиз 1.5
• После того, как ветка релиза была протестирована, она снова разветвляется, называя ее 1.5.1
• Исправление ошибок выполняется в основной ветке и во всех активных ветвях выпуска (например, 1.3, 1.4, 1.5)
• Регулярно новые версии (ветки) веток выпуска создаются и отправляются клиентам (например, 1.5.2, 1.5.3, ...)

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

Answer 4

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

Если вы думаете о ментальной модели с графом связанных узлов, ветвь «Производство» - это просто еще один узел, связанный с основной ветвью интеграции.