Designing a CI/CD Pipeline
Fast feedback for devs, immutable artifacts, separation of CI (build/test) from CD (deploy). Trunk-based + GitOps beats long-lived release branches.
Deep dive
Stages
- Pre-merge: lint, unit tests, security scans (SAST, dependency CVE) — must finish in <10 min or devs route around it.
- Build artifact once: container image tagged with commit SHA, signed (cosign), pushed to registry.
- Promote, don't rebuild: the same image flows from dev → staging → prod.
- Deploy: GitOps (ArgoCD/Flux) reconciles a Git-tracked manifest. Rollback = revert commit.
Quality gates
Smoke tests + canary analysis after each promotion. Prometheus-driven auto-rollback on SLO breach.
Real-world example
From productionA team rebuilt the same Maven project three times per deploy (dev/stg/prod). Builds were non-deterministic — one prod deploy shipped a slightly different artifact than what passed staging. Switched to build-once-promote-many with image SHA pinning in ArgoCD; reproducibility incident dropped to zero.
Interview questions
2 senior-levelQ1Why is build-once-promote-many important?▾
Guarantees the exact bits tested in staging are what runs in prod. Rebuilding per environment introduces drift from base image updates, dependency resolution, build-host differences. Combine with image signing and SBOM for supply chain integrity.
Q2GitOps vs push-based deploys?▾
GitOps makes desired state explicit and auditable — every change is a Git commit, rollback is git revert. Push-based is simpler initially but creates drift between cluster reality and source. For multi-cluster, GitOps wins decisively.
Common mistakes
Storing secrets in pipeline YAML.
End-to-end tests that gate every PR — slow, flaky, route around them.
Letting CI deploy directly to prod (couples deploy to commit time).
Trade-offs
GitOps adds a learning curve and tooling but pays off in compliance/audit.
Trunk-based requires strong feature-flag discipline.