Why This Matters
Imagine a team of ten developers all pushing code to the same project. Without automation, someone has to manually run tests, check for conflicts, build the project, and deploy it. That process is slow, error-prone, and terrifying on a Friday afternoon.
CI/CD eliminates that fear. Continuous Integration means every push triggers an automated test suite. If something breaks, you find out in minutes, not days. Continuous Deployment takes it further: code that passes all tests is automatically shipped to production. No manual steps, no "deployment day" stress. This is how companies like GitHub, Netflix, and Shopify deploy hundreds of times per day.
Define Terms
Visual Model
The full process at a glance. Click Start tour to walk through each step.
The CI/CD pipeline: push triggers build, tests gate deployment, green builds ship automatically.
Code Example
// .github/workflows/ci.yml - GitHub Actions config
// name: CI Pipeline
// on: [push, pull_request]
// jobs:
// test:
// runs-on: ubuntu-latest
// steps:
// - uses: actions/checkout@v4
// - uses: actions/setup-node@v4
// with:
// node-version: 20
// - run: npm ci
// - run: npm run lint
// - run: npm test
// - run: npm run build
// package.json scripts that CI runs
const packageScripts = {
"lint": "eslint src/",
"test": "jest --coverage",
"build": "next build",
"deploy": "vercel --prod"
};
// A test that CI will run automatically
function add(a, b) {
return a + b;
}
// test file: add.test.js
// test("adds two numbers", () => {
// expect(add(2, 3)).toBe(5);
// expect(add(-1, 1)).toBe(0);
// });
console.log("CI runs these tests on every push");
console.log("If any test fails, deployment is blocked");Interactive Experiment
Try these exercises:
- Look at the
.github/workflowsdirectory in any popular open-source repo on GitHub. What steps does their CI pipeline include? - Create a simple GitHub Actions workflow that runs
npm teston every push. Push a failing test and watch the pipeline turn red. - Try adding a linting step to your pipeline. Does lint run before or after tests? Why might the order matter?
- Break a test intentionally and open a pull request. Notice how GitHub blocks the merge until CI passes.
Quick Quiz
Coding Challenge
Write a function called `runPipeline` that takes an array of step objects, each with `name` (string) and `pass` (boolean). Simulate running the pipeline: iterate through steps in order, logging each one. If a step fails (`pass` is false), stop immediately and return the string 'Pipeline failed at: <step name>'. If all steps pass, return 'Pipeline passed: <count> steps completed'. The log for each passing step should be '<name>: passed'.
Real-World Usage
CI/CD is the backbone of modern software delivery:
- GitHub Actions is the most popular CI/CD platform for open source. Every pull request triggers a workflow that builds, tests, and reports results.
- Vercel and Netlify deploy frontend apps automatically on every push to main — a preview URL is generated for every PR.
- Jenkins is the self-hosted workhorse used by enterprises for custom pipelines with hundreds of steps.
- Test suites as quality gates prevent broken code from reaching users. If tests fail, the merge button stays red.
- Trunk-based development relies on CI — developers push small changes frequently, trusting the pipeline to catch regressions.