CI/CD is the technical backbone of DevOps. It is the set of practices that automate the path from “code written by a developer” to “the application running in production”.
| Acronym | Name | In one sentence |
|---|---|---|
| CI | Continuous Integration | We merge and test the code often and automatically. |
| CD | Continuous Delivery | The tested code is always ready to be deployed (manual production release). |
| CD | Continuous Deployment | The tested code goes automatically to production. |
Without CI/CD, shipping software feels like moving house by hand: slow, tiring, and risky. With CI/CD, it is an automated conveyor belt: you put the code in at one end, the application arrives ready at the other.
🔧 Mini-exercise — Match each acronym to its definition: (1) CI, (2) Continuous Delivery, (3) Continuous Deployment.
(1) CI = frequent automatic merge + build + tests. (2) Continuous Delivery = always ready to deploy, manual button for production. (3) Continuous Deployment = automatic production release after successful tests.
Continuous integration means merging frequently every developer's code into a shared branch, and automatically validating each merge with a build and tests.
| Without CI | With CI |
|---|---|
| Everything is merged at the end of the month → painful large conflicts | Several merges per day → small, easy conflicts |
| Bugs are found late | Bugs are found in minutes |
| “It worked on my machine” | Reproducible build on the server |
Analogy: tidy the kitchen as you go (CI) rather than waiting until everything is dirty (“big bang” integration). The small frequent effort avoids the rare catastrophe.
🔧 Mini-exercise — A developer keeps their code for 3 weeks without merging, then attempts a large merge. Which continuous-integration principle did they ignore, and what consequence is likely?
They did not merge frequently. Likely consequence: a massive merge conflict that is hard to resolve, and bugs detected very late. CI recommends small, frequent merges.
The two “CD”s look alike but differ on a single point: who presses the production-release button.
| Continuous Delivery | Continuous Deployment | |
|---|---|---|
| Production release | Manual (a human clicks) | Automatic |
| Control | Final human decision | No intervention |
| Ideal for | Regulated sectors, planned releases | Mature teams, strong test coverage |
Continuous Delivery = the car is parked at the door, ready, keys in the ignition; you decide when to start. Continuous Deployment = the self-driving car starts on its own as soon as it is ready.
🔧 Mini-exercise — A bank wants every production release to be approved by a manager. Which “CD” should they choose?
Continuous Delivery: the pipeline makes the version ready automatically, but the production release remains a human decision (manager approval).
A pipeline is a sequence of automated steps (called stages) that turn source code into a deployed application. If a stage fails, the pipeline stops and the team is notified.
| Stage | Role | Example tool |
|---|---|---|
| Checkout | Get the code from Git | Git |
| Build | Compile / assemble | Maven, npm, javac |
| Test | Verify automatically | JUnit, pytest |
| Package | Produce a shippable artifact | .jar, Docker image |
| Staging | Deploy to pre-production | test server |
| Deploy | Release to production | server / cloud |
The “fail fast” principle: put the cheap, fast stages (compilation, unit tests) first. There is no point deploying if the code does not even compile.
🔧 Mini-exercise — In which order should you place these stages: Deploy, Build, Test, Checkout?
Checkout → Build → Test → Deploy. Get the code, compile it, test it, and deploy only if everything is green.
Let's follow the path of a single line of code fixed by a developer, Léa, in a web application.
Step-by-step walkthrough:
git push.v1.4.1.Compare: before CI/CD, this same fix would have required a scheduled production release, one evening, by hand, with the stress of “hope it works”. Here, it is a 6-minute routine.
🔧 Mini-exercise — At step 3, 2 tests out of 124 fail. What does the pipeline do, and does the version go to production?
The pipeline stops at the Test stage, notifies Léa, and does not deploy. Production stays on the previous stable version. That is the “fail fast” principle protecting production.
| Benefit | What it changes in practice |
|---|---|
| Fewer human errors | Repetitive tasks are scripted: no more forgotten steps |
| Fast feedback | You know in minutes whether a change breaks something |
| Frequent deployments | You can ship several times a day with confidence |
| Reproducibility | Every build is identical — no more “it works on my machine” |
| Traceability | Every change is recorded: who, what, when |
The more often you deploy, the smaller each deployment is, and therefore the less risky. It is counter-intuitive: deploying more often makes deployments safer, not more dangerous.
🔧 Mini-exercise — Give two reasons why deploying small changes 10 times a day is less risky than a single large monthly deployment.
Question 1: What does “CI” stand for?
a) Code Inspection
b) Continuous Integration
c) Container Initialization
d) Central Infrastructure
Answer: b) — Continuous Integration: frequent automatic merge and validation of the code.
Question 2: What is the difference between Continuous Delivery and Continuous Deployment?
a) None, they are synonyms
b) In Delivery the production release is manual; in Deployment it is automatic
c) Deployment does not run tests
d) Delivery deploys automatically
Answer: b) — Both prepare a ready version; only the production release differs (manual vs automatic).
Question 3: What happens if the Test stage fails in a pipeline?
a) The pipeline continues all the way to production anyway
b) The pipeline stops and the team is notified
c) The code is deleted from the repository
d) The pipeline restarts forever
Answer: b) — “Fail fast” principle: a failure stops the pipeline and triggers an alert; nothing goes to production.
Question 4: What is an artifact in a pipeline?
a) A bug introduced by mistake
b) The packaged result of a build (e.g. a .jar, an image)
c) A message in the logs
d) A user of the system
Answer: b) — The artifact is the deliverable produced by the build, ready to be deployed.
Question 5: Why does deploying often make deployments safer?
a) Because each deployment is smaller and therefore easier to diagnose and roll back
b) Because we remove the tests
c) Because the servers become more powerful
d) Because users do not notice
Answer: a) — Small frequent changes reduce the risk surface and make rollback easier.
A team is developing a Java application. Design (on paper / as a pseudo-pipeline) the stages of a CI/CD pipeline for this application, indicating for each stage: its name, its role, and what should stop the pipeline. Also specify whether you recommend Continuous Delivery or Continuous Deployment, and why.
| Order | Stage | Role | Stop condition |
|---|---|---|---|
| 1 | Checkout | Get the code from Git | Repository unreachable |
| 2 | Build | Compile with Maven (mvn package) | Compilation error |
| 3 | Test | Run the JUnit tests | A test fails |
| 4 | Package | Produce the .jar / image artifact | Packaging failure |
| 5 | Staging | Deploy to pre-production | Application startup fails |
| 6 | Deploy | Release to production | Manual validation refused |
Recommended choice to start: Continuous Delivery.
Rationale: until test coverage is mature, keep a human validation before production (Delivery). When the team trusts its automated tests, it can move to Continuous Deployment (automatic production release).
Expected diagram:
Lesson 04 — Deployment strategies: how to go from v1 to v2 in production without breaking the service (Blue/Green, Canary, Rolling…).
All rights reserved. Any reproduction, distribution, use or adaptation of this course, in whole or in part, is strictly prohibited without the prior written authorization of Dr. Haythem REHOUMA.
Course created by Dr. Haythem REHOUMA — Development and Deployment of Data Solutions