What Is CI/CD?

Introduction

CI/CD is not a tool you install — it is a named delivery system that crystallizes decades of release engineering judgment. When you say "we need CI on every PR before CD," you compress an hour of whiteboarding into one sentence and align five engineers on gates, artifacts, and rollback in seconds.

This lesson reframes CI/CD as a communication and risk-management tool, not a Jenkins vs Actions shopping exercise. You will learn the four-part vocabulary every pipeline stage shares, the three delivery forces they balance, and when automating a stage earns its keep versus when it is premature toil.

The story

In a 2024 incident review at a fintech, two senior engineers spent forty minutes arguing about release process. One said "we should auto-deploy on green builds." The other said "no, that's reckless without scan gates." A third walked in, asked "is this a CI problem or a CD maturity problem?" — and the room reached agreement in three minutes. Same concern, different words, wasted time. Pipeline vocabulary won the argument that tool names could not.

The business problem

Teams without shared delivery vocabulary pay costs that show up in sprint metrics and incident reports:

• Velocity: every release means a manual checklist — features that should ship daily wait on hero deployers.
• Incident blast radius: untested merges reach production because verification is not continuous.
• Compliance & audit: no machine-readable record of what ran before prod — SOC2 reviewers ask for evidence you cannot produce.
• Onboarding drag: new hires re-propose manual deploy steps the team already rejected because judgment was never named.
• Review fatigue: senior engineers spend hours re-explaining release process instead of shipping.

The problem teams faced

Before teams adopt pipeline vocabulary, they hit the same pain on every project:

• Engineers reinvent the same deploy scripts with subtle bugs each time.
• Platform reviews stall because participants describe identical stages in different words.
• New hires take months to learn "how we release here" without searchable pipeline names.
• Senior deploy decisions vanish when the author leaves — nothing in the runbook, nothing in git.

Understanding the topic

Every pipeline stage documents four things. Memorize this structure — not YAML syntax:

• Trigger — the git event that starts work (push, PR, tag, schedule).
• Stages — ordered verification and packaging steps (build, test, scan, sign).
• Artifact — the immutable output promoted across environments (image digest, jar, bundle).
• Feedback — signals that pass or fail the pipeline and drive rollback (tests, metrics, alerts).

Internal architecture

Mature delivery systems balance three forces that appear in every production pipeline:

• Automate verification — integrate and test on every change; never merge untested code.
• Immutable artifacts — build once, promote by digest; never rebuild per environment.
• Reversible release — design rollback before auto-deploy; blue-green, revert, or GitOps undo.

Recurring release pain  →  Named pipeline stage  →  Documented gate  →  Measurable DORA outcome

Visual explanation

Three diagrams capture what CI/CD actually is. The first is the anatomy of any pipeline stage — the four parts you should recite in an interview. The second shows how a named pipeline turns recurring release pain into faster team decisions. The third is when to automate — Fowler's Rule of Three applied to delivery.

Informative example

Here is what CI/CD looks like in practice — not abstract boxes, but real seams in a checkout-service pipeline:

# CI — verify every change (Continuous Integration)
jobs:
  test:
    steps:
      - run: npm ci && npm test
      - run: npm run lint

# Artifact — build once, tag with git SHA
  build:
    needs: test
    steps:
      - run: docker build -t checkout:${{ github.sha }} .
      - run: docker push ghcr.io/acme/checkout:${{ github.sha }}

# CD — promote immutable digest (Continuous Delivery)
  deploy-prod:
    needs: build
    environment: production  # human approval gate
    steps:
      - run: kubectl set image deploy/checkout checkout@sha256:abc123...

# Continuous Deployment = remove approval when gates are strong enough

Each block marks a delivery boundary the business has already proven it needs. CI is the Problem (untested merges). Stages + artifact are the Solution. Pipeline maintenance and gate tuning are the Consequences — accepted deliberately, not by accident.

Execution workflow

Real-world use

CI/CD is everywhere once you know the stages. Etsy deploys hundreds of times daily with strong CI gates. GitHub Actions runs billions of workflow minutes monthly. Argo CD reconciles cluster state to git commits — rollback is `git revert`. Every mature team is a working pipeline dictionary — your job is to read it with vocabulary, not guesswork.

Production case study

A fourteen-person product team onboarded four engineers in one quarter. Releases slowed dramatically:

• Symptom: each new hire proposed a different deploy script — release threads grew 30%.
• Root cause: delivery judgment lived in one senior engineer's head, not in searchable pipeline docs.
• Decision: publish a one-page "how we ship" doc — each stage linked to one workflow file in the repo.
• Outcome: time-to-first-production-deploy dropped from 12 days to 5; change failure rate fell from 14% to 6%.
• Lesson: pipelines are infrastructure for human communication. The YAML is how you deliver; the stage names are how you remember.

Trade-offs

• Pro — Communication: compresses release discussion; aligns reviewers in minutes.
• Pro — Reuse of judgment: inherit decades of DORA and SRE delivery research.
• Pro — Onboarding: shared pipeline vocabulary shrinks the learning curve for new engineers.
• Con — Cargo-culting: teams copy YAML by name without re-validating the release force.
• Con — Premature automation: pipelines before the second manual deploy cost more than they save.
• Con — Tool drift: "GitHub Actions" in 2026 looks nothing like CruiseControl in 2006 — always explain the stage, not the vendor.

Decision framework

• Use CI when: more than one engineer merges to the same branch daily.
• Use CD when: artifacts are immutable and rollback is tested in staging.
• Use continuous deployment when: gates are strong, blast radius is small, and on-call can revert in minutes.
• Defer automation when: you have one service, one environment, and zero repeated deploy incidents.
• Defer automation when: the team cannot name the artifact being promoted — clarity debt will pile up.
• Defer automation when: compliance requires human sign-off that no gate can replace yet.

Best practices

• Name the release pain in the ADR before naming the pipeline stage.
• Use stage names as review shorthand — "this needs a scan gate" beats a twenty-comment thread.
• Write contract tests for deploy smoke checks before automating prod promotion.
• Promote by artifact digest, not by branch name or "latest" tag.
• Instrument deploy boundaries with metrics and traces — prove the gate behaves under load.
• Review pipeline git history quarterly; retire stages that never failed or never ran.

Anti-patterns to avoid

• Workflows named deploy.yml with no artifact, no rollback, and no owner — label without structure.
• Applying full CD pipelines uniformly when only CI is needed.
• Rebuild-per-environment left in place indefinitely instead of artifact promotion.
• Leaking prod credentials into PR workflows from untrusted forks.

Common mistakes

• Automating prod deploy during unrelated feature work without a rollback drill budget.
• Skipping characterization of manual deploy steps before encoding them in YAML.
• Letting pipeline files grow to 500 lines again after the initial cleanup.
• Debating Jenkins vs Actions in review without naming the release force first.

Debugging tips

• When prod differs from staging, diff which artifact digest each environment received.
• Use correlation IDs to trace a release from git SHA through deploy logs and metrics.
• If CI passes locally but fails in pipeline, suspect environment drift or missing secrets.
• Persistent manual deploy overrides mean the gate was placed incorrectly — revisit the force.

Optimization strategies

• Cache dependencies and Docker layers at the CI stage when wall-clock time blocks PR flow.
• Parallelize test shards only after CI is stable — flaky parallel tests amplify noise.
• Prefer reusable workflow modules over copy-paste jobs when the third service needs the same stages.
• Batch deploy windows only when the business requires it — not as a default substitute for CI.

Common misconceptions

• Many developers believe CI/CD means auto-deploy to production. In reality, Continuous Integration is universal; Continuous Delivery adds promotion; Continuous Deployment is optional maturity.
• Many developers believe pipelines eliminate release risk. In reality, they relocate risk to documented gates where teams can manage it deliberately.
• Many developers believe interviewers want tool trivia. In reality, they want pain → stage → trade-off stories tied to DORA outcomes.
• Related: CI vs CD distinction is the physics this lesson depends on — learn it next in this course.

Advanced interview questions

Summary

You now know what CI/CD is: named delivery structure for recurring release forces, not copy-paste YAML. You can draw the four-part anatomy, explain when the Rule of Three applies, and tell the fintech story that shows why pipeline vocabulary beats tool debates. Teach it to a colleague without notes — if you can do that, you own this lesson.