CI/CD-Interviewfragen 2026: Blaugrüne, kanarische und Feature-Flaggen

# Ideal CI pipeline stages (GitHub Actions example)
name: CI Pipeline
on: [push, pull_request]

jobs:
  # Stage 1: Fast feedback (< 2 min)
  fast-checks:
    steps:
      - lint         # code style
      - type-check   # TypeScript/mypy
      - security-scan  # pip-audit, npm audit, SAST
      - build        # compile/bundle

  # Stage 2: Tests (< 10 min)
  test:
    needs: fast-checks
    steps:
      - unit-tests      # fast, isolated
      - integration-tests  # with real DB

  # Stage 3: Quality gates
  quality:
    needs: test
    steps:
      - coverage-check   # fail if < 80%
      - performance-test  # detect regressions

  # Stage 4: Build artifact
  build-image:
    needs: quality
    steps:
      - docker-build
      - docker-push      # push to registry
      - container-scan   # Trivy vulnerability scan

Blue-Green Deployment:
  Blue environment: current production (v1.0)
  Green environment: new version (v1.1)

Steps:
  1. Deploy v1.1 to green (separate environment)
  2. Run smoke tests on green
  3. Switch load balancer to point to green
  4. Blue is now idle (keep for rollback)
  5. If issues: switch back to blue instantly

Benefits:
  - Zero downtime deployment
  - Instant rollback (flip load balancer back)
  - Can run full tests on green before switching

Drawback:
  - Requires 2x infrastructure cost
  - DB schema changes are tricky (must be backward compatible)

Canary Deployment: gradually shift traffic to new version

10% users → new version
   Monitor error rates, latency, business metrics
   If OK: increase to 25%, 50%, 100%
   If bad: route 100% back to old version

Tools:
  - Kubernetes: traffic splitting via Ingress/Istio
  - AWS: Application Load Balancer weighted target groups
  - Cloudflare: percentage-based routing

Canary vs Blue-Green:
  Canary: gradual rollout, real user testing, slower
  Blue-Green: instant switch, all-or-nothing

# Feature flags decouple deployment from release
# Deploy code → behind flag → enable for subset of users

# Simple feature flag
ENABLE_NEW_CHECKOUT = os.getenv("ENABLE_NEW_CHECKOUT", "false") == "true"

if ENABLE_NEW_CHECKOUT:
    return new_checkout_flow()
else:
    return legacy_checkout()

# Advanced: Unleash or LaunchDarkly
from unleash_client import UnleashClient

client = UnleashClient(url="https://unleash.mycompany.com")
client.initialize_client()

# Gradual rollout to % of users
if client.is_enabled("new-dashboard", context={"userId": user_id}):
    return new_dashboard()
else:
    return old_dashboard()

# Benefits:
# - Separate deployment from release
# - A/B testing built-in
# - Instant kill switch if issues
# - Roll out to % of users

Database migrations are the hardest part of zero-downtime deployments.

Pattern: Expand and Contract (3-phase deployment)

Phase 1: Expand (add new column, keep old)
  ALTER TABLE users ADD COLUMN email_v2 VARCHAR(255);
  Application writes to BOTH old and new column

Phase 2: Backfill
  UPDATE users SET email_v2 = email WHERE email_v2 IS NULL;

Phase 3: Contract (remove old column)
  Application reads from new column only
  ALTER TABLE users DROP COLUMN email;

Why not just ALTER TABLE in one step?
  - Large tables lock for minutes/hours
  - pg_repack or pt-online-schema-change for zero-downtime ALTER
  - Requires coordination with application deployment