Что такое полезная стратегия управления версиями? - PullRequest
Новая
       15

Что такое полезная стратегия управления версиями?

8 голосов
/ 23 августа 2011

Мы перешли к подходу управления версиями продукта, который будет помечать / увеличивать сборки в соответствии со следующим форматом: [Major].[Minor].[Build].[Revision/Patch], и в производственном выпуске по существу будет добавление Major или Minor (в зависимости от объема изменений).

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

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

Некоторые соображения:

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

(облегченный) сценарий может помочь: 

Product X\Trunk (ver 1.1.208.0)
Product X\Branches\Feature A (ver 1.1.239.0)
Product X\Branches\Feature B (ver 1.1.221.0)

Редактировать: лучшая документация, которую я нашел на данный момент, находится на MSDN , хотя она немного расплывчата в уникальных версиях параллельных ветвей.

Ответы [ 3 ]

4 голосов
/ 31 августа 2011

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

На самом деле нет правильного или неправильного ответа - никакой серебряной пули - на правильную обработку разветвления / слияния, поскольку, ИМХО, это варьируется от бизнеса к бизнесу и от продукта к продукту. Вот как мы решили идти вперед:

Независимо от ствола или ответвления, мы продолжим нумерацию на основе формата [Major]. [Minor]. [Build]. [Rebuild], где rebuilt указывает ревизию сборки. Ветви и ствол будут не синхронизированы (разные номера сборки), но это не проблема, так как мы будем определять наши конфигурации сборки и в любом случае явно удалять местоположения. Управление средой будет знать, какая версия развернута на каком сервере.

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

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

Я хочу оставить этот поток открытым и позволить другим писать о своем предпочтительном методе управления версиями веток.

2 голосов
/ 23 августа 2011

Мы не даем номера версий нашим веткам функций.У нас есть основная ветвь разработки, затем мы создаем ветки для каждой создаваемой нами функции.Когда эта функция завершена или ее части завершены, и это не нарушит ветвь разработки, мы возвращаемся к разработке.

При этом ветвь разработки должна быть несколько стабильной.Мы выпускаем еженедельно, поэтому каждый понедельник мы создаем ветку релиза от Develop, которой присваивается номер версии.Затем тестеры проводят день или два, тестируя эту ветку, чтобы убедиться, что она стабильна, а затем мы внедряем во вторник / среду.

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

1 голос
/ 23 августа 2011

Я бы не привязывал номер версии к ветви функции, потому что в параллельном сценарии разработки вам может потребоваться учитывать:

  • только часть функции (не все может быть готово кВыпуск в функции)
  • несколько функций (если одна зависит от другой), что означает, что вам нужно будет выпустить несколько функций как часть новой версии.
  • вспомогательные или основные версии: не каждая стабильнаяточка будет увеличивать только сборку, функция может вносить незначительные или существенные изменения

Для каждого нового выпуска x.y я бы предпочел отдельную ветвь для консолидации, где я могу объединить все выбранные ветви функцийдля следующего выпуска (поскольку некоторые функции могут быть не готовы вовремя), и где часть x.y будет иметь смысл.

Другими словами, я бы отделил цикл разработки функций от цикла выпуска.

...