Continuous integration and delivery (CI/CD)

CI (continuous integration) means automatically checking every change before integrating it. CD (continuous delivery or deployment) means getting that change into a real environment with no manual steps. Most teams gain more from good CI than from any other technical investment of the same cost.

What CI checks, and in what order

1. Fastest first: formatting and lint. Fails in seconds and keeps noise out of the review.
2. Compilation / type-check: if it does not build, nothing else matters.
3. Unit tests: the bulk of the confidence, should take a few minutes.
4. Integration and end-to-end tests: slower and more fragile; they go last and in parallel.
5. Production artifact build: if it is prerendered or bundled, let it fail here and not on the server.

Run times matter more than they seem

If the pipeline takes 25 minutes, people stop waiting for it: they merge before it finishes, pile up changes and lose the cause-and-effect link between a commit and its failure. A reasonable target is a CI answer in under ten minutes. You get there with dependency caching, parallelisation and not repeating work between stages.

Gates before production

Between "CI passes" and "it is in production" it is worth adding checks that are not code: an approved review, database migrations reviewed separately, and a way to roll back in a minute. Deployment should be boring; if it produces adrenaline, automation is missing.

• Reproducible deployment: the same artifact that was tested is the one that ships.
• Fast rollback: relaunching the previous version cannot depend on rebuilding anything.
• Post-deploy health: an automatic check that the service responds before the release is considered good.

Environments

At a minimum, an integration environment that resembles production (same services, anonymised data) where you test before releasing. Many teams avoid incidents just by having that environment and actually using it.