Как настроить GitVersion для Release Flow?

Question

Я пытаюсь настроить GitVersion для работы с Release Flow стратегией ветвления.

По сути, у меня естьосновная ветка Master, ветки Release, Feature и Fix.Ветви Feature и Fix создаются из ветки Master и сливаются обратно в Master с помощью запроса на извлечение.В конце спринта я создаю ветку Release от Master, которая будет действовать до конца следующего спринта, когда будет создана новая ветка Release.Ветви Release не объединяются в master.Их даже можно удалить после создания новой ветки Release.Если требуется исправление, оно будет разработано в ветке Fix, созданной и объединенной обратно с master, а затем вставленной в текущую ветку Release.Я использую теги git только для основных выпусков.

Возвращаясь к GitVersion, я хочу настроить его так, чтобы номер вспомогательной версии увеличивался при создании новой ветви выпуска, а номер исправления увеличивался при появлении новой.совершить в ветке релиза (вишня выбрана из ветки Fix).

Кто-нибудь уже сделал это и может мне помочь?

Answer 1

Мне удалось заставить это работать над созданием Anti-Pattern только для одной части процесса выпуска.Но это не имеет большого значения, если вы используете Azure DevOps, потому что Microsoft предоставляет быстрый и простой способ увидеть, находится ли ваша ветвь релиза впереди или позади основной ветки.Я протестировал это и использую Release Flow для почти полной автоматизации управления версиями, помимо создания ветки релиза и нового тега в конце каждого спринта.Этот метод также хорошо работает для Semantic Versioning 2.0 моих пакетов Nuget, в которых я использую представления вместо суффиксных тегов.

Модифицированный поток выпуска

Answer 2

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

После битовой борьбы я закончилс моим сценарием PowerShell .Сценарий прост и работает очень быстро (около 1 секунды, в отличие от GitVersion, который может работать 5-15 минут на наших огромных репо с большим количеством веток).Теперь результат выглядит так:

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

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