CI/CD Concepts - What Is Continuous Integration and Why It Matters

Status: Active
Last Updated: 2026-08-14
Category: CI/CD - Phase 1: CI/CD Fundamentals
Prerequisites: None
Time: 1 hour
Tags: ci-cd, continuous-integration, continuous-deployment, fundamentals, concepts

Summary

Continuous Integration and Continuous Deployment are the practices that turn "software we hope works" into "software we know works." This article explains what CI/CD actually means, how the build → test → deploy pipeline replaced manual release rituals, and what benefits and tradeoffs you accept when you automate your delivery workflow.

🎯 What You'll Learn

By the end of this article, you'll be able to:

✅ Define Continuous Integration, Continuous Delivery, and Continuous Deployment precisely
✅ Explain the build → test → deploy lifecycle
✅ Contrast traditional release workflows with modern automated ones
✅ Articulate the real benefits and honest tradeoffs of CI/CD
✅ Recognize which parts of a workflow belong in a pipeline vs. outside it

The Problem CI/CD Solves

Imagine the classic software release from the early 2000s:

Weeks of development on a branch
    ↓
"Integration day": merge everything at once
    ↓
Conflicts everywhere, nothing compiles
    ↓
Days of debugging the merge
    ↓
Manual testing checklist (partially skipped under deadline)
    ↓
Deploy by copying files to a server via FTP
    ↓
Something breaks. Roll back by... restoring from memory?
    ↓
Repeat next quarter

This is late integration: combining everyone's work rarely and painfully. Every problem surfaces at once, months after the code was written, when context is gone.

CI/CD inverts this:

Every developer merges small changes daily
    ↓
An automated system builds the project on every merge
    ↓
Automated tests run within minutes
    ↓
Failures surface while the code is fresh in someone's head
    ↓
Working builds flow automatically toward production

What Happens conceptually: instead of one giant risky event per quarter, you perform hundreds of tiny low-risk events. Risk is amortized. Feedback is immediate.

Continuous Integration Explained

Continuous Integration (CI) is the practice of merging every developer's working copy to a shared mainline several times a day, with each merge verified by an automated build and test run.

The three rules of CI:

Everyone commits to main frequently. Long-lived branches are where integration pain lives.
Every commit triggers an automated build + test. A machine, not a person, verifies the merge.
A broken build is the top priority. You do not build new features on a red pipeline.

A minimal CI loop looks like this:

# Conceptual — what a CI system does on every push:
on: push
steps:
  - install dependencies      # npm install / bun install / pip install
  - compile or lint           # tsc --noEmit / ruff check
  - run unit tests            # pytest / vitest / go test
  - report pass/fail          # badge, email, chat notification

What Happens when a commit lands: the CI server checks out your exact commit into a clean environment, runs the steps deterministically, and publishes the result. If step 2 fails, steps 3–4 don't run. You get a red X and a log link within minutes.

What CI Is NOT

❌ It does not catch every bug — only bugs your tests can express.
✅ It catches integration problems: broken builds, API mismatches, regressions, environment drift.
❌ It is not a substitute for code review — it's the floor beneath review ("does it even build/run?"), so humans can spend attention on design.

CD: Delivery vs Deployment

The two CDs get confused constantly. The difference is one decision:

                    ┌──────────────────────────────┐
   Commit ──► CI ──►│ Automated tests pass         │
                    └──────────────┬───────────────┘
                                   ▼
                     Artifact built & versioned
                                   │
              ┌────────────────────┴──────────────────┐
              ▼                                       ▼
   CONTINUOUS DELIVERY                  CONTINUOUS DEPLOYMENT
   Staging deploy is automatic;         Production deploy is also
   production needs a human             automatic. Green build on
   "Approve" button.                    main == live in production.

Practice	Deploy to staging	Deploy to production	Typical for
Continuous Integration	manual	manual	teams just starting automation
Continuous Delivery	automatic	manual approval	regulated products, cautious orgs
Continuous Deployment	automatic	automatic	high-trust pipelines, SaaS, homelabs

Rule of thumb: you earn continuous deployment by starting with delivery. If your pipeline has never deployed something broken to staging, you can consider removing the human gate to production.

Build → Test → Deploy

Nearly every pipeline, regardless of tool, decomposes into three stages:

Stage 1: Build

Transform source code into a runnable artifact.

# Examples of "build" steps
npm run build          # JS/TS bundle
go build ./...         # compiled binary
docker build -t app .  # container image

Key property: the artifact is immutable. You build once, then promote that same artifact through staging → production. Rebuilding per environment reintroduces "works on my machine."

Stage 2: Test

Verify the artifact before anyone depends on it, ordered fastest-and-cheapest first:

Lint/typecheck   (seconds)     fail fast — no point compiling further
Unit tests       (minutes)     pure logic, no network
Integration tests(minutes+)    needs a DB/Redis — spin up services
E2E/smoke tests  (tens of min) full running app, few critical paths

What Happens if you order it wrong: a typo fails a 40-minute E2E suite instead of a 10-second linter. Fast checks gate slow checks.

Stage 3: Deploy

Move the artifact to running infrastructure:

# Common deploy mechanisms (covered later in this course)
ssh server 'docker compose pull && docker compose up -d'   # compose host
kubectl set image deployment/app app=registry/app:v1.2.3   # k8s/k0s
git push production                                        # GitOps trigger

Traditional vs Modern Workflows

Dimension	Traditional	Modern (CI/CD)
Merge frequency	Rarely; feature branches live for weeks	Daily; branches live hours
When bugs found	Weeks later, in QA or prod	Minutes later, in the pipeline
Who tests	Dedicated QA at the end	Automated suite + humans on behavior
Release size	Big-bang quarterly	Small, continuous, reversible
Rollback	Restore backups, improvise	Redeploy previous artifact/tag
Release anxiety	High — ceremonies, war rooms	Low — releases are boring

The deep shift isn't tooling — it's that releases stop being events. In a mature pipeline, deploying is as unremarkable as saving a file.

Benefits and Tradeoffs

Benefits (real, measured)

Faster feedback loops. Bugs are cheapest minutes after they're written; CI finds them then.
Smaller blast radius. A diff of 50 lines is easy to reason about and revert; 5,000 lines is archaeology.
Reproducible builds. Pipelines run in clean containers, so "works on my machine" stops being an excuse.
Safer change culture. When rollback is one command, people ship improvements instead of hoarding them.
Institutional knowledge encoded as code. The deploy process lives in the repo, not in one admin's shell history.

Tradeoffs (honest ones)

Up-front investment. Pipelines, test suites, and environments take days-to-weeks to stand up before they pay off.
Tests become mandatory debt repayment. CI amplifies whatever test coverage exists — including zero. Automating deploys without tests automates breaking production.
New failure domain. Flaky tests, runner outages, and YAML bugs now block shipping. You must treat pipeline failures as first-class incidents.
Discipline requirement. Broken main must be fixed immediately; skipping that discipline makes the pipeline theater.
Self-hosted operational load. Running your own Forgejo/Woodpecker (this course's stack) means you patch, back up, and monitor it.

Which Parts Belong in a Pipeline?

Automate anything deterministic, repeatable, and boring:

✅ Compile, lint, typecheck
✅ Unit/integration tests
✅ Container image build + registry push
✅ Database migrations (with care)
✅ Deployments to staging

Keep human judgment calls outside (or as explicit gates):

👤 Product decisions ("is this feature right?")
👤 Production approval in regulated contexts (continuous delivery)
👤 Incident response during a failed rollout

Mental Model for the Rest of This Course

You are here
     │
     ▼
[concepts] → [Forgejo: your own GitHub] → [Woodpecker: your own Actions]
                                                       │
                              [build images] [run tests] [cache]
                                                       │
                                            [deploy: ssh/compose/k0s]
                                                       │
                                          [GitOps: ArgoCD reconciles]

Everything ahead is these concepts made concrete with self-hosted tools you own end to end.

🛠️ Troubleshooting & Common Issues

Even conceptual-stage CI adopters hit predictable walls:

Symptom	Root cause	Fix
Pipeline green but code still broken	Tests assert nothing meaningful	Write failing test first, watch it fail, make it pass
Team ignores red builds	No ownership rule	Adopt "broken main = drop everything"; assign fixer automatically
"Works locally, fails in CI"	Environment drift	Pin versions, replicate local setup with containers
Pipeline slower than manual deploy	Wrong stage ordering, no caching	Fail fast ordering + caching (see caching-strategies)
Fear of enabling auto-deploy	No confidence in tests	Stay at continuous delivery until pipeline earns trust

🔗 Related

Next: manual-vs-automated — the concrete cost/benefit case for automation
Also next: self-hosted-vs-cloud — choosing where your pipeline lives
Prerequisites elsewhere: kb/basics/git-fundamentals
Where this leads: woodpecker-introduction, gitops-principles

Change Log

2026-08-14 — Initial version written as part of the KB course build-out (cicd directory).