Topic 0.1
Why CI/CD Exists
In one line
Continuous Integration catches problems the moment code is merged, by building and testing automatically — Continuous Delivery/Deployment extends that same automation all the way to actually shipping the result.
Think of it like this
A restaurant kitchen that tastes and checks every dish as it's being made, versus one that only finds out something's wrong when a customer sends a plate back — CI is the first kitchen: catching a problem the moment it's introduced, not days later after it's already reached someone.
Key ideas
- 01
Before CI/CD, a genuinely common real failure mode was 'integration hell' — several developers each work on their own branch for days or weeks, then merge everything together at once, discovering conflicts and breakages only at that late, painful moment, when the actual cause could be buried under dozens of combined changes.
- 02
CONTINUOUS INTEGRATION (CI) means merging code changes FREQUENTLY (ideally many times a day) with an AUTOMATED build and test running on every single merge — problems surface within minutes of being introduced, while the change is still small, recent, and fresh in the author's mind, rather than weeks later.
- 03
CONTINUOUS DELIVERY extends CI one step further: every change that passes its automated checks is automatically packaged into a genuinely deployable ARTIFACT, ready to release at any time — a human still decides WHEN to actually deploy it, but the artifact itself is always ready, with zero manual build steps standing in the way.
- 04
CONTINUOUS DEPLOYMENT goes one step further still: every change that passes its automated checks is deployed AUTOMATICALLY, with no human approval step at all — genuinely the fastest path from commit to production, and only safe with a real, comprehensive automated test suite that a team genuinely trusts to catch problems before they reach real users.
- 05
The one-sentence pitch you should be able to give in an interview: 'CI catches problems early by building and testing on every merge; Continuous Delivery keeps every passing change genuinely deployable; Continuous Deployment removes the human approval step entirely, shipping automatically the moment checks pass.'
Code & diagrams
Each stage builds on the one before it — CI is the foundation all of this sits on.
Explain it without notes
What specific problem did 'integration hell' cause, and why does merging frequently with automated checks prevent it?
What's the actual difference between Continuous Delivery and Continuous Deployment, given that both terms use the word 'continuous'?
Practice
Think of a real or hypothetical team merging changes only once a week. Write one sentence describing a realistic problem that infrequent merging specifically causes, that daily merging would have prevented.
Decide, for a hypothetical team with a genuinely strong automated test suite versus one with almost no automated tests, which one should reasonably adopt Continuous Deployment and which should stop at Continuous Delivery — and why.
Trade-offs
- ↔
Continuous Deployment is the fastest path from commit to production, but it puts enormous weight on the automated test suite genuinely catching real problems — a team without that level of test coverage adopting full Continuous Deployment anyway is trading a slower, safer manual gate for speed it hasn't actually earned yet, which is exactly why Continuous Delivery (automated up to the point of release, human-triggered from there) is the more common, more conservative real-world default.
Done when you can
I can explain what 'integration hell' was and why frequent merging with automated checks prevents it.
I understand the specific difference between Continuous Integration, Continuous Delivery, and Continuous Deployment.
I can reason about when Continuous Deployment is appropriate versus when Continuous Delivery is the safer choice.