CI/CD
Continuous Integration / Continuous Deployment — automating testing and deployment. CI runs tests on every push. CD deploys passing code to production. CI/CD pipelines catch bugs early and ship faster, safer. GitHub Actions, GitLab CI, and CircleCI are common tools.
- Every project that deploys regularly.
- Teams wanting safe, frequent releases.
- One-person projects with no releases (overkill).
- Projects with no tests (CI is pointless without tests).
Definition
CI (Continuous Integration) merges code and runs tests automatically on every push. CD (Continuous Deployment/Delivery) deploys passing code to production (deployment) or stages it for manual release (delivery). Pipelines define build → test → deploy stages.
Why it exists
Manual testing and deployment is slow, error-prone, and risky. CI/CD automates the path from code to production, catching bugs early and enabling frequent, safe releases.
How it works
Push to git → CI triggers (build, lint, test). If tests pass → CD deploys (to staging or production). Pipelines are YAML files (.github/workflows, .gitlab-ci.yml). Stages: build, test, deploy. Environments: dev, staging, prod. Rollback on failure.
Scaling limits
Pipeline run time grows with test suite size (parallelize). Flaky tests block deploys. Secrets management. Cost of CI runners. Complex deployment strategies (blue-green, canary).
Cost shape
Free tiers (GitHub Actions). Paid for more runners/minutes.
Alternatives
- Manual deploy — Simple but slow and risky.
- Git push-to-deploy (Vercel/Netlify) — Easiest, but less control over testing.
Failure modes
- Flaky tests blocking deploys.
- Long pipeline run times.
- Deploying untested code.
- Secrets in logs.