Как ты считаешь, правильно ли в одном workflow объединять сборку, тестирование и выкладку образа в хранилище артефактов, а также добавлять шаги для деплоя в различные среды?

Это не всегда оптимально. Хотя такой подход может быть удобен для небольших проектов или локальных тестовых сборок, объединение всех этапов в один workflow имеет недостатки:

• Уменьшение гибкости: Деплой в разные среды (dev, staging, production) требует разных параметров и часто разных прав доступа. Объединение усложняет управление этими различиями.
• Зависимость от окружения: Если деплой в одну из сред не удался, вся сборка считается проваленной, даже если сборка образа и его тестирование прошли успешно.
• Сложность отката: Откат деплоя становится менее тривиальным, так как нужно откатывать весь workflow.
• Увеличение времени выполнения: Весь pipeline занимает больше времени, что замедляет обратную связь для разработчиков.
• Меньшая масштабируемость: При росте проекта и увеличении количества сред деплоя такой workflow становится громоздким и трудноуправляемым.

Более распространенной и гибкой практикой является разделение этих этапов:

1. Build & Test Pipeline: Отвечает за сборку кода, тестирование, сборку образа и помещение его в реестр артефактов (например, Docker Registry, Nexus). Этот workflow запускается по каждому коммиту или pull request'у.
2. Deployment Pipelines: Отдельные workflow для деплоя в каждую среду. Они берут уже собранный и протестированный образ из реестра артефактов и деплоят его в целевое окружение. Эти workflow могут запускаться вручную, по расписанию или автоматически после успешного завершения предыдущего этапа (например, успешного деплоя в staging).

Это позволяет:

• Быстрее получать обратную связь о качестве кода (build & test).
• Деплоить в разные среды независимо.
• Более гибко управлять параметрами деплоя для каждой среды.
• Упростить процесс отката.

Исключением могут быть небольшие pet-проекты или монолитные приложения с простым процессом деплоя, где накладные расходы на разделение превышают выгоду. Однако в большинстве корпоративных сред разделение workflow является лучшей практикой.