AtomLearnAtomLearn
DashboardGoalsPathAchievementsReviewSign In
DashboardCI/CDCI/CD Fundamentals
CI/CDNot Started

CI/CD Fundamentals

What CI/CD is, why every team uses it, and the vocabulary you need to get started

0%
Knowledge0%
Learn & Drill
Fluency0%
Drill & Speed
Retention0%
Mastery & Review
Confidence0%
All modes
Practice
Knowledge
Fluency
Retention

Knowledge Debt detected

You can study this freely — but your score may plateau if these foundations have gaps. The Mastery badge requires them to be solid.

Explanation

CI/CD stands for Continuous Integration and Continuous Delivery (or Deployment). It is the practice of automating the steps between writing code and putting it in front of users.

Without CI/CD:

  • Developer writes code → manually runs tests → manually builds → manually deploys → hope it works
  • Result: infrequent releases, big risky deployments, slow feedback on bugs

With CI/CD:

  • Developer pushes code → automation runs tests → automation builds → automation deploys
  • Result: small safe releases, bugs caught before users see them, multiple deploys per day

The two halves:

| Term | What it means | |------|--------------| | CI (Continuous Integration) | Automatically test and build every code change. The goal: always know the code works. | | CD (Continuous Delivery) | Automatically prepare every passing build so it is ready to ship. A human still clicks "deploy". | | CD (Continuous Deployment) | Automatically deploy every passing build — no human click required. |

The CI pipeline (what runs on every push):

Push code → Trigger pipeline → Install deps → Lint → Run tests → Build artifact ↓ (if all pass) Deploy to staging/prod

Key vocabulary:

| Term | Meaning | |------|---------| | Pipeline | The sequence of automated steps | | Job | A single step in the pipeline (e.g. "run tests") | | Runner | The machine that executes the job | | Artifact | The built output (Docker image, binary, zip) | | Trigger | What starts the pipeline (push, PR, schedule) | | Environment | Where code runs (dev, staging, prod) |

Benefits:

  • Speed: changes go from commit to deploy in minutes, not days
  • Safety: bugs caught in CI never reach users
  • Consistency: the same steps run every time — no "works on my machine"
  • Confidence: green CI means the code works, enabling fast review cycles

Popular CI/CD platforms:

  • GitHub Actions — built into GitHub, free for public repos
  • GitLab CI — built into GitLab
  • CircleCI, Travis CI — standalone services
  • Jenkins — self-hosted, highly customizable

Examples

The CI loop in practice

Every push gets automatic feedback — you know within minutes if you broke something, not days later.

git checkout -b feature/add-login
# write code...
git add .
git commit -m "feat: add login endpoint"
git push origin feature/add-login
# → CI pipeline triggers automatically

# Pipeline runs in the cloud (~2-3 minutes):
# 1. Checkout code
# 2. Install dependencies
# 3. Run linter
# 4. Run tests (pytest)
# 5. Build Docker image
# → All green? PR is safe to merge.
# → Any step fails? Developer notified immediately.

CI vs CD vs Continuous Deployment

Many teams use Delivery (not Deployment) — automated prep with human sign-off on production releases.

# Scenario: e-commerce team pushing a new feature

# CI (Continuous Integration) — runs on every PR push:
pytest --tb=short          # 180 tests pass
eslint src/ --max-warnings=0  # no linting errors
docker build -t app .     # image builds successfully
# Developer gets green checkmark on their PR

# CD (Continuous Delivery) — on merge to main:
docker push registry/app:sha-a1b2c3
# Artifact is tagged, ready to deploy to production
# A human clicks "Deploy to prod" in the dashboard

# Continuous Deployment (fully automated) — on merge to main:
# If all checks pass → automatically deploys to production
# No human approval needed
# Used by teams with high test coverage and confidence

How well did you understand this?

Next in CI/CD

GitHub Actions

Continue