What are the stages of a CI/CD pipeline?
A CI/CD pipeline automates the path from a code commit to a running production deployment, enforcing quality gates at each stage to catch issues early when they are cheapest to fix.
**Source trigger**: The pipeline starts on a push or pull request event from the version control system (GitHub, GitLab). Branch protection rules require the pipeline to pass before merge.
**Build**: Source code is compiled, transpiled, or containerised. The build artifact should be immutable and environment-agnostic—a Docker image tagged with the commit SHA, or a compiled binary. Build caching (layer caching for Docker, dependency caching for npm/pip) keeps this stage fast.
**Unit and integration tests**: Fast, isolated unit tests run first; slower integration tests (requiring databases, message brokers) run after or in parallel with test containers (Docker Compose, Testcontainers). Code coverage thresholds act as gates.
**Static analysis and linting**: Code style (ESLint, Black), type checking (mypy, TypeScript), and static security analysis (Semgrep, Bandit) catch issues without executing code.
**Security scanning**: Dependency vulnerability scanning (Snyk, Dependabot, Trivy for containers) and SAST (Static Application Security Testing) run here. Findings above a severity threshold block the pipeline.
**Artifact publishing**: The verified image or binary is pushed to a registry (ECR, Artifact Registry, PyPI) tagged with the commit SHA and semantic version. The artifact is immutable from this point—the same artifact is promoted through environments.
**Deploy to staging**: The artifact is deployed to a staging environment that mirrors production topology. Smoke tests and end-to-end tests run against staging. This is the last gate before production.
**Deploy to production**: In Continuous Deployment, this is automatic after staging passes. In Continuous Delivery, a human approval gate precedes it. Production deployments use progressive rollout strategies (blue-green, canary, rolling) with automated rollback on error rate or latency SLO breach.
**Observability gate**: After production deploy, the pipeline monitors error rates and latency for a bake window (5-15 minutes). Automated rollback triggers if thresholds are breached.
The key principle is **fail fast, fail early**—put the fastest and highest-signal checks first. A pipeline that takes 45 minutes to run is one that developers work around rather than wait for.
Names six or more stages in correct order with the purpose of each and mentions artifact immutability.
Covers all stages, explains the distinction between CI and CD, discusses progressive deployment strategies, automated rollback, and the fail-fast ordering principle.
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment