Continuous Deployment (CD, ciągłe wdrażanie) to praktyka, w której każda zmiana w kodzie, która przejdzie przez pełny zestaw automatycznych testów, ląduje na produkcji bez udziału człowieka. Nie ma przycisku „deploy”, nie ma maila do szefa z prośbą o zgodę, nie ma okienka wdrożeniowego w piątek o 23:00. Jest commit, jest zielony pipeline, jest produkcja. To rozszerzenie Continuous Delivery, gdzie kod jest gotowy do wdrożenia w każdej chwili, ale ktoś musi kliknąć. W Continuous Deployment tego kliknięcia nie ma.
Jak to działa
Cały sekret leży w zaufaniu do automatyzacji. Każdy push do głównej gałęzi uruchamia pipeline: build, testy jednostkowe, integracyjne, czasem testy end-to-end, skany bezpieczeństwa. Jeśli wszystko świeci na zielono, artefakt automatycznie trafia na serwery produkcyjne. Jeśli cokolwiek się wywali, deployment się nie odbywa, a Ty dostajesz powiadomienie.
Żeby to nie skończyło się katastrofą, Continuous Deployment opiera się na siatce zabezpieczeń: feature flags (nowy kod jest na produkcji, ale wyłączony, dopóki go nie włączysz), strategie typu canary lub blue-green (zmiana idzie najpierw do 5% użytkowników), oraz automatyczny rollback, gdy wskaźniki błędów skoczą. Bez tego „ciągłe wdrażanie” zamienia się w „ciągłe pożary”.
Przykład z praktyki
Masz repozytorium na GitHubie i workflow w GitHub Actions. Plik .github/workflows/deploy.yml nasłuchuje na push do main: buduje obraz Dockera, odpala npm test, a jeśli testy przejdą, robi kubectl apply albo wywołuje deploy na Vercelu czy Fly.io. Programista merguje PR-a, idzie po kawę, a po ośmiu minutach jego zmiana jest już live dla użytkowników. Firmy jak Netflix czy Amazon wdrażają tym sposobem setki, a nawet tysiące razy dziennie.
Częste błędy i mity
- Mit: „to dla nas za ryzykowne”. Paradoksalnie małe, częste wdrożenia są bezpieczniejsze niż wielkie wdrożenie raz na kwartał, bo gdy coś pęknie, wiesz dokładnie, który commit zawinił.
- Błąd: słabe testy. Continuous Deployment bez solidnego pokrycia testami to wystrzeliwanie bugów na produkcję z prędkością światła.
- Mylenie z CI. Continuous Integration to częste scalanie i testowanie kodu, Continuous Deployment to automatyczne wypuszczanie go na produkcję. To różne etapy.
- Brak monitoringu. Jeśli wdrażasz automatycznie, ale nie obserwujesz metryk i logów, dowiesz się o awarii od użytkowników na Twitterze.
Pojęcia powiązane
Warto znać też: Continuous Integration (CI), Continuous Delivery (też skracane do CD), pipeline CI/CD, feature flags, canary deployment, blue-green deployment, rollback oraz DevOps jako szersza kultura, w której to wszystko żyje.