design·lab

DevOps & platform

CI/CD Pipeline

Every push automatically builds, tests, and — if it earns it — ships itself to production.

✗ Problem

Shipping by hand, one nervous release at a time

No pipeline means a human runs every step — on their laptop, from memory, hoping they didn't skip one.

# release day (manual)
ssh prod-server
git pull                 // which branch again?
npm install && npm run build
// tests? ran them locally… yesterday
pm2 restart app           // fingers crossed
// works on my machine ¯\_(ツ)_/¯
Slow, inconsistent, and terrifying: "works locally" surprises, no repeatable record of what shipped, and so much release-day fear that teams ship once a month instead of daily.
✓ How it works

CI builds trust, CD ships it

CI (Continuous Integration): every push auto-runs Build → Test → Scan and packages an artifact/image. CD (Continuous Delivery/Deployment): that artifact is auto-deployed to Staging → Prod, behind gates.

stages:
  - build
  - test
  - deploy

test:
  script: npm test    # gate ✋

deploy:
  script: ./deploy.sh
  when: tests_passed
🔨 Build
compile & lint
↓
🧪 Test
unit + integration
↓
📦 Package
artifact / image
↓
🚀 Deploy
staging → prod (gated)

A pipeline is ordered stages — a failing stage stops the line; nothing downstream ever runs.

✓ See it live

Push a commit — watch the pipeline run

Each stage lights up in order. A failing test stops the line — later stages never run.

📥 Checkout
git clone
→
🔨 Build
compile
→
🧪 Test
unit + integration
→
📦 Package
build image
→
🚀 Deploy staging
auto
→
🌐 Deploy prod
gated

Idle — click a button to push a commit.

✓ Takeaway

Automate the path to prod

  • Fast feedback: know within minutes if a commit is broken, not days later.
  • Small, frequent releases beat big-bang deploys — smaller diffs, smaller blast radius.
  • Fail fast: a bad commit stops at the first failing gate; it never reaches prod.
  • Artifacts are immutable: build once, then promote the same image through staging → prod — never rebuild per environment.
  • CD pairs with GitOps for declarative, auditable deploys; tests come from TDD.
Back to all topics →