What happens between push and live?
You write some code, run git push, and a few minutes later it's running in production, or a red X appears and it isn't. Somewhere in that gap sits "the pipeline," and for most beginners it's a black box: a magic conveyor belt that either works or yells at you. This article opens the box.
A CI/CD pipeline is just an automated sequence of steps that takes your code from a commit to running software, checking it at every stage. Nothing about it is magic. Once you can name the stages and explain why each exists, you'll be able to read any team's pipeline and debug it when it goes red.
Note: Who this is for: Beginners who've used Git but never built or really understood a pipeline. No prior CI/CD experience needed. We'll use GitHub Actions for the concrete example because it's free and ships with every GitHub repo, but the stages are identical in GitLab CI, Jenkins, CircleCI, and the rest.
The one-sentence definition
CI/CD is the practice of automatically building, testing, and delivering every change to your code, so that integrating and shipping software is a routine, low-risk, push-button event instead of a scary manual ritual.
Think of a pipeline like an airport security and boarding process for your code. Every passenger (a commit) goes through the same checkpoints in the same order, every time. No one skips screening because they're in a hurry. The whole system exists so that by the time a passenger reaches the plane (production), you're confident they're safe to fly.
| In the real world | In tech |
|---|---|
| 🎫 Check-in | Source: a commit triggers the pipeline |
| 🧳 Bag scanning | Build + automated tests |
| 🛂 Security checkpoint | Lint, security scans, quality gates |
| 🎒 Tagged, sealed luggage | A versioned, immutable artifact |
| ✈️ Boarding the plane | Deploy + release to production |
Every commit is a passenger; the pipeline is the airport.
CI vs CD vs Continuous Deployment
Three terms get used interchangeably and they shouldn't be. They're three stages of maturity, each building on the last.
| What it automates | Human still does | |
|---|---|---|
| Continuous Integration (CI) | Build + test every change, merged often | Decides when/whether to deploy |
| Continuous Delivery (CD) | Above + package + deploy to staging, ready to ship | Clicks 'approve' to release to prod |
| Continuous Deployment | Above + auto-release to prod if all checks pass | Nothing, fully automated |
Same acronym family, three distinct commitments. Each row assumes the one above it.
Continuous Integration is the foundation: every developer merges their work into the shared main branch frequently (at least daily), and every merge is automatically built and tested. The goal is to catch "it broke when our changes met" problems within minutes, not at the end of a painful multi-week "integration phase."
Continuous Delivery extends that: every change that passes is automatically packaged and pushed as far as staging, leaving production one approval click away. You could ship at any moment; a human just decides when. Continuous Deployment removes that last click, if every check is green, it goes live automatically. Most teams live happily at Continuous Delivery; full Continuous Deployment requires deep confidence in your tests.
Tip: The acronym "CD" is genuinely ambiguous, it means Delivery to some teams and Deployment to others. In an interview or a design doc, say which one you mean. It signals you know the difference.
The picture: the six stages
Almost every pipeline, in any tool, runs the same six stages left to right. Here's the whole flow:
This part is interactive in the original. Open the full version on TheSimplifiedTech
- Source: A push or pull request triggers the pipeline. The system checks out exactly the commit you pushed, nothing more, nothing less.
- Build: Turn source into something runnable: install dependencies, compile, transpile. If it won't build, the pipeline stops here and tells you.
- Test: Run the automated checks, linting, unit tests, integration tests, security scans. This is the quality gate. A failure here blocks everything downstream.
- Package: Bundle the built, tested code into a single immutable artifact, typically a container image or a versioned archive. This is the thing that will actually ship.
- Deploy: Push that exact artifact to an environment, usually staging first, and run smoke tests to confirm it actually starts and serves traffic.
- Release: Promote the same artifact to production, making it live for users. In Continuous Delivery this needs a click; in Continuous Deployment it's automatic.
Build once, deploy many, the rule that prevents disasters
Here's the single most important principle in the whole pipeline, and the one beginners most often get wrong: you build the artifact exactly once, and promote that identical artifact through every environment. You do not rebuild for staging and then rebuild again for production.
Why does this matter so much? If you rebuild for each environment, you can never be sure the thing you tested is the thing you shipped. A dependency could publish a new version between builds. A base image could change. You'd test artifact A in staging and ship a subtly different artifact B to production, and that gap is exactly where the "but it worked in staging!" outages come from.
Warning: The rebuild trap: If your pipeline runs the build step separately for staging and prod, you don't have a reliable pipeline, you have two pipelines that happen to look alike. Build once, tag it, store it in a registry, and deploy that same tagged artifact everywhere. What you tested is then provably what you shipped.
This is also why the Package and Registry stages exist as their own thing. The artifact gets a unique, immutable version (often the Git commit SHA), lands in a registry, and every later deploy just pulls and runs it. We go deep on this in Artifacts & Registries.
A real pipeline you can read
Enough theory. Here's a minimal but genuine GitHub Actions workflow. Drop this file into a repo and every push runs CI automatically. Read it top to bottom, each block maps to a stage from the diagram.
.github/workflows/ci.yml
name: CI
# Source stage: what triggers the pipeline
on:
push:
branches: [main]
pull_request:
jobs:
build-and-test:
runs-on: ubuntu-latest # a fresh machine, every run
steps:
# Check out exactly this commit
- uses: actions/checkout@v4
# Build stage: set up the toolchain
- uses: actions/setup-node@v4
with:
node-version: "20"
cache: "npm" # speed up repeat runs
- name: Install dependencies
run: npm ci # clean, reproducible install
# Test stage: the quality gate
- name: Lint
run: npm run lint
- name: Unit tests
run: npm test
# Package stage: produce the artifact
- name: Build
run: npm run build
Three things to notice. One: the on: block is the Source stage, it says "run this on every push to main and every pull request." Two: every run starts on a clean ubuntu-latest machine, so there's no "works on my laptop", it's a fresh, reproducible environment each time. Three: the steps run in order and the first failure stops the rest, exactly like the airport: fail screening and you don't reach the gate.
Tip: This is CI only, it builds and tests but doesn't deploy. That's the right place to start. Get a green checkmark gating every pull request first; add the deploy stages once your team trusts the tests. We build the full version step-by-step in the next article.
Why automate this at all?
If you've only ever deployed by hand, automation can feel like overhead. It isn't. The payoff compounds with every single commit for the life of the project.
- Consistency, the same steps run the same way every time. No forgotten command, no "did you remember to run the migrations?"
- Speed, feedback in minutes. A broken test is caught before the code is even merged, not discovered days later.
- Confidence, because every change is tested identically, shipping stops being scary. Scary deploys lead to rare, giant, risky deploys, the exact thing DevOps fights.
- Repeatability, a new teammate doesn't need a 12-step deployment wiki. They push code; the pipeline does the rest.
- An audit trail, every build, test result, and deploy is logged. When something breaks, you can see exactly what shipped and when.
Common mistakes that cost hours
- Rebuilding per environment. The cardinal sin. Build once, store the artifact, promote the same one. Rebuilding means staging and prod can silently differ.
- Tests that don't actually block. A test suite that runs but doesn't fail the pipeline (or that everyone ignores when red) is theater. A red pipeline must stop the line.
- Slow pipelines nobody waits for. If CI takes 40 minutes, people stop paying attention to it. Cache dependencies, parallelize jobs, and keep the feedback loop tight.
- Putting secrets in the workflow file. Never hardcode tokens or passwords in YAML, it's in your Git history forever. Use the CI tool's encrypted secrets store.
- Confusing 'deploy' with 'release.' Deploying puts code on a server; releasing exposes it to users. Conflating them makes safe rollout strategies impossible.
Takeaways
The whole pipeline in six lines
- A pipeline is an automated sequence: source → build → test → package → deploy → release.
- CI = build + test every change. CD = automatically deliver it, ready to ship.
- Continuous Deployment goes one step further: live automatically if all checks pass.
- Build the artifact ONCE; promote that identical artifact through every environment.
- The test stage is the quality gate, a failure must stop everything downstream.
- Automate it for consistency, speed, confidence, and a full audit trail.
Where to go next
You understand the stages, now build one with your own hands and watch a green checkmark gate a pull request for the first time.
- Your First CI Pipeline with GitHub Actions, the hands-on, copy-paste version of this article.
- Practice in the CI/CD lab, run pipeline commands in a real in-browser terminal.
- Deployment Strategies: Blue-Green & Canary, what the Release stage looks like when you do it safely.
Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.
Top comments (0)