Continuous integration, delivery and deployment

The problem CI solves

Picture five developers who each work on their own branch for three weeks. On merge day nothing fits together: the same files were changed in different ways, tests fail, and nobody knows whose change broke what. Teams used to call this "integration hell". Another old problem is "it works on my machine": code passes on one laptop but fails everywhere else because of a different setup.

Continuous integration (CI) fixes both. Developers merge small changes into the shared main branch often, at least daily. Every push triggers an automated build and test run on a clean machine, so problems show up within minutes, while the change is small and fresh in the author's mind. The team's first rule: keep main green (passing). If a build breaks, fixing or reverting it comes before any new work.

Delivery versus deployment

The letters CD have two meanings, and people mix them up:

Both need the same foundation: automated tests you trust, and a pipeline that deploys the same way every time.

The stages of a pipeline

A pipeline is the series of automated steps a change goes through. A stage is one group of steps with a clear job. A typical web app pipeline looks like this:

1. Checkout: fetch the exact commit that was pushed.
2. Install: download dependencies from the lock file (npm ci, pip install -r requirements.txt).
3. Lint: check style and catch simple bugs without running the code.
4. Test: run unit tests, then integration tests.
5. Build: compile or bundle the app, or build the container image.
6. Scan: check dependencies and the image for known vulnerabilities, and the code for leaked secrets.
7. Package and publish: push the artefact (a versioned image or package) to a registry.
8. Deploy to staging: a production-like environment, then run smoke tests (a few quick checks that the main pages and APIs work).
9. Approval: a person or an automatic check agrees to release.
10. Deploy to production: then watch the dashboards.

push → checkout → install → lint → test → build → scan → publish
                                                        ↓
                         production ← approval ← staging + smoke tests

Principles that make pipelines work

• Fail fast: run the cheapest, quickest checks first (lint, unit tests) so most mistakes are caught in a couple of minutes, and stop at the first failure.
• Pipeline as code: the pipeline definition is a file in the repository (a workflow YAML or a Jenkinsfile), reviewed in pull requests and versioned with the code.
• Build once, deploy many: build the artefact one time, then promote that same artefact through staging and production. Only configuration changes between environments.
• Fast feedback: aim for a pipeline that tells a developer the result in about ten minutes. Slow pipelines get ignored.
• Everything automated: a manual step in the middle is where mistakes and delays creep in.