CI/CD Basics

Analogy categoryAnalogies

Introduction

CI/CD refers to a set of practices and automated pipelines that let teams integrate, test, and release code changes frequently and reliably. It reduces the risk and manual effort of shipping software by automating the steps between a code commit and a running production system.

🏏

Cricket analogy: CI/CD is like a franchise's net-practice-to-match pipeline — every new batting technique gets tested in nets (integrate/test) before being trusted in a real match (release) — reducing the risk of a raw technique failing under match pressure and cutting manual coaching intervention.

Explanation

Continuous Integration (CI) is the practice of automatically building and testing every change as soon as it is pushed, so integration problems are caught within minutes rather than accumulating over weeks. Continuous Delivery extends CI by ensuring that every change that passes the pipeline is automatically packaged into a release-ready artifact that could be deployed at any time — but the actual deployment to production still requires a manual approval or trigger. Continuous Deployment goes one step further and removes that manual gate entirely: every change that passes all automated checks is deployed to production automatically, with no human intervention. The three form a spectrum of increasing automation: CI (automated build/test) → Continuous Delivery (automated release, manual deploy) → Continuous Deployment (fully automated deploy).

🏏

Cricket analogy: CI is like every net session being immediately reviewed by a coach for technique flaws; Continuous Delivery is like a player being match-ready after nets but the captain still decides whether to field him (manual gate); Continuous Deployment is like an automatic selection algorithm that plays a fit-and-in-form player with no captain's sign-off at all.

Example

yaml

# Example CI/CD pipeline definition (GitHub Actions style)
name: CI-CD
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: npm ci
      - name: Build
        run: npm run build
  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test
  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        run: ./deploy.sh

Analysis

The pipeline above follows the standard build -> test -> deploy stage sequence: the build stage compiles or packages the application, the test stage runs automated tests against that build to catch regressions, and only if both succeed does the deploy stage run. Whether this counts as Continuous Delivery or Continuous Deployment depends entirely on whether the deploy job runs automatically on every successful merge to main (Continuous Deployment) or waits for a manual approval step (Continuous Delivery). Automating this sequence matters because it removes error-prone manual steps, gives fast feedback to developers when something breaks, and — when paired with a trunk-based or GitHub Flow branching strategy — allows a team to ship small, low-risk changes frequently instead of large, risky releases.

🏏

Cricket analogy: The pipeline mirrors nets (build) -> practice match (test) -> real fixture (deploy); whether it's Continuous Delivery or Continuous Deployment depends on whether the captain must approve the lineup or it's auto-selected on form; automating this gives players fast feedback and, paired with squad rotation, lets a team make small, low-risk changes each match instead of one big overhaul.

Key Takeaways

Continuous Integration automatically builds and tests every change to catch integration issues early.
Continuous Delivery automatically produces a release-ready artifact but requires manual approval to deploy.
Continuous Deployment automatically deploys every change that passes all checks, with no manual gate.
A typical pipeline follows the sequence build -> test -> deploy.
CI/CD reduces manual effort and risk, enabling frequent, reliable releases.