What are the stages of a CI/CD pipeline?

CI/CD Pipeline

By Nikola Pashov

InfrastructureMidcicd

What a Strong Answer Covers

• CI vs CD
• pipeline stages
• tool named.

Senior-Level Answer

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.

What Separates a 2/3 from a 3/3

Common Mistakes

• Treating CI and CD as synonymous—CI ends at artifact; CD covers deployment.
• Not mentioning artifact immutability—rebuilding from source per environment breaks reproducibility.
• Omitting security scanning as a pipeline stage.
• Not discussing automated rollback or observability gates after production deploy.

Follow-Up Questions

• What is the difference between Continuous Delivery and Continuous Deployment? — Delivery: every passing build is deployable, but production deploy requires human approval. Deployment: production deploy is fully automated after tests pass.
• How do you handle database migrations in a CI/CD pipeline without downtime? — Backward-compatible migrations first (add column, no rename/drop), deploy new code, then remove old schema in a follow-up migration after old code is gone.
• How would you implement automated rollback in a production deployment? — Monitor error rate and p99 latency post-deploy; if they breach SLOs within the bake window, trigger redeploy of the previous artifact version.
• Why should the same artifact be promoted through environments rather than rebuilt per environment? — Rebuilding is not reproducible—dependencies can change. The same image ensures what was tested in staging is exactly what runs in production.