At one of my first jobs, releasing the app was a ritual. One person zipped up the build on their laptop, copied it to the server, and the rest of us watched. If everything worked, we went home. However, if it didn’t, we ordered food and stayed. I genuinely thought that was how every company shipped software.
It isn’t. Instead, the thing that replaced that ritual is what this post is about.
If you’ve heard “CI/CD pipeline” in standups, job descriptions, or YouTube comments and quietly nodded along, this is the plain-English version. No tool tutorials. No buzzword salad. Instead, you’ll get what the machine is, why teams built it, and the one distinction almost everyone gets wrong at the end.
Why Teams Built CI/CD in the First Place
Writing software alone is simple. You change whatever you want, whenever you want, and if something breaks, you know exactly who did it. You.
By contrast, put five people on the same codebase.
Three of them make changes that land cleanly. Meanwhile, two of them edit the same lines of the same file on the same afternoon. As a result, every developer on the team is asking the same uncomfortable question: how do I know your change didn’t break mine?
That one question is the reason CI/CD pipelines exist. Therefore, everything else in this post is the answer, built up one step at a time.
From Code to Users — How Software Actually Ships
Before CI/CD makes sense, you first need two ideas most beginners never see spelled out: code is not the product, and every change takes the same four-step trip.
Source Code Is Not the Product
Say a small team is building a food delivery app — call it QuickBites. They write twelve files and somewhere north of eleven thousand lines of code. After all that typing, a user still has nothing. You cannot hand someone a folder of JavaScript and call it dinner.
Instead, the code has to become something. Specifically, that step is the build: compile the source, bundle it, package it into one shippable thing. A zip. An installer. A .whl if you live in Python land, an APK if you’re shipping to Android. Thousands of files go in; one artifact comes out.
Ship that artifact, and only then does a user see anything at all — a webpage, a menu, a checkout button. They will never see your code. Instead, what they get is the build. That distinction sounds obvious once you hear it, but it changes how you think about everything downstream.
The Four Steps Every Change Takes
Every single change you will ever ship — a huge feature or a one-line fix to the checkout button — takes the same trip:
- Develop — write it, get it reviewed, merge it
- Build — turn the code into the app
- Test — prove nothing broke
- Release — put it in front of users
Four steps. Looks tidy on a whiteboard. However, this trip has to happen for every change, from every developer, every single time. Therefore, the real question becomes: who makes sure it actually happens, consistently?
How It Worked Before Automation
For most of software history, the answer was people. One person owned the build machine and built the app by hand. Another re-ran the test suite. A third ran the deploy scripts. Every arrow in that four-step diagram had a human standing on it.
And humans, being humans, forget steps. That is where “works on my machine” comes from — the build passed on one laptop and failed everywhere else, because two computers are never quite the same.
Furthermore, everyone waits on everyone. Releasing becomes slow and expensive, so teams do it rarely — once a month, once a quarter. When releases are rare, changes pile up into giant batches. And giant batches are exactly where your change and my change finally meet each other for the first time. In production. On release day.
That fear from the beginning of this post isn’t bad luck. Rather, the manual process manufactures it. That FTP ritual from my first job? That was our “release” step. One tired human, one zip file, and a lot of hope.
What CI/CD Actually Does
The fix was never “hire more careful humans.” Instead, the fix was taking humans out of the repetitive loop. That is literally what the letters mean.
CI and CD, Defined
CI — Continuous Integration. On every single change, a machine builds the code and runs the tests. Automatically. Not on someone’s laptop — instead, on a fresh, neutral machine that gets created for the run and thrown away after.
CD — Continuous Delivery. Meanwhile, the release path is automated too. Packaging the app, rehearsing the deploy, getting it ready for production — scripted, repeatable, boring in the best possible way.
Two acronyms. Four steps. Zero humans required between a commit and a tested, ready-to-ship app.
What Changes Once the Pipeline Exists
Once the pipeline is in place, something clicks. For example, five developers can merge all day long, and every commit — every merge — triggers the full run. Build, test, release-ready. Again and again. Fourteen times before lunch if that’s how the morning goes.
As a result, the shared code everyone builds on is always built, always tested, always green.
And now we can finally answer the question this post opened with. How do you know their change didn’t break yours? Because it couldn’t get in without proving itself. In other words, nothing gets in without proving itself. That is the entire promise of CI, delivered by a machine that never gets tired and never skips a step.
The Pipeline Is Just a Text File
Here’s the part that surprises people most. This machine I’ve been describing — it is not a product you buy or a server humming in a closet. Rather, it is a text file, sitting in your repository, right next to the code.
This is what a real one looks like, using GitHub Actions:
name: pipeline
on: [push]
jobs:
build-test-release:
runs-on: ubuntu-latest
steps:
- name: get the code
uses: actions/checkout@v4
- name: install dependencies
run: npm install
- name: build the app
run: npm run build
- name: run the tests
run: npm test
- name: publish to users
if: github.ref == 'refs/heads/main'
run: npm run deploy
Read it top to bottom and it’s almost English. When does it run? On every push. Where? On a fresh Ubuntu machine, not anybody’s laptop. What does it do? Get the code, install what it needs, build it, test it.
Additionally, look at that last step carefully. Publish to users — but only if this is the main branch. There is no human anywhere in this file. If a change is green on main, it ships itself.
In fact, twenty-four lines is all it takes. Jenkins, GitLab CI, and CircleCI are the same idea with a different filename.
Continuous Delivery vs Continuous Deployment
That last step — “it ships itself” — brings us to the distinction that trips up nearly everyone, including engineers with years of experience. After all, CD, annoyingly, stands for two different things.
Picture the moment after the tests pass. The change is built, tested, packaged, sitting there ready. The only thing left is “go.” So: who presses the release button?
If a human presses it, you have continuous delivery. Every change is always ready to ship, and a person picks the moment. Releases can queue up while the team decides — and that’s not a flaw. That is the point.
By contrast, if nobody presses it — if green means gone — you have continuous deployment.
Same pipeline. Same file, almost. One button apart.
Which Approach Fits Your Team?
Honestly, I think continuous deployment gets oversold to beginners. It sounds like the advanced mode, the thing real engineers graduate into. It isn’t. Instead, it’s a trade-off, and the right answer depends on what a bad release costs you.
For example, a web app? Deploy every commit. If something breaks, you roll it back in minutes and most users never notice.
Similarly, a mobile app? You get continuous delivery whether you like it or not — app store review sits in the path, and that is a button you cannot remove.
A bank? The human approval gate isn’t friction. It’s the feature.
Ultimately, the right pipeline matches the cost of a bad release. That single sentence will make you sound more senior in a design discussion than any tool name you could drop.
Putting It Together
So that’s a CI/CD pipeline. In short, it’s not a tool or a buzzword — every scary manual step between “code written” and “users have it,” automated, in roughly the order teams got burned by them.
Consequently, the next time you push code and that little checkmark turns green, you’ll know the journey behind it: the merge that proved itself, the build on nobody’s laptop, the tests that ran without being asked, and a release that’s either one button away or already out the door.
Common Questions
Is CI/CD the same as DevOps?
No. DevOps is the broader culture of developers and operations working as one team; CI/CD is one concrete practice inside it — probably the most visible one. However, you can adopt a pipeline without adopting everything else DevOps implies.
What is the difference between continuous delivery and continuous deployment?
One button. In continuous delivery, every change is automatically built, tested, and made ready — but a human decides when it goes to production. By contrast, in continuous deployment, there is no human step: any change that passes the tests ships automatically.
Is Jenkins a CI/CD pipeline?
No — Jenkins is a tool that runs pipelines. Instead, the pipeline itself is the set of steps you define — usually in a config file in your repo. Similarly, GitHub Actions, GitLab CI, and CircleCI play the same role.
Do I need to know CI/CD for coding interviews?
For most roles you won’t implement one in an interview, but the concepts show up constantly — in system design discussions, in behavioral questions about how your team ships, and in the classic “delivery vs deployment” check. Therefore, know the four steps and the one-button difference cold.
What does a CI/CD pipeline look like in practice?
Simply scroll up to the YAML example in this post — that 24-line file is a complete, real pipeline: build and test on every push, deploy automatically from the main branch.
Resources and Next Steps
Book a 1:1 session. If this distinction comes up in your interviews — it does, more often than you’d think — this is exactly the kind of thing I help people practice. Additionally, I’ve run 590+ sessions on Topmate covering mock interviews, system design, and career strategy. Book a slot →
More from me: all my resources · GitHub
Something you’d explain differently? Drop it in the comments — I read them.
