CI/CD

CI stands for continuous integration: every change pushed to the repo is automatically built and tested. CD stands for continuous delivery (or continuous deployment): every passing change is automatically released to staging, and often to production. Together, CI/CD lets a team merge dozens of small changes per day with confidence.

Why It Matters

Before CI/CD, integration was a painful event: branches grew for weeks, then someone spent days reconciling them. Modern teams instead integrate continuously — small changes merge into main many times a day, each one verified by an automated pipeline. The cost of a single change is low, so feedback is fast and the blast radius of a bug stays small.

Pipeline Stages

A typical pipeline runs these stages in order, stopping on the first failure:

1. Lint and format — catch style issues and obvious mistakes
2. Build — compile the code, bundle assets, generate any artifacts
3. Unit tests — run the fast, isolated tests
4. Integration tests — exercise the seams between components
5. Package — produce a deployable artifact (binary, Docker image)
6. Deploy to staging — run the artifact in a staging environment
7. End-to-end tests — run a small set of full-stack checks against staging
8. Deploy to production — promote the same artifact to production

Each stage is independent and can be re-run in isolation, which makes failures fast to diagnose. The example shows the core control flow: run the stages in order, halt on failure.

Triggers

Pipelines run automatically on triggers:

• A push to a branch (run lint and tests)
• A pull request opened or updated (run the full pipeline against the merged result)
• A merge to main (run pipeline + deploy to staging)
• A tag like v1.4.0 (run pipeline + deploy to production)

This is configured in YAML files like .github/workflows/ci.yml or .gitlab-ci.yml.

Safe Deployment Patterns

Production deploys are not just "push the green button." Common patterns:

• Blue-green — keep two identical environments and flip a switch
• Canary — send a small percentage of traffic to the new version first
• Feature flags — deploy code in a dormant state, toggle it on later

All three give you a fast rollback path if something breaks.

Try It Yourself

• Modify the example so one stage returns False and watch the pipeline halt
• List the stages of a CI pipeline you have used (or seen on GitHub Actions)
• Sketch what should happen if the deploy stage fails: rollback, alert, both?