Why CI/CD? The Problem It Solves

CI/CD Pipelines

Chapter 1 · Why CI/CD? The Problem It Solves

🚀 Why CI/CD? The Problem It Solves

Every language course in this curriculum already taught you how to write tests — Go's testing package, Jest, RSpec, PHPUnit. This course isn't about writing more tests. It's about the fact that in most shops, actually running those tests before merging or deploying is still a manual step someone has to remember — and automating that step, and everything that follows it, is what CI/CD actually is.

The Manual Deployment Problem

A typical pre-CI/CD release process: a developer runs tests locally (or skips them "just this once" under deadline pressure), manually builds the app, manually copies files to a server — or worse, edits files directly on production — then manually restarts the service. Every one of these steps is a place for human error, inconsistency between environments ("works on my machine"), and forgotten steps exactly when there's least time to catch them.

📖 CI, CD, and Continuous Deployment

These three terms get blurred together in casual conversation, but the distinctions matter for understanding what a given pipeline actually promises:

Term	What It Actually Means
Continuous Integration (CI)	Every code change is automatically built and tested — catching integration problems early, not at release time
Continuous Delivery (CD)	Every passing build is automatically prepared for release (built, tested, packaged) — but a human still approves the actual deployment
Continuous Deployment	Goes one step further — every passing build deploys straight to production with no human approval step at all

Before and After

Manual Process

Remember to run tests, manually build, manually copy files to a server, manually restart — every step a chance to forget something under pressure.

Automated Pipeline

Push code → tests run automatically → build happens automatically → deployment proceeds (or waits for approval) automatically — no step depends on someone remembering it.

Why Automating Testing Specifically Matters Most

A test suite that only runs when a developer remembers to run it locally provides much weaker guarantees than one that runs automatically and blocks a merge or deploy on failure. This is the single most valuable, foundational piece of CI/CD — even before touching deployment at all.

What You Already Know

Writing tests themselves — covered across the Go, Node.js, Express, and TypeScript courses. This course assumes that skill and builds automation around it.

Where This Course Ends Up

By Chapter 9's capstone: a full pipeline that builds, tests, containerizes, and deploys an app to staging and production with an approval gate.

💻 Coding Challenges

Challenge 1: Classify Three Pipeline Descriptions

For each of (a) "every PR runs the test suite automatically," (b) "every passing build is packaged and a team lead clicks Deploy," and (c) "every merge to main goes live within minutes with no human involved," identify whether it describes CI, Continuous Delivery, or Continuous Deployment.

Goal: Practice distinguishing the three terms in realistic descriptions, not just definitions.

→ Solution

Challenge 2: Identify the Manual-Process Failure Mode

A team's release process requires a developer to manually SSH into a production server and run a deploy script. Identify at least two distinct failure modes this manual step introduces, referencing this chapter's own examples.

Goal: Practice recognizing concrete risks in a manual process, not just labeling it "risky."

→ Solution

Challenge 3: Decide Whether Continuous Deployment Fits

A small internal tool used only by 5 employees has a solid automated test suite. Discuss whether Continuous Deployment (no human approval before production) is a reasonable choice here, using this chapter's definitions.

Goal: Practice reasoning about when the strongest form of automation is actually appropriate, not just "the most advanced" option.

→ Solution

⚠️ Gotcha: "We Have CI" Doesn't Mean "We're Safe"

CI only automates running whatever tests already exist — it does nothing to improve the quality or coverage of a weak test suite. A pipeline that runs zero or trivial tests and reports "passing" gives a false sense of safety that can be worse than knowing tests aren't automated at all, since a green checkmark now implies a confidence that isn't actually earned. CI/CD automates test execution, not test quality — the two are easy to conflate, and conflating them is a genuinely common, costly mistake.

🎯 What's Next

With the terminology and motivation established, the next chapter breaks down the actual structure every pipeline shares: Anatomy of a Pipeline — stages, triggers, jobs vs steps, and a pipeline as a dependency graph.