Czy uważasz, że poprawne jest łączenie buildowania, testowania i publikowania obrazu w jednym workflow, a także dodawanie kroków do wdrożenia w różnych środowiskach?

To nie zawsze jest optymalne. Chociaż takie podejście może być wygodne dla małych projektów lub lokalnych buildów testowych, łączenie wszystkich etapów w jeden workflow ma wady:

• Zmniejszenie elastyczności: Deployment w różnych środowiskach (dev, staging, produkcja) wymaga różnych parametrów i często różnych uprawnień dostępu. Połączenie utrudnia zarządzanie tymi różnicami.
• Zależność od środowiska: Jeśli deployment w jednym z środowisk się nie powiedzie, cała kompilacja jest uznawana za nieudaną, nawet jeśli tworzenie obrazu i testy przebiegły pomyślnie.
• Trudność w cofnięciu zmian: Cofnięcie deploymentu staje się mniej trywialne, ponieważ trzeba cofnąć cały workflow.
• Wydłużenie czasu wykonania: Cały pipeline zajmuje więcej czasu, co spowalnia informację zwrotną dla programistów.
• Mniejsza skalowalność: W miarę rozwoju projektu i zwiększania się liczby środowisk deploymentowych, taki workflow staje się niepraktyczny i trudny do zarządzania.

Bardziej powszechną i elastyczną praktyką jest podział tych etapów:

1. Build & Test Pipeline: Odpowiada za kompilację kodu, testowanie, tworzenie obrazu i umieszczanie go w rejestrze artefaktów (np. Docker Registry, Nexus). Workflow ten uruchamia się przy każdym commicie lub pull request.
2. Deployment Pipelines: Oddzielne workflow dla deploymentu do każdego środowiska. Pobierają już zbudowany i przetestowany obraz z rejestru artefaktów i wdrażają go do docelowego środowiska. Workflow te mogą być uruchamiane ręcznie, według harmonogramu lub automatycznie po pomyślnym zakończeniu poprzedniego etapu (np. udany deployment w staging).

To pozwala:

• Szybciej uzyskać informację zwrotną o jakości kodu (build & test).
• Deployment w różnych środowiskach niezależnie.
• Bardziej elastycznie zarządzać parametrami deploymentu dla każdego środowiska.
• Uprościć proces cofania zmian.

Wyjątkiem mogą być małe pet-projekty lub monolityczne aplikacje z prostym procesem deploymentu, gdzie koszty podziału przewyższają korzyści. Jednak w większości środowisk korporacyjnych podział workflow jest najlepszą praktyką.