Развертывание. Является Ли Поток Gitlab (Или Поток Github И Т. Д.) Анти-Развертыванием Повсюду?

Исторически сложилось так, что особенно в мире Java принцип «сборка один раз и развертывание повсюду» был очень важным моментом для развертываний. Артефакты должны создаваться ровно один раз при выпуске релиза и храниться где-нибудь, например, в Nexus или Artifactory, где они являются неизменяемыми и могут быть многократно и безопасно развернуты во всех средах.

С другой стороны, GitLab Flow рекомендует иметь отдельную ветку для каждой среды и развертывать ее в этой среде как событие после выполнения мерж-реквеста в ветку. Например. слияние master -> staging запускает CI/CD в промежуточной ветке, что приводит к развертыванию там. Объединение промежуточного этапа с производственной веткой приводит к тому же самому в производстве (с возможностью принудительного согласования запуска вручную).

Таким образом, поток GitLab заставляет нас пересобирать наши артефакты для каждой среды, а не создавать их после развертывания повсюду.

Означает ли это, что мы должны полностью отказаться от повсеместной сборки и развертывания при переходе на современные инструменты, такие как GitLab/GitHub? Это хорошо?

Я думаю, мы можем расширить поток GitLab следующим образом:

• Создавайте артефакты при слиянии с веткой DEV и сохраняйте их в репозитории maven/etc.
• Выполните развертывание с использованием этих артефактов.
• При слиянии с промежуточным/продуктовым проектом пропустите сборку/тестирование и выполните развертывание только с использованием тех же артефактов.

Однако это похоже на принуждение GitLab/etc к чему-то против их модели, поэтому я думаю, что это не очень хорошая идея.

Примечание. Мне также интересно, как в некоторых крупных проектах возможна сборка/тестирование/развертывание в каждой среде отдельно. Например. Престо Facebook включает около часа тестов в сборке maven (или больше)... Я бы не хотел, чтобы мой производственный релиз занимал часы; это противоположность современному.

Есть какие-нибудь мысли?

#deployment #gitlab #continious-deployment #cicd #build-pipeline

Один из возможных ответов может исходить из причины использования нескольких ветвей в качестве основы для сред.

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

В этом контексте ветки будут расходиться, поэтому принцип «создать один раз — развернуть везде» аналогичным образом применим только на уровне ветки/среды и не может применяться на уровне проекта. В таком случае поток GitHub/GitLab может работать хорошо.

Если, однако, не происходит сбора вишен между ветвями и строго прямые/быстрые слияния из исходных точек ветки восходящего потока используются для распространения изменений в нижестоящие ветки/среды, тогда причина использования нескольких ветвей ИМХО сомнительна. А одиночный/мастер Вместо этого можно использовать ветку, при этом среды реализуются просто как различные шаги/этапы в конвейере обработки CI/CD.

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

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

Обратите внимание, что ничто в этом сценарии не противоречит использованию самого GitLab/GitHub (или любой другой современной системы контроля версий), вы просто не придется используйте все возможности, которые они предлагают ;)