CI/CD Pipelines: Automating Code Deployment

A School Website That Broke on Registration Day

Rohan and three classmates in the Class 8 IT club built a website for their school's annual sports day so that students could register for events online instead of standing in a queue outside the PT teacher's room. For two weeks the site worked well. Whenever someone found a bug, they fixed it on their own laptop, opened an FTP program, and manually copied the changed files onto the school's shared web hosting account. It felt simple: fix the code, upload the file, done.

The night before registration closed, Ananya fixed a bug in the "sibling discount" feature — younger siblings of participating students got 10% off the entry fee. She tested it on her own laptop, saw the right number appear, and uploaded the one file she had changed. She did not upload a second, smaller file that her fix quietly depended on, because she had forgotten she had touched it three days earlier and it slipped her mind at 11 p.m. The next morning, the first fifty students who tried to register saw a blank white page with the words "Internal Server Error." Nobody had checked the live site before students arrived, because "checking" meant one tired person eyeballing a page, not a machine verifying it. Registration opened forty-five minutes late, after Rohan spotted the complaints in the class WhatsApp group and manually re-uploaded the missing file.

Nothing about this story involves careless people. Ananya is a good programmer. The problem is structural: manual deployment asks a human to remember every file, in the right order, every single time, with no safety net that catches a mistake before real users see it. A team of four students felt this pain after two weeks. Real software companies push code changes dozens or hundreds of times a day, from teams of hundreds of engineers. At that scale, "remember to upload the right files" is not a plan — it is a guarantee that something eventually breaks in front of users. This chapter is about the engineering answer to that problem: a CI/CD pipeline, a machine-run sequence of checks and steps that stands between "I changed the code" and "users see the change," so that no broken commit reaches production because a human forgot one file at 11 p.m.

From Assembly Lines to Code: What "Pipeline" Actually Means

The word pipeline is borrowed from manufacturing. On a car assembly line, a chassis moves through fixed stations in a fixed order — welding, painting, engine fitting, quality inspection — and at each station, if something is wrong, the line stops right there instead of shipping a half-built car to a customer. Nobody re-decides the order of stations for each car; the sequence is fixed, automatic, and repeatable.

A software pipeline works the same way, except what moves through the stations is not metal but a commit — a saved, labelled snapshot of the codebase created by a version-control tool such as Git (you may already have used git commit and git push in earlier lessons on version control). Every time a developer pushes a commit to the shared repository, a pipeline tool wakes up and runs that commit through a fixed sequence of automated stages. Two formal terms describe what the pipeline actually does:

• Continuous Integration (CI): every commit is automatically combined ("integrated") with the rest of the team's code, built, and tested — immediately, not just once a week when someone remembers to check. The word "continuous" is doing real work here: it means this happens after every single push, not on a schedule.
• Continuous Delivery / Continuous Deployment (CD): once a commit passes every automated check, it is automatically prepared to go live. In Continuous Delivery, a human still clicks a button to actually release it to users. In Continuous Deployment, there is no button — a commit that passes every stage goes live by itself. These two are close cousins but not identical, and mixing them up is a common misconception we will return to below.

Put together, "CI/CD" names one automated pipeline with two jobs: catch broken code early (CI), and get good code to users quickly and safely (CD).

Tracing a Good Commit Through the Pipeline

Concepts are easiest to trust once you trace real code through them. Suppose Rohan's team writes a function for the sibling-discount feature, along with a test that checks it does the right arithmetic.

def apply_discount(price, discount_percent):
    return price - (price * discount_percent / 100)

def test_apply_discount():
    assert apply_discount(200, 10) == 180

Trace the arithmetic by hand first, the way you would check any formula: apply_discount(200, 10) computes 200 * 10 / 100 = 20, then 200 - 20 = 180. The assert statement checks that this equals 180 — it does, so the test passes silently (an assert that succeeds produces no output at all; it only speaks up when it fails).

Now watch what the pipeline does with this commit, stage by stage:

1. Commit stage. Rohan runs git push. The pipeline tool detects the new commit on the shared repository and starts automatically — no one has to click "run the pipeline."
2. Build stage. A clean, temporary computer (often a short-lived virtual machine) checks out the code fresh — not Rohan's laptop, which might have leftover files or a different Python version — installs the project's dependencies, and assembles a runnable version of the app. This step alone catches a whole category of bugs: code that only "worked" because of something already sitting on the developer's machine.
3. Test stage. The pipeline runs every automated test in the project, including test_apply_discount. Since 180 == 180, this test passes. If even one test among hundreds fails, the pipeline stops here — it does not proceed "mostly."
4. Deploy-to-staging stage. Because every check passed, the pipeline automatically copies the built app onto a staging server — a private copy of the live site, invisible to real students, where the team can click around and sanity-check the feature in a realistic environment.
5. Deploy-to-production stage. Only after staging looks right does the change reach the production server — the actual site that students and parents use to register. In a Continuous Delivery setup, a team member presses a "release" button to trigger this last stage; in Continuous Deployment, it happens automatically the moment staging is confirmed healthy.

Every one of those five stages ran without a human remembering to do anything except write the code and push it. That is the entire point.

When a Commit Breaks: Rohan's Bug and the Pipeline That Caught It

Now trace the version of events the pipeline is actually designed to prevent. Suppose, instead of a careful fix, someone on the team makes a one-character typo while editing the same function late at night:

def apply_discount(price, discount_percent):
    return price - (price * discount_percent / 1000)  # typo: 1000, not 100

Trace it the same way as before. apply_discount(200, 10) now computes 200 * 10 / 1000 = 2, then 200 - 2 = 198. But test_apply_discount still asserts the result equals 180. Since 198 != 180, the assertion fails, and the test framework reports an AssertionError naming exactly which test failed and what value it got instead of what it expected.

This is the moment the pipeline earns its keep. The Test stage does not report the failure and shrug — it stops the pipeline immediately. Stages 4 and 5 never run. The broken code is never copied to staging, and it is nowhere near the production server that students will hit tomorrow morning. The developer gets a notification — commonly an email or a message in the team's chat tool — naming the failing test, long before any student ever loads the registration page. Compare this to Ananya's actual FTP mistake: there, the "test" was one tired person eyeballing a page at 11 p.m., and the failure was discovered by fifty confused parents the next morning instead of by a machine within minutes of the push.

This is worth stating precisely, because it is the core engineering idea of CI/CD: a pipeline turns "hope the code works" into "prove the code works, automatically, before anyone downstream can be affected by it." The pipeline does not write better code than Ananya or Rohan; it simply refuses to let a specific, well-defined kind of mistake travel any further than the stage that catches it.

Five Stages, One Safety Net

The diagram below lays out the same five stages as one continuous flow, with the failure path from the traced example shown branching off the Test stage in red — this is exactly what happened to the buggy apply_discount commit above.

Continuous Delivery vs. Continuous Deployment — They Are Not the Same

Here is a mistake even confident students make: assuming "CI/CD" means every commit that passes tests goes live instantly, with no human ever looking at it. That is true only for Continuous Deployment. It is not true for Continuous Delivery, and most real organisations — including ones handling money or safety-critical systems — deliberately choose delivery over deployment for at least their most sensitive releases.

The difference sits entirely in stage 5 of the diagram above:

• In Continuous Delivery, stages 1–4 are fully automatic, exactly as traced above. But the pipeline stops after staging and waits. A human — often a release manager or the team lead — reviews what changed and then manually triggers stage 5. The system is always ready to deploy at the push of a button; a person still decides when.
• In Continuous Deployment, there is no waiting button. If a commit clears every automated stage, stage 5 fires on its own, and the change is live for real users within minutes of being pushed, with no manual approval step at all.

Neither one is "the correct CI/CD" — they are two different policies teams choose deliberately, trading speed against caution. A hospital's patient-records system is far more likely to use Continuous Delivery, keeping a human in the loop before anything touches production. A social media app's minor visual tweak is a more plausible candidate for full Continuous Deployment, where speed matters more than a manual sign-off on each tiny change.

Writing an Actual Pipeline Definition

So far the pipeline stages have been described in words. In practice, a developer writes them down as a configuration file that lives inside the project's own repository, so the pipeline's instructions are version-controlled just like the code. Here is what a real, minimal pipeline definition looks like, in the format used by GitHub Actions, a CI/CD tool built into GitHub:

name: CI Pipeline
on: [push]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run tests
        run: pytest

Reading this line by line: on: [push] tells the tool exactly when to wake up — on every push to the repository, matching the "Continuous" in Continuous Integration. runs-on: ubuntu-latest requests a brand-new, clean Linux machine for the Build stage, which is why leftover files on a developer's own laptop can never quietly make a broken commit "pass." Each entry under steps is one instruction executed in order: check out the code, install a specific Python version, install the project's dependencies, then run pytest, which is the tool that actually executes functions like test_apply_discount and reports pass or fail. If the pytest step exits with a failure — exactly as it would for the buggy discount_percent / 1000 commit — GitHub Actions marks the whole run as failed and, depending on the team's configuration, blocks that commit from being merged or deployed any further. Other widely used CI/CD tools, such as Jenkins and GitLab CI, follow the same underlying idea — a file of ordered steps triggered by a push — with different configuration syntax.

What Happens If a Bad Commit Slips Through Anyway

Tests catch the mistakes someone thought to write a test for. They cannot catch a bug nobody anticipated. So a mature pipeline also has a plan for the case where broken code passes every automated check and still reaches production. The standard tool for this is a rollback: since every deployment corresponds to an exact, labelled commit in version control, "undo the last deployment" simply means re-deploying the previous known-good commit through the same pipeline. Because the pipeline is automated and repeatable, a rollback is not a frantic manual scramble — it is the same Build, Test, and Deploy stages running again on an older, trusted snapshot of the code, usually completing in minutes. This is precisely why version control (Git) and CI/CD are taught together: the pipeline needs a well-labelled history of past commits to have anything to roll back to.

Why This Matters at Indian Scale

The sibling-discount bug affected one school's registration page for forty-five minutes. Scale the same underlying problem up to a system handling payments or transportation for hundreds of millions of people, and the cost of a manual mistake stops being an inconvenience and starts being a genuine crisis. Consider the kind of load the Indian Railways ticket-booking system faces the moment Tatkal booking opens each morning, with an enormous number of users hitting the same servers within the same few seconds — a context where a bad, untested deployment pushed live at the wrong moment could lock out real travellers during the one narrow window they have to book a ticket. Or consider a UPI-based payment app used for everyday transactions by a huge share of India's smartphone users: a single bad line of code reaching production without passing through automated tests first could, in principle, miscalculate an amount or fail a transaction for millions of people before anyone manually notices. This is exactly the class of risk a CI/CD pipeline is built to prevent — not by making developers infallible, but by refusing to let an untested change reach the systems that matter, regardless of what time of night it was written or how confident the author felt.

Where This Fits in the Software Development Life Cycle

Your CBSE Computer Science syllabus introduces the Software Development Life Cycle (SDLC) as a sequence of phases: planning, analysis, design, implementation (coding), testing, deployment, and maintenance. Traditionally these phases were pictured as one long straight line — the whole project moves through testing once, then deployment once, then years of maintenance. CI/CD does not remove any of those phases; it changes how often the last few repeat. Instead of "testing" and "deployment" being single events near the end of a long project, a CI/CD pipeline compresses testing and deployment into something that happens after every individual code change — potentially many times a day. Maintenance, in this model, is not a separate phase that starts after deployment; it is continuous too, because every bug fix is itself a new commit that goes through the same Build–Test–Deploy pipeline.

A Second Misconception: "CI/CD Is Just an Automatic File Uploader"

It is tempting, after seeing the deployment stages, to think a pipeline is essentially a fancy version of the FTP upload Rohan's team used, just automated. This misses the actual point. An automatic uploader that skipped the Test stage would have uploaded Ananya's incomplete fix exactly as fast, and exactly as broken — automation alone does not create safety. What made the traced example safe was not automation in general, but specifically the Test stage acting as a gate that later stages cannot bypass. A pipeline without automated tests is faster at shipping bugs, not safer. The value of CI/CD comes from combining automation with verification at every stage — build, then test, then a staging check — where each stage can refuse to let a broken commit continue to the next one.

Check Yourself

Work through these before reading the summary — they use the exact examples traced above.

1. A developer changes discount_percent / 100 to discount_percent / 10 by mistake and pushes the commit. Using apply_discount(200, 10), compute what the buggy function returns, compare it to the test's expected value of 180, and state which pipeline stage stops this commit.
2. Explain, in your own words, the one concrete difference between Continuous Delivery and Continuous Deployment — name exactly which stage differs and how.
3. A team's pipeline has no automated tests, only a Build stage. A broken commit that still compiles successfully is pushed. Will the pipeline catch it? Justify your answer using what the Build stage actually checks versus what a Test stage checks.
4. Explain why a rollback is fast to perform in a system that uses Git and CI/CD together, but would be slow and risky in a team that deploys by manually copying files over FTP.

Answers to check your reasoning: (1) 200 * 10 / 10 = 200, then 200 - 200 = 0; since 0 != 180, the assertion fails and the Test stage stops the pipeline before Deploy-to-staging or Deploy-to-production ever run. (2) In Continuous Delivery, stage 5 (Deploy to production) waits for a human to trigger it manually after staging looks correct; in Continuous Deployment, stage 5 fires automatically the moment staging passes, with no manual trigger. (3) No — the Build stage only checks that the code assembles and runs without crashing (for example, no syntax errors or missing imports); it has no way to know that apply_discount is supposed to return 180 for those inputs, because only a test that states the expected result can catch that. (4) With Git and CI/CD, every past deployment corresponds to an exact labelled commit, so "roll back" means re-running the same automated pipeline on an older commit — a repeatable, minutes-long process. With manual FTP uploads, there is no reliable record of exactly which files were live at which point, so undoing a bad deployment means a person trying to remember and manually re-upload the previous correct files, the same error-prone process that caused the original problem.

Summary

• A CI/CD pipeline is a fixed, automated sequence of stages — typically Commit, Build, Test, Deploy-to-staging, Deploy-to-production — that every code change must pass through before it can reach real users.
• Continuous Integration (CI) means every commit is automatically built and tested immediately after being pushed, not batched up and checked later.
• Continuous Delivery automates everything up to a human-triggered final release; Continuous Deployment automates the final release too. They are related but distinct, and real teams choose deliberately between them.
• The Test stage is what actually catches bugs like a typo that changes / 100 to / 1000 — tracing the arithmetic (198 instead of the expected 180) shows exactly why the assert fails and the pipeline halts before the change reaches staging or production.
• Automation alone (a Build stage, or a plain automatic uploader) is not the same as safety — safety comes from verification stages, especially automated tests, that later stages cannot bypass.
• A rollback re-runs the same pipeline on a previous, known-good commit, which is only fast and reliable because version control keeps an exact record of what that commit was.
• CI/CD does not remove any phase of the SDLC you study for CBSE; it compresses testing, deployment, and maintenance from single end-of-project events into something that happens automatically after every commit.

Think About It

Think about this: How would you explain ci/cd pipelines: automating code deployment to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.