CI/CD Fundamentals: What a Pipeline Really Does

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.

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.

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.

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.

The picture: the six stages

Almost every pipeline, in any tool, runs the same six stages left to right. Here's the whole flow:

1. 1

   Source

   A push or pull request triggers the pipeline. The system checks out exactly the commit you pushed, nothing more, nothing less.

2. 2

   Build

   Turn source into something runnable: install dependencies, compile, transpile. If it won't build, the pipeline stops here and tells you.

3. 3

   Test

   Run the automated checks, linting, unit tests, integration tests, security scans. This is the quality gate. A failure here blocks everything downstream.

4. 4

   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.

5. 5

   Deploy

   Push that exact artifact to an environment, usually staging first, and run smoke tests to confirm it actually starts and serves traffic.

6. 6

   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.

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.

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.

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

1. Rebuilding per environment. The cardinal sin. Build once, store the artifact, promote the *same* one. Rebuilding means staging and prod can silently differ.
2. 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.
3. 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.
4. 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.
5. Confusing 'deploy' with 'release.' Deploying puts code on a server; releasing exposes it to users. Conflating them makes safe rollout strategies impossible.

Takeaways

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.