CI/CD Pipelines: From Commit to Production

A CI/CD pipeline automates the path from a code change to running software. Continuous integration (CI) builds and tests every change as it's merged, so problems surface within minutes. Continuous delivery keeps every passing build ready to release with one approval. Continuous deployment goes further and releases every passing build automatically. The design goal is to make releasing small changes so routine and safe that teams do it many times a day.

A typical pipeline

Continuous integration

• Merge small and often: short-lived branches (or trunk-based development) keep merges small and conflicts rare.
• Fast feedback: unit tests, linting and type checks run in minutes; slower suites run in parallel or later stages.
• Reproducible builds: pinned dependencies, hermetic build environments and caching, so the same commit always builds the same artifact.
• A broken main is an emergency: if the main branch fails, fixing or reverting it comes first, otherwise everyone's changes pile up untested.
• Security scanning: dependency vulnerability checks, secret scanning and static analysis catch issues before release.

Delivery vs deployment

Principles of safe delivery

• Build once, deploy many: promote the same immutable artifact through environments; never rebuild for production.
• Configuration separate from code: environment-specific settings come from config and secrets, not from different builds.
• Progressive rollout: canary or blue-green releases limit the blast radius. See deployment strategies.
• Automated verification: compare the canary's error rate and latency with the baseline and halt or roll back automatically.
• Decouple deploy from release: ship code dark behind feature flags and turn it on separately.
• Database migrations in compatible steps: expand (add columns, keep old ones), deploy code that handles both, then contract (remove old ones) in a later release, so rollback stays possible.
• Rollback is a button: redeploying the previous artifact must be quick and well practised.

Measure delivery with the DORA metrics: deployment frequency, lead time for changes, change failure rate and time to restore service. Fast and safe go together; teams that deploy more often usually have fewer failures, because each change is smaller.

Pipelines at scale

• Monorepos need build systems that only rebuild and test what a change affects.
• Shared pipeline templates let hundreds of services get the same stages and guardrails, which is a core part of an internal developer platform.
• Release windows and freezes are sometimes needed (peak sales days), enforced by the pipeline rather than by memory.
• Supply chain integrity: sign artifacts and verify signatures at deploy time so only images built by your pipeline can run.