CI/CD to dwie powiązane praktyki, które automatyzują drogę kodu od commita do działającej aplikacji. CI (Continuous Integration, ciągła integracja) to nawyk częstego scalania zmian do wspólnej gałęzi, gdzie każda zmiana automatycznie uruchamia build i testy. CD oznacza albo Continuous Delivery (kod jest zawsze gotowy do wdrożenia, ale klikasz „deploy” ręcznie), albo Continuous Deployment (wdrożenie na produkcję dzieje się samo, bez człowieka). Skrót zostaje ten sam, więc warto dopytać, którą wersję ktoś ma na myśli.
Po co to komu
Zamiast zbierać zmiany tygodniami i robić jeden wielki, stresujący release, integrujesz małe kawałki na bieżąco. Maszyna (tzw. pipeline) po każdym git push sama pobiera kod, instaluje zależności, kompiluje, odpala testy, czasem skanuje pod kątem bezpieczeństwa, buduje artefakt (np. obraz Dockera) i wypycha go na kolejne środowiska. Dzięki temu błąd wychodzi w 10 minut po wprowadzeniu, a nie po dwóch tygodniach, gdy nikt już nie pamięta, co zmieniał.
Efekt: szybsze i częstsze wydania, mniej „u mnie działa”, mniej ręcznej roboty i powtarzalność — pipeline robi za każdym razem dokładnie to samo, niezależnie od humoru i kawy.
Przykład z praktyki
Najpopularniejsze narzędzia to GitHub Actions, GitLab CI i Jenkins. W GitHub Actions pipeline opisujesz w pliku YAML w katalogu .github/workflows/. Minimalny scenariusz dla Node.js: po pushu na main odpalasz testy.
on: push— wyzwalacz: każdy push do repo,runs-on: ubuntu-latest— maszyna, na której to leci,run: npm ci— instalacja zależności po lockfile,run: npm test— testy; jeśli zwrócą kod inny niż 0, pipeline świeci się na czerwono i blokuje merge.
Gdy testy przejdą, kolejny krok może zbudować obraz i zrobić docker push, a potem etap deploy wypchnie go na serwer.
Częste błędy i mity
Mit: „CI/CD = jakieś narzędzie”. Nie — to przede wszystkim praktyka. Możesz mieć Jenkinsa i nie robić CI, jeśli scalasz zmiany raz na miesiąc. Pułapka pierwsza: testy, które nikt nie pisze — pipeline bez sensownych testów to drogi sposób na szybsze wdrażanie bugów. Pułapka druga: sekrety (hasła, klucze API) wklejone na sztywno w pliku workflow zamiast w secret managerze — to wpada do repo na zawsze. Pułapka trzecia: mylenie Continuous Delivery z Deployment i obiecywanie szefowi automatycznej produkcji, gdy realnie masz ręczny przycisk.
Pojęcia powiązane
DevOps, pipeline, Docker, Kubernetes, Git, testy jednostkowe, build, artefakt, środowiska (dev/staging/prod), Infrastructure as Code.