Myslíš, že je správné spojit sestavení, testování a publikaci obrazu v jednom workflow a také přidat kroky pro nasazení do různých prostředí?

To není vždy optimální. I když takový přístup může být vhodný pro malé projekty nebo místní testovací sestavení, spojení všech kroků do jednoho workflow má nevýhody:

• Snížení flexibility: Nasazení do různých prostředí (dev, staging, produkce) vyžaduje různé parametry a často růzová přístupová práva. Spojení to ztěžuje správu těchto rozdílů.
• Závislost na prostředí: Pokud se nasazení v jednom z prostředí nezdaří, celá sestava je považována za neúspěšnou, i když tvorba obrazu a testy proběhly úspěšně.
• Obtížnost rollbacku: Vrácení nasazení je méně jednoduché, protože je třeba vrátit celý workflow.
• Prodlužení doby běhu: Celý pipeline trvá déle, což zpomaluje zpětnou vazbu pro vývojáře.
• Menší škálovatelnost: S růstem projektu a počtu nasazovacích prostředí se tento workflow stává nepraktickým a těžko spravovatelným.

Častější a flexibilnější praxí je rozdělení těchto etap:

1. Build & Test Pipeline: Odpovídá za sestavení kódu, testování, tvorbu obrazu a jeho uložení do artefaktového úložiště (například Docker Registry, Nexus). Tento workflow se spouští při každém commitu nebo pull requestu.
2. Deployment Pipelines: Samostatné workflow pro nasazení do každého prostředí. Ty načítají již sestavený a otestovaný obraz z artefaktového úložiště a nasazují jej do cílového prostředí. Tyto workflow mohou být spuštěny ručně, podle plánu nebo automaticky po úspěšném dokončení předchozí fáze (například úspěšné nasazení do staging).

To umožňuje:

• Rychlejší zpětnou vazbu o kvalitě kódu (build & test).
• Nezávislé nasazení do různých prostředí.
• Flexibilnější správu parametrů nasazení pro každé prostředí.
• Zjednodušení procesu rollbacku.

Výjimkou mohou být malé pet-projekty nebo monolitické aplikace s jednoduchým procesem nasazení, kde náklady na rozdělení převyšují přínosy. Většina podnikových prostředí však považuje rozdělení workflow za nejlepší praxi.