Как настроить GitVersion для Release Flow?
Я пытаюсь настроить GitVersion для работы со стратегией ветвления Release Flow.
По сути, у меня есть основная ветка Master, ветки Release, Feature и Fix. Ветви Feature и Fix создаются из ветки Master и сливаются обратно в Master с помощью запроса на извлечение. В конце спринта я создаю ветку Release от Master, которая будет действовать до конца следующего спринта, когда будет создана новая ветка Release. Ветви Release не объединяются в master. Их даже можно удалить после создания новой ветки Release. Если требуется исправление, оно будет разработано в ветке Fix, созданной и объединенной обратно с master, а затем вставленной в текущую ветку Release. Я использую тэги git только для основных релизов.
Возвращаясь к GitVersion, я хочу настроить его так, чтобы вспомогательный номер версии увеличивался при создании новой ветки релиза, а номер патча увеличивался при новой фиксации в ветви релиза (вишня выбрана из ветви Fix).
Кто-нибудь уже сделал это и может мне помочь?
2 ответа
Мы используем поток, очень похожий на этот (на самом деле на его основе). Мы вносим исправления прямо в ветки релиза, а также создаем ветки перед выпуском (удобно иметь отдельные каналы в octopus-deploy).
После непродолжительной борьбы я получил свой собственный скрипт PowerShell. Сценарий прост и работает очень быстро (около 1 секунды, в отличие от GitVersion, который может работать 5-15 минут на наших огромных репо с большим количеством веток). Теперь результат выглядит так:
Он в основном предназначен для использования с TeamCity, но я думаю, что вы можете легко сменить его на ноги, которые вам нужны. Подробное описание алгоритма расчета вы можете увидеть в комментариях к скрипту. Это также кратко объяснено на этой диаграмме:
Предостережение: в будущих / тематических ветках, в отличие от GitVersion, скрипт использует постоянно растущий счетчик сборки из teamcity вместо счетчика коммитов. Я должен был это сделать, когда узнал, что наши колледжи используют насильственные толчки (некоторая политика "чистой истории"), и я не могу полагаться на историю коммитов.
Я смог заставить это работать над созданием Anti-Pattern только для одной части процесса выпуска. Но это не имеет большого значения, если вы используете Azure DevOps, потому что Microsoft предоставляет быстрый и простой способ увидеть, находится ли ваша ветвь релиза впереди или позади основной ветки. Я протестировал это и использую Release Flow для почти полной автоматизации управления версиями, помимо создания ветки релиза и нового тега в конце каждого спринта. Этот метод также хорошо работает для Semantic Versioning 2.0 моих пакетов Nuget, в которых я использую представления вместо суффиксных тегов.