Как именно работает сборка раскрутки с GitFlow?

Question

Мне трудно понять, как именно концепция продвижения сборок (и их артефактов) работает вместе с GitFlow. Я нахожусь в процессе разработки непрерывного рабочего процесса интеграции / доставки с Git, Jenkins и (как новое дополнение) Artifactory. Это то, что я разработал до сих пор:

• Артефакты сборки из ветви develop будут автоматически переведены в репозиторий dev (если пройдены модульные тесты и т. Д.) И, следовательно, переведены в статус dev. Дальнейшее продвижение по службе для этих артефактов невозможно.
• Артефакты из ветвей feature вообще не продвигаются и не продвигаются.
• Артефакты из ветви release также можно повысить до dev (или мне следует ввести release репо?)
• Как только release объединен с master, новый коммит помечается, и Дженкинс запускает полный конвейер CI / CD. После юнит-тестов и метрик (этапов сборки, которые выполняются во всех ветвях) артефакт помещается в репо master и повышается до master. Затем артефакт используется для развертывания в промежуточной среде, где может быть выполнено окончательное тестирование (эти тесты могут быть автоматизированы при полной установке непрерывного развертывания). Если все тесты пройдены успешно, артефакт будет перемещен в репо prod, развернут в производство и переведен в статус prod. Если на каком-либо этапе, пока не произойдет сбой, тег будет принадлежать версии, которая никогда не поступала в производство.

Правильно ли мое понимание? Я в основном смущен слиянием мастер / релиз. Интуитивно я бы сказал, что двоичные файлы из release будут подвергаться наибольшему тестированию. Тем не менее, GitFlow диктует, что только коммиты на master будут помечены (и я не хочу отмечать коммиты, которые технически не производят двоичные файлы, которые попадают в производство). Что, если во время сборки коммита на master обнаружатся проблемы? Это "неправильно" иметь теги, которые не попали в производство? Нужно ли мне возвращать или отменять тег или даже коммит слияния?

Было бы приятно услышать, как другие люди подходят к этому промоушену + GitFlow. Любая помощь очень ценится.

Answer 1

Существует так много разных моделей ветвления, и так много людей со своими собственными дублями, что я не думаю, что есть определенная ссылка на то, что означает «GitFlow». (Пожалуйста, не стесняйтесь доказать, что я неправ, я люблю обсуждать подобные вещи).

Учитывая сказанное, я (лично) нахожу эти две ссылки очень полезными, полными и убедительными:

1. Оригинальное сообщение в блоге NVIE
2. разбивка DataShift

---

Итак, что?

По-моему, первые два пункта верны, а последние два неверны.

С точки зрения продвижения сборки все ветки release и hotfix могут (и ожидаются) быть развернутыми в вашей среде test / staging для окончательной проверки. Из DataShift:

Код в ветви релиза развертывается в подходящей тестовой среде, тестируется, и любые проблемы исправляются непосредственно в ветви релиза. Этот цикл развертывания -> test -> fix -> redeploy -> retest продолжается до тех пор, пока вы не будете удовлетворены тем, что выпуск достаточно хорош для выпуска клиентам.

Затем, когда все проверено и вы готовы к выпуску:

Когда выпуск завершен, ветвь релиза объединяется с master и development, чтобы гарантировать, что любые изменения, внесенные в ветку релиза, не будут случайно потеряны новой разработкой.

Или, если подвести итог:

Основная ветвь отслеживает только выпущенный код. Единственные коммиты для мастера - это слияния из веток релиза и ветвей исправлений.

Здесь все становится сложнее, и разные проекты имеют разные мнения: откуда на самом деле возникает артефакт prod?

На мой взгляд, у вас есть два варианта:

1. Повторно использовать артефакт из test / staging, созданный из ветви release / hotfix.
2. Перестроить артефакт из коммита в master.

С точки зрения только кода они эквивалентны - код в master точно соответствует коду, который был только что собран и развернут в test / staging. Однако с точки зрения процесса сборки перспективы могут отличаться - разные переменные среды, разные ключи и т. Д.

Кроме того, все может быть сложнее, если смотреть на вашу команду test против staging.

---

Итак, что делать?

С учетом того, что это только мое мнение, и предположением, что staging означает "производственное зеркало", я думаю, что следующий процесс является разумным:

• Ветви компонентов не развертываются в общей среде
• Среда dev (если имеется) создается / развертывается из ветви develop
• Среда test создается / развертывается из release или hotfix филиала
• Среда staging создается / развертывается из ветви release или hotfix ПОСЛЕ того, как нормальное тестирование / исправление завершено. ПРИМЕЧАНИЕ. Вы можете указать это с помощью тега RC, но это вопрос командной работы.
• После проверки staging код объединяется с release / hotfix в master и помечается версией выпуска.
• Среда prod развернута с утвержденным и протестированным артефактом от staging.

---

Заключительные мысли:

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