CI/CD Pipelines: What to Automate First

CI/CD gets presented as a platform investment. In practice it's a sequence of small automations, each of which removes a specific recurring cost — and the early ones deliver most of the value.

Stage 1 — A build anyone can run

The first goal is that a clean checkout builds and runs with one documented command, on a machine that isn't the original developer's laptop. Until this is true, every later automation is built on sand, and onboarding a new engineer costs days.

Stage 2 — Tests and checks on every pull request

• Run the test suite, linting, and type checks automatically; block merge on failure.
• Keep it under ten minutes. A slow pipeline gets bypassed, and a bypassed pipeline protects nothing.
• Add dependency vulnerability scanning and secret detection here — they cost almost nothing and catch expensive mistakes.

Stage 3 — Automated deployment to a staging environment

• Every merge to the main branch deploys automatically to staging.
• Staging should be built the same way as production, from the same artifact; "works in staging" must mean something.
• Define environments in code so they can be rebuilt rather than repaired.

Stage 4 — Production deploys and fast rollback

• Deploy the exact artifact that passed the pipeline — never rebuild for production.
• Automate the rollback and practise it; rollback time matters more than deploy time.
• Add smoke tests after deploy, and automate the revert if they fail.
• Introduce feature flags so releasing code and releasing a feature become separate decisions.

How to know it's working

These four are the industry's standard delivery metrics, and they're a better description of engineering health than any velocity number.

• Deployment frequency — how often you ship, which tends to rise sharply once deploys stop being events.
• Lead time from merge to production.
• Change failure rate — the share of deploys causing an incident.
• Time to restore service after a failed change.