Мислиш ли, че е правилно да се обединят създаването, тестването и публикуването на образа в един работен процес, както и да се добавят стъпки за разгръщане в различни среди?

Това не винаги е оптимално. Въпреки че такъв подход може да бъде удобен за малки проекти или локални тестови сборки, обединяването на всички етапи в един workflow има недостатъци:

• Намаляване на гъвкавостта: Разгръщането в различни среди (dev, staging, production) изисква различни параметри и често различни права за достъп. Обединяването усложнява управлението на тези различия.
• Зависимост от средата: Ако разгръщането в една от средите се провали, цялата сборка се счита за неуспешна, дори ако създаването на образа и тестовете са преминали успешно.
• Трудност при връщане назад: Връщането на разгръщането става по-малко тривиално, тъй като трябва да върнете цялото workflow.
• Увеличаване на времето за изпълнение: Целият pipeline отнема повече време, което забавя обратната връзка към разработчиците.
• По-малка мащабируемост: С растежа на проекта и увеличаването на броя на средите за разгръщане, такъв workflow става тромав и трудно управляем.

По-често срещаната и по-гъвкава практика е разделянето на тези етапи:

1. Build & Test Pipeline: Отговаря за събиране на кода, тестване, създаване на образ и поставянето му в регистър на артефакти (например Docker Registry, Nexus). Този workflow се стартира при всеки commit или pull request.
2. Deployment Pipelines: Отделни workflows за разгръщане във всяка среда. Те взимат вече създадения и тестван образ от регистъра на артефакти и го разгръщат в целевата среда. Тези workflows могат да се стартират ръчно, по график или автоматично след успешно завършване на предишния етап (например, успешно разгръщане в staging).

Това позволява:

• По-бърза обратна връзка за качеството на кода (build & test).
• Независимо разгръщане в различни среди.
• По-гъвкаво управление на параметрите за разгръщане за всяка среда.
• Упростяване на процеса на връщане назад.

Малките pet-проекти или монолитните приложения с прост процес на разгръщане могат да бъдат изключение, където разходите за разделяне надвишават ползите. Въпреки това, в повечето корпоративни среди разделянето на workflow е най-добрата практика.