Q: Explain your CI CD pipeline from code commit to production.
Walk through an end-to-end CI CD pipeline from code commit to production: shift-left security, automated unit and SAST testing, container build optimization, GitOps manifest synchronization with ArgoCD, and canary verification.
Want to master this scenario in a live sandbox? KodeKloud's Enterprise GitOps with ArgoCD & Kubernetes Rollouts covers this exact problem with hands-on terminal drills.
🛠️ Production Runbook & Step-by-Step Resolution
Direct Answer: Interviewers ask for your end-to-end CI CD pipeline from code commit to production to evaluate whether you view CI/CD as merely a build script or as an enterprise delivery platform with automated quality gates, security scanning, GitOps synchronization, and progressive delivery safety nets.
Developer Commit, Trunk-Based Git & Pull Request Trigger
Developers work on short-lived feature branches following trunk-based development. Opening a Pull Request triggers a GitHub Actions / GitLab CI workflow via webhooks, with branch protection rules enforcing status checks.
- Branch Protection: Requires >= 1 peer approval, branch up-to-date with main, and passing CI status checks.
- Fast Feedback Loop: Pipeline immediately posts build progress status back to the GitHub PR interface.
Continuous Integration: Linting, Unit Tests & Static Analysis
The CI runner checks out code and executes static quality checks in parallel: linter checks, unit tests with code coverage thresholds, and static application security testing (SAST).
# GitHub Actions CI job definition
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm run lint
- run: npm test -- --coverage --coverageThreshold='{"global":{"lines":80}}'
- uses: sonarsource/sonarqube-scan-action@v2- Code Coverage Gating: PRs fail automatically if test coverage falls below 80%.
- Secret Scanning: TruffleHog scans the commit diff to ensure no AWS keys or private tokens are leaked.
Container Build, Multi-Stage Caching & OCI Packaging
Once PR is merged to main, the release pipeline triggers. Docker BuildKit builds an immutable container image using multi-stage Dockerfiles and remote registry layer caching.
# Build and push immutable container image tagged with Git SHA
docker buildx build \
--cache-from type=registry,ref=ghcr.io/org/app:buildcache \
--cache-to type=registry,ref=ghcr.io/org/app:buildcache,mode=max \
--platform linux/amd64,linux/arm64 \
-t ghcr.io/org/app:${{ github.sha }} \
--push .- Immutable Tagging: Images are tagged strictly with the immutable Git commit SHA, NEVER with mutable tags like
latest. - Multi-Arch Builds: Compiles for both amd64 and arm64 architectures to support cost-effective AWS Graviton nodes.
Security Hardening: Vulnerability Scanning & Cosign Signing
Before the image is allowed near production, it must clear automated security gates: vulnerability scanning with Aqua Trivy and cryptographic signing via Sigstore Cosign.
# Scan image for critical CVEs and sign with Cosign
trivy image --exit-code 1 --severity CRITICAL,HIGH ghcr.io/org/app:${{ github.sha }}
cosign sign --yes ghcr.io/org/app:${{ github.sha }}- Vulnerability Gate: Pipeline halts if CRITICAL CVEs with available fixes are detected.
- Software Supply Chain Security: Generates a Software Bill of Materials (SBOM) using Syft and signs the image via Keyless OIDC.
GitOps Manifest Promotion & Staging Sync
The CI pipeline commits the new image tag to a dedicated GitOps repository managing environment Kustomize manifests. ArgoCD detects the Git commit and reconciles the staging cluster.
# CI updates the image digest in the GitOps repository
cd gitops-repo/environments/staging
kustomize edit set image app=ghcr.io/org/app:${{ github.sha }}
git commit -am "chore(release): bump staging app to ${{ github.sha }}"
git push origin main- Separation of Concerns: The CI runner does NOT have direct
kubectlaccess to production; deployments are pulled via ArgoCD. - Automated Staging Smoke Tests: ArgoCD syncs Staging; automated Postman/Cypress integration tests run against the staging endpoint.
CI CD Pipeline from Code Commit to Production Architecture Stages
End-to-end phase progression of the enterprise CI CD pipeline from code commit to production:
- Trigger & Shift-Left: Feature branch PRs trigger parallel linting, unit testing (>80% coverage), SonarQube quality gates, and TruffleHog secret scanning.
- Immutable Packaging: Merging to main builds multi-arch container images tagged with the exact Git commit SHA using Docker BuildKit remote caching.
- Security Gating: Aqua Trivy scans the image, blocking deployments on High/Critical CVEs; Syft generates an SBOM and Cosign signs the container.
- GitOps Reconciliation: The CI pipeline updates Kustomize manifests in a dedicated GitOps repo; ArgoCD reconciles the cluster state without external cluster credentials.
- Progressive Canary Delivery: Argo Rollouts executes a 10% -> 25% -> 50% -> 100% canary rollout, automatically rolling back if Prometheus detects HTTP 5xx spikes.
Senior hiring managers and bar raisers evaluate how you prioritize during outages. Avoid these common anti-patterns:
- Granting CI runners direct admin credentials to the production Kubernetes cluster If a CI runner is compromised via a malicious npm dependency, attackers gain full cluster-admin access; using GitOps (ArgoCD) keeps credentials internal.
- Deploying container images tagged with ':latest' instead of immutable commit SHAs Using :latest prevents reproducible rollouts, breaks rollback workflows, and causes different pods to run different code versions after restarts.
- Running database schema migrations concurrently with application canary deployments Breaking database schema migrations will immediately crash the remaining 90% of pods running legacy code; migrations must always be backward compatible.
- Failing to automate rollbacks based on real-time application metrics Relying on human engineers to spot latency regressions or 5xx spikes delays incident recovery, resulting in SLA violations.