CI vs Continuous Delivery vs Continuous Deployment
Beginner Core Git
Why this matters
"CI/CD" is said constantly and the two halves are different things, one of which is really two things. Knowing which is which tells you what happens after your change is merged, and how long it takes to reach the people who asked for it.
An analogy
Think of a shared kitchen preparing one large meal.
- Continuous integration is everyone bringing their part to the same table every few hours and checking it still works with everyone else's, rather than at the end of the day when the sauce turns out to be for a different dish.
- Continuous delivery is having every finished dish plated and ready to serve at any moment. Somebody still decides when to carry it out.
- Continuous deployment is the dish going out to the table the moment it is plated, with nobody deciding.
The difference between the last two is one human decision.
Continuous integration
What it means: everyone's work is merged into the shared branch frequently, and every merge is automatically built and tested.
What it prevents: the two-week branch that turns out to conflict with everything. Integration problems are found in minutes, when they are small, instead of in a fortnight, when they are a project.
What it requires: an automated test suite worth trusting, and small changes merged often.
What it looks like to you: the pipeline on your merge request. When it is green, your change works with everyone else's; when it is red, it does not, or the checks themselves are broken.
Continuous delivery
What it means: every change that passes CI is automatically built into something releasable, so the project is always in a shippable state. Releasing is then a decision, not a project.
What it requires: the build and packaging fully automated, and a staging environment where the result can be verified.
What it looks like to you: merged work appears on a staging site quickly, and a release is somebody pressing a button, often after a checklist that may well include your documentation.
Continuous deployment
What it means: every change that passes the pipeline goes to production automatically. No button.
What it requires: genuinely good automated tests, monitoring that notices problems, a fast rollback, and usually feature flags so unfinished work can be merged without being visible.
What it looks like to you: your merged change is live within minutes, and documentation has to be ready at merge time rather than at release time. That last consequence is the one that most affects a writer.
The difference in one table
| Continuous integration | Continuous delivery | Continuous deployment | |
|---|---|---|---|
| Automates | Build and test on every merge | Everything up to a releasable artefact | Everything, including going live |
| Human decides | When to merge | When to release | Nothing after merge |
| Needs | Tests, small changes | Automated packaging, staging | Strong tests, monitoring, rollback, flags |
| Your docs must be ready | Eventually | By release day | At merge time |
Which does my team do?
Three questions, in order:
- Does a pipeline run on every merge request? If yes, you have continuous integration.
- Does merging to
mainproduce something deployable automatically? If yes, at least continuous delivery. - Does merging to
mainput it in front of users without anyone pressing anything? If yes, continuous deployment.
The answer is visible in the configuration file: a job whose name mentions deploy or pages, with a rule limiting it to the default branch, is delivery or deployment depending on whether it needs a manual click (lesson 14.4).
How to do it
Nothing here is a Git command, but one command tells you what your project automates:
$ cat .gitlab-ci.yml
$ cat .github/workflows/*.ymlLook for job names and for rules, only, if or environment lines: they say what runs when, and where it goes.
The platform extensions show pipeline status in the status bar, which is the quickest way to see whether merging triggered a deployment or just a build.
The same status appears on the branch and in the merge or pull request window.
Build → Pipelines shows every run and what it did. Deploy → Environments exists only if the project deploys somewhere, and its presence is the fastest answer to question 2 above.
Actions for runs; Settings → Environments and the Environments panel on the repository home page for deployments.
Common mistakes
- Using "CI/CD" as one word for "the pipeline". It is understood, but it hides the question of what happens after merge.
- Assuming merged means live. It depends entirely on which of the three you have.
- Assuming continuous deployment means no review. The review is the merge request; the automation is what happens afterwards.
- Writing documentation for release day in a project that deploys on merge.
Try it yourself
Goal: work out which practice your project uses.
- Open your project's CI configuration file and list the jobs.
- For each, note when it runs: every push, merge requests only, the default branch only, tags only.
- Find any job that deploys something, and check whether it is automatic or manual.
- Answer the three questions in this lesson.
- Write one sentence: "when my change is merged, it reaches users by …".
Expected result: a sentence you could tell a colleague, and which tells you when your documentation has to be finished.
Show solution
Step 5 is the practical outcome. In a continuously deployed project, "I will document it next sprint" means the feature is live and undocumented for a sprint. Knowing which project you are in changes when your work has to be done.