CI/CD — co to jest i jak działa?

Continuous Integration i Continuous Delivery to fundament nowoczesnego wytwarzania oprogramowania. Poznaj 8 etapów pipeline, strategie wdrożenia i DORA Metrics.

Czym jest CI/CD?

CI/CD to zestaw praktyk automatyzacji wytwarzania oprogramowania. CI (Continuous Integration) — każda zmiana kodu jest automatycznie budowana i testowana. CD (Continuous Delivery/Deployment) — kod po testach jest gotowy do lub automatycznie wdrażany na produkcję.

Przed CI/CD: merge odbywały się raz na tydzień, integration hell trwał dni, release był stresującym eventem. Z CI/CD: każdy commit jest automatycznie walidowany, deploy to rutynowa operacja. Elite performers wdrażają wiele razy dziennie.

Wiele x/dzień

częstotliwość wdrożeń u elite performers (DORA Metrics)

Poniżej 1h

Lead Time for Changes u najlepszych zespołów devops

0-5%

Change Failure Rate (% wdrożeń powodujących problemy) u elite

8 etapów pipeline CI/CD

Source / Trigger

Commit lub PR do repozytorium uruchamia pipeline

GitHub, GitLab, Bitbucketgit push → webhook → pipeline start

Build

Kompilacja kodu, instalacja zależności, bundlowanie aplikacji

Docker, npm/yarn, Maven, Gradledocker build, npm run build, mvn package

Unit & Integration Tests

Automatyczne testy jednostkowe i integracyjne — fail = pipeline stop

Jest, JUnit, Pytest, RSpecnpm test, pytest, mvn test

Code Quality & Security

Static analysis, lint, dependency vulnerabilities, SAST

SonarQube, Snyk, Dependabot, ESLintsonar-scanner, snyk test

Artifact / Image

Tworzenie deployable artifacts — Docker image, npm package, JAR

Docker Hub, ECR, Artifactory, npm registrydocker push, npm publish

Deploy Staging

Automatyczne wdrożenie na środowisko staging/pre-production

Kubernetes, Helm, Terraform, ArgoCDhelm upgrade --install, kubectl apply

E2E / Smoke Tests

Testy end-to-end na środowisku staging — weryfikacja działania jako całość

Cypress, Playwright, Selenium, k6npx cypress run, npx playwright test

Deploy Production

Wdrożenie na produkcję — z manualnym zatwierdzeniem (CD) lub automatycznie (CD Deployment)

ArgoCD, Flux, Spinnaker, manual approvalargo sync, kubectl rollout

4 strategie wdrożenia

Blue-Green Deployment

Dwa identyczne środowiska: Blue (produkcja) i Green (nowa wersja). Switch przełącza ruch. Rollback = przełącz z powrotem.

Zalety:

Zero downtime, szybki rollback

Wady:

Podwójne koszty infrastruktury

Canary Release

Nowa wersja dostaje stopniowo rosnący % ruchu (1% → 5% → 25% → 100%) z monitorowaniem metryk.

Zalety:

Minimalne ryzyko, real-world testing, automatyczne rollback

Wady:

Złożoność konfiguracji, potrzeba feature flags

Rolling Update

Stopniowa zamiana starych instancji nowymi — Kubernetes domyślnie. Część nowych + część starych przez czas wdrożenia.

Zalety:

Zero downtime, stopniowe, oszczędność zasobów

Wady:

Backward compatibility wymagana, trudny rollback mid-way

Feature Flags

Kod wdrożony na produkcję, ale funkcja wyłączona flagą. Włączana stopniowo lub dla wybranych użytkowników.

Zalety:

Oddzielenie deploymentu od releasu, A/B testing, ring deployment

Wady:

Techniczny dług jeśli flagi nie są sprzątane

DORA Metrics — jak mierzyć efektywność CI/CD?

Metryka	Co mierzy	Elite	High	Low
Deployment Frequency	Jak często wdrażasz na produkcję	Wiele razy dziennie	Raz dziennie — raz w tygodniu	Raz w miesiącu lub rzadziej
Lead Time for Changes	Czas od commitu do działającego kodu na produkcji	Poniżej godziny	1 dzień — 1 tydzień	Powyżej 6 miesięcy
Change Failure Rate	% wdrożeń powodujących degradację/rollback	0-5%	5-15%	Powyżej 30%
MTTR (Mean Time to Recovery)	Średni czas przywrócenia serwisu po awarii	Poniżej godziny	1 dzień	Powyżej tygodnia

FAQ — CI/CD

Co to jest CI/CD?

CI/CD (Continuous Integration / Continuous Delivery lub Continuous Deployment) to zestaw praktyk automatyzacji procesu wytwarzania oprogramowania. CI (Continuous Integration) — każda zmiana kodu jest automatycznie budowana i testowana zaraz po commitcie do repozytorium. CD/Delivery — kod po przejściu testów jest automatycznie przygotowany do wdrożenia (release candidate). CD/Deployment — kod jest automatycznie wdrażany na produkcję bez manualnej interwencji. CI/CD eliminuje 'integration hell' i przyspiesza dostarczanie wartości.

Jaka jest różnica między Continuous Delivery a Continuous Deployment?

Continuous Delivery — pipeline automatycznie buduje i testuje kod, ale wdrożenie na produkcję wymaga manualnego zatwierdzenia (jeden klik lub approval). To podejście daje kontrolę nad momentem wdrożenia. Continuous Deployment — każda zmiana która przechodzi wszystkie testy jest automatycznie wdrażana na produkcję bez żadnej manualnej interwencji. Wymaga bardzo wysokiej jakości testów i confidence. Większość firm stosuje Continuous Delivery z manualnym gate'em, nie pełne Continuous Deployment.

Jakie narzędzia do CI/CD?

Najpopularniejsze: GitHub Actions — zintegrowany z GitHub, prosta konfiguracja YAML, bezpłatny dla publicznych repo; GitLab CI/CD — wbudowany w GitLab, pełny DevOps platform; Jenkins — open-source, bardzo konfigurowalny, wymaga więcej setup; CircleCI — szybki, dobry DX, popularny w US startupach; Bitbucket Pipelines — jeśli używasz Bitbucket; ArgoCD/Flux — GitOps dla Kubernetes. Dla nowych projektów GitHub Actions lub GitLab CI/CD są zazwyczaj najlepszym wyborem.

Co to jest pipeline CI/CD?

Pipeline CI/CD to sekwencja zautomatyzowanych kroków które kod przechodzi od commitu do produkcji. Typowe etapy: 1. Source (commit trigger), 2. Build (kompilacja, bundlowanie), 3. Test (unit, integration, e2e), 4. Security Scan (SAST, dependency check), 5. Artifact (build image/package), 6. Deploy to staging, 7. Smoke/acceptance tests, 8. Deploy to production (z approval lub automatycznie), 9. Post-deploy monitoring. Każdy etap jest bramką — jeśli nie przejdzie, pipeline zatrzymuje się.

Jakie metryki mierzyć w CI/CD?

DORA Metrics (DevOps Research and Assessment): Deployment Frequency (jak często wdrażamy na produkcję), Lead Time for Changes (czas od commitu do produkcji), Change Failure Rate (% wdrożeń powodujących problemy), Mean Time to Recovery (średni czas przywrócenia serwisu po awarii). Elite performers: deploy wiele razy dziennie, lead time poniżej godziny, change failure rate poniżej 5%, MTTR poniżej godziny.

Czytaj dalej