CI/CD Course
What is CI/CD
In this lesson
CI/CD stands for Continuous Integration and Continuous Delivery (or Continuous Deployment). It is a set of practices that automates the process of taking code from a developer's machine to running in production — reliably, repeatedly, and without manual steps. Every time a developer pushes code, CI/CD builds it, tests it, checks it for security issues, and delivers it to the right environment automatically.
Before CI/CD existed, shipping software was a manual, error-prone ritual — checklists, SSH sessions, crossed fingers, and post-midnight deploys. CI/CD replaces that ritual with a machine that does the same steps correctly every single time.
Before CI/CD Existed
In the early 2000s, software teams worked in a pattern called waterfall development. Code was written for months in isolation, then everyone merged their work together at the end of a cycle — a painful event that teams called "integration week." It was rarely a week. It was usually two or three.
The problem was simple: the longer two pieces of code exist separately, the more they drift apart. Think of two people writing different chapters of the same book without talking for six months. By the time they try to combine the chapters, one named the protagonist "Alex" and the other named them "Alix," one set the story in London and the other in Edinburgh, and neither chapter connects to the other at all. Fixing it takes longer than writing either chapter.
Deployment had the same problem. Because releases were rare and risky, teams avoided them. Because they avoided them, releases grew larger. Because they grew larger, they became even riskier. The cycle fed itself until some teams were releasing once a quarter — and dreading it every time.
The Insight That Changed Everything
The Vaccination Analogy
A vaccine works by exposing your immune system to a small, controlled version of a threat — so when the real thing arrives, the response is fast and damage is minimal. CI/CD works the same way. Instead of one large, catastrophic integration at the end of a cycle, you integrate constantly in tiny doses. Each merge is a small exposure. Each automated test is the immune response. By the time anything reaches production, the system has already handled every kind of failure at small scale. The big scary release becomes a non-event.
The engineers who figured this out — particularly the Extreme Programming community in the late 1990s — made a radical suggestion: integrate constantly. Every developer merges their work into the shared codebase at least once a day. Every merge triggers automated verification. If something breaks, the team knows within minutes while the context is still fresh.
That idea — Continuous Integration — was controversial at the time. It felt risky. In practice it was the opposite: smaller, more frequent integrations are dramatically less risky than large infrequent ones.
What CI/CD Actually Means
CI/CD is made up of three distinct practices. Understanding the difference between them matters — especially between Continuous Delivery and Continuous Deployment, which are often confused.
The three practices — what each one means
Continuous
Integration
CI
Merge frequently. Verify automatically.
Every developer merges code at least daily. Every merge triggers an automated build and test run. Bugs are caught within minutes while the change is still fresh. CI keeps the shared codebase healthy at all times.
Continuous
Delivery
CD
Always deployable. Human decides when.
Every passing commit is automatically prepared for release — deployed to staging, tested end-to-end, ready to go live at any moment. A human still approves the production release, but it is a single click. Deployment becomes a business decision, not a technical ordeal.
Continuous
Deployment
CD
Every passing change goes live. Automatically.
No human approval step. Every change that passes all automated checks is deployed to production immediately. This requires extraordinary trust in the test suite and robust production monitoring. Teams like Netflix and Amazon deploy hundreds of times per day using this model.
A Day in the Life — With CI/CD
The best way to understand what CI/CD feels like is to walk through a normal working day on a team that has it running properly.
A normal Tuesday at a team with CI/CD
What a Pipeline Actually Looks Like
A pipeline is a sequence of automated stages. Each stage does one job. A failure in any stage stops everything — nothing broken advances. Think of it as a series of locked doors: to reach production, code must pass through every one.
📝
Code
Push triggers it
🔨
Build
Compiles
🧪
Test
Runs all tests
🔍
Scan
Security check
🚀
Deploy
Goes live
One failure at any stage stops the pipeline — nothing broken reaches the next door.
The Numbers That Made Organisations Pay Attention
For years, CI/CD was accepted on faith. That changed when researchers at DORA (DevOps Research and Assessment) measured the difference between teams that practised CI/CD and those that didn't — across tens of thousands of teams worldwide.
208×
more frequent deployments by elite teams vs low performers
2,604×
faster recovery from failures — hours vs months
7×
lower change failure rate — fewer broken deployments
50%
less time on unplanned work and rework
The most counterintuitive finding: teams that deploy more frequently have fewer failures — not more. Moving slower is not safer. Smaller, more frequent changes are fundamentally easier to verify, debug, and roll back.
CI/CD Is Not a Tool — It's a Practice
Installing GitHub Actions or Jenkins and creating a pipeline file does not mean you have CI/CD. A pipeline that teams bypass with "just this once" exceptions, that has tests which always pass because they test nothing, and that nobody looks at when it fails — that is a false pipeline. It gives the appearance of CI/CD without any of the substance. The tooling is five percent of the work. The discipline is the other ninety-five.
The CI/CD Checklist
Signs your CI/CD is genuinely working
Teacher's Note
Start with CI before anything else — get every merge triggering an automated build and test run. Once the team trusts it, add the deployment stages.
Practice Questions
1. The practice of merging code into a shared mainline frequently and automatically verifying the result with a build and test run is called what?
2. The CD practice where every change that passes all automated checks goes to production automatically — with no human approval — is called what?
3. A sequence of automated stages where a failure in any stage stops everything from advancing is called a what?
Quiz
1. A team merges all branches once every six weeks and describes the process as painful. What does CI specifically solve?
2. Every merge to main auto-deploys to staging and is tested end-to-end. Production requires a human to click Approve. Which practice is this?
3. A manager argues that deploying more often is riskier because there are more chances for something to go wrong. What does DORA research show?
Up Next · Lesson 2
Software Development Lifecycle
CI/CD fits inside a broader software development lifecycle. Understanding where the pipeline sits in the SDLC explains why certain pipeline decisions are made the way they are.