CI/CD Best Practices

Jakie są najlepsze praktyki CI/CD — od czego zacząć?

CI/CD (Continuous Integration / Continuous Delivery) to praktyki które automatyzują budowanie, testowanie i wdrażanie oprogramowania. Fundamenty dobrego CI: Trunk-Based Development: wszyscy developerzy commitują do jednego brancha (main/trunk). Krótko żyjące feature branches (max 1-2 dni) lub feature flags zamiast długich branchy. Eliminuje merge hell. Automatyczne testy przy każdym commit: unit tests (sekunde), integration tests (minuty). Fail fast — pipeline przerywa się natychmiast po błędzie. Build raz, deploy wszędzie: artefakt (Docker image) budowany raz w CI. Ten sam image promowany przez staging → produkcja. Nie buduj ponownie dla każdego środowiska. Deterministic builds: te same inputy zawsze dają te same outputy. Lock file (package-lock.json, Cargo.lock, go.sum). Hermetic builds (brak zewnętrznych deps w build time). Pipeline as Code: Jenkinsfile, .github/workflows, .gitlab-ci.yml. Wersjonowany razem z kodem. Peer review dla pipeline zmian. Dobre praktyki CD: Blue/Green Deployment — dwa identyczne środowiska, przełącz ruch. Canary Releases — stopniowe rollout (5% → 25% → 100%). Feature Flags — oddzielenie deploy od release. Automated Rollback — automatyczne cofnięcie przy alert. Database migrations — forward-only, backward compatible. Shift-left security — security checks w CI (SAST, dependency scan).

GitHub Actions, GitLab CI, CircleCI — jak wybrać narzędzie CI/CD?

GitHub Actions: natywna integracja z GitHub. YAML workflows w .github/workflows/. Marketplace — 10,000+ actions (reusable steps). Self-hosted runners dla custom environments lub speed. Free dla public repos, płatne minuty dla private. Matrix builds — testuj na wielu OS/wersji jednocześnie. OIDC — połącz z AWS/GCP/Azure bez long-lived credentials. Reusable Workflows — DRY dla pipeline definicji. GitLab CI: potężna platforma all-in-one (kod + CI + registry + deploy). .gitlab-ci.yml — YAML config. Stages i Jobs. GitLab Runners — shared (SaaS) lub self-managed. Include i extends — reuse configuration. Auto DevOps — automatyczny CI/CD pipeline z konwencji. Environments i review apps — deploy per branch automatycznie. Protected environments — wymagaj approval dla produkcji. CircleCI: szybkie, konfigurowalne. Orbs — reusable packages. Resource classes — wybierz CPU/RAM per job. Test splitting — rozdziel testy między N maszyn dla szybkości. Pipeline insights — analytics dotyczące pipeline. Jenkins: open-source, very customizable (ale wymaga dużo pracy operacyjnej). Groovy Pipelines (Jenkinsfile). Ogromny ekosystem pluginów. Dobre dla complex on-prem setup. Harness: enterprise-grade CD. AI-assisted deployment. Cost management, governance. Tekton (Kubernetes native): open-source, cloud-native CI/CD na K8s. Pipeline definicje jako Kubernetes CRDs. Używany przez Tekton Chains (supply chain security).

Testy w pipeline — jak strukturyzować i optymalizować czas?

Piramida testów w CI: Unit tests (baza): szybkie (ms), izolowane, dużo ich. Powinny kończyć się w sekundy. Integration tests (środek): testują integracje (DB, API, messaging). Minuty. E2E tests (szczyt): pełne flow użytkownika. Wolne (minuty-godziny), mało ich. Strategia optymalizacji pipeline: Fail fast ordering: unit tests najpierw (najszybsze), integration po, E2E na końcu. Parallel jobs: uruchom niezależne suity testów równolegle. Test splitting: rozdziel dużą suitę na N równoległych workerów (CircleCI, Nx). Caching: cache node_modules, Go modules, Maven dependencies między runami. Cache na podstawie lock file hash. Docker layer caching. Selective testing: uruchom tylko testy dotknięte zmianami (Nx affected, Bazel, TurboRepo). Test rezultaty i flaky tests: JUnit XML format — standard dla CI reporting. Flaky tests — losowo failing testy = erosja zaufania do CI. Wykrywaj i naprawiaj flaky tests priorytetowo. Test retry — retry N razy zanim fail (CircleCI, GitHub Actions). Quality Gates: code coverage minimum (np. 80%). Static analysis (SonarQube, CodeClimate). Linting i formatting (ESLint, Prettier, Black). Security scanning (Snyk, Trivy, Semgrep). Contract tests: Pact — consumer-driven contract tests. Testuj API kontrakt między producent a konsument bez full stack. Szczególnie ważne dla mikroserwisów i event-driven architecture.

Deployment strategies — Blue/Green, Canary, Rolling — jak wybrać?

Recreate: zatrzymaj starą wersję, uruchom nową. Downtime. Używaj tylko dla non-production lub mało krytycznych serwisów. Rolling Update: stopniowe zastępowanie instancji (N at a time). Kubernetes domyślna strategia. Zero downtime jeśli aplikacja backward compatible. Wada: przez chwilę działają obie wersje. Blue/Green: dwa identyczne środowiska (Blue = prod, Green = staging). Deploy na Green, przełącz ruch (DNS lub load balancer). Instant rollback — przełącz z powrotem na Blue. Wada: 2x infrastruktura, DB migration złożona. Canary Release: routing małego % ruchu (5%) do nowej wersji. Monitoruj metryki (error rate, latency). Stopniowo zwiększaj (5% → 25% → 50% → 100%). Automatyczny rollback przy degradacji. Implementacja: Kubernetes native przez Argo Rollouts lub Flagger. Nginx/Istio weighted routing. Feature Flags — nie deployment-level ale feature-level canary. A/B testing: podtyp canary — mierzysz conversion/engagement. Argo Rollouts: Kubernetes controller do zaawansowanych deployment strategies. AnalysisRun — automatyczna analiza metryk przy deployment. Flagger: progressive delivery operator. Integruje z Istio, Nginx, Linkerd. Automatyczne canary analysis. Deployment Frequency: według DORA — elite performers deployują wiele razy dziennie. Lead Time — czas od commit do produkcji (elita: poniżej godziny). Change Failure Rate — % deploymentów powodujących incident (elita poniżej 5%). Time to Restore — czas naprawy po incydencie (elita poniżej godziny).

Supply chain security w CI/CD — SBOM, podpisywanie artefaktów, Sigstore?

Software Supply Chain Security: ataki na pipeline CI/CD to rosnące zagrożenie (SolarWinds, Codecov, Xz backdoor 2024). SLSA Framework (Supply chain Levels for Software Artifacts): Level 1 — dokumentacja build process. Level 2 — signed provenance z CI. Level 3 — hardened build platform (isolated builds, ephemeral environments). Level 4 — hermetic, reproducible builds. Sigstore (CNCF): bezpłatna, open-source infrastruktura do podpisywania artefaktów. Cosign — podpisuj i weryfikuj Docker images. Rekor — transparency log (niemodyfikowalny audit trail podpisów). Fulcio — Certificate Authority (certyfikaty oparte na OIDC identity). Keyless signing — nie potrzebujesz long-lived keypairs — OIDC token z CI (GitHub Actions OIDC). Policy enforcement: Kyverno / OPA Gatekeeper w Kubernetes — sprawdź czy image jest podpisany zanim deploy. SBOM w CI: Syft — generuje SBOM z Docker images lub katalogów. Grype — skanuj SBOM pod kątem CVE. Trivy — container scanner + SBOM. Dependency scanning: GitHub Dependabot / Renovate Bot — automatyczne PR z aktualizacjami deps. Snyk — CVE scanning w CI. SAST (Static Application Security Testing): Semgrep, SonarQube, CodeQL (GitHub Advanced Security). Secret scanning: TruffleHog, GitGuardian, git-secrets — wykryj sekrety w kodzie przed push. GitHub secret scanning — automatyczne. Pre-commit hooks — ostatnia linia obrony przed push secretów.

Wyślij zapytanie