Continuous Delivery

Praktyka utrzymywania kodu w stanie gotowym do wdrożenia na produkcję w dowolnym momencie. Wdrożenie wymaga jedynie ręcznego zatwierdzenia.

Continuous Delivery (CD, ciągłe dostarczanie) to praktyka, w której Twój kod przez cały czas pozostaje w stanie gotowym do wdrożenia na produkcję. Każda zmiana, która przejdzie automatyczne testy i build, ląduje w artefakcie, który można wypchnąć na żywo w dowolnym momencie. Kluczowe słowo to „można” — sama decyzja o kliknięciu przycisku „Deploy” zostaje po stronie człowieka.

Jak to działa i do czego służy

CD jest naturalnym przedłużeniem Continuous Integration (CI). Najpierw CI: developerzy często mergują kod do wspólnej gałęzi, a pipeline automatycznie buduje aplikację i odpala testy. CD idzie krok dalej — każdy zielony build automatycznie przechodzi przez kolejne etapy (testy integracyjne, staging, ewentualne testy wydajnościowe) i kończy jako gotowa do wdrożenia paczka. Brakuje tylko ostatniego kroku: ręcznego zatwierdzenia wdrożenia na produkcję.

Sens jest taki, że wdrożenie przestaje być stresującym wydarzeniem „raz na kwartał o północy”, a staje się rutynową, nudną czynnością. Małe, częste zmiany są łatwiejsze do przetestowania i do cofnięcia, jeśli coś pójdzie nie tak.

Przykład z praktyki

W pipeline GitHub Actions albo GitLab CI definiujesz etapy: build, test, deploy-staging, a na końcu deploy-prod oznaczony jako manualny. W GitLab robisz to jednym słowem:

  • deploy-prod:
  •   when: manual

Efekt: cała ścieżka biegnie sama, ale produkcja czeka, aż ktoś kliknie. Po kliknięciu narzędzie (np. kubectl, Helm czy argocd app sync) wypycha wersję na serwery.

Częste błędy i mity

Najczęstsza pomyłka to mylenie Continuous Delivery z Continuous Deployment. To drugie idzie o krok dalej — kasuje ręczne zatwierdzenie, więc każda zmiana, która przejdzie testy, ląduje na produkcji automatycznie. Oba skracają się do „CD”, co regularnie wywołuje zamieszanie na spotkaniach.

Drugi mit: „mamy pipeline, więc mamy CD”. Nie. Jeśli wdrożenie wymaga trzech ludzi, ręcznej edycji configa i modlitwy, to nie jest gotowość do wdrożenia w dowolnym momencie. CD bez solidnego pokrycia testami i automatycznego rollbacku to tylko szybsza droga do wywalenia produkcji.

Pojęcia powiązane

Continuous Integration, Continuous Deployment, pipeline CI/CD, DevOps, feature flags, rollback, blue-green deployment.