Digital Product Engineering7.5 CI/CD Pipelines
VOL. VII · CH. 7.5 · SOFTWARE ENGINEERING

CI/CD Pipelines

The automated assembly line that turns a committed change into a live deployment.

DivisionDevOps
DifficultyIntermediate
Prerequisites7.4
Related7.6 7.8
2 min read · 367 words

7.5.1Definition

Continuous Integration (CI) automatically builds and tests (7.4) every proposed change as soon as it's pushed, catching problems before merge. Continuous Deployment/Delivery (CD) automatically ships a change to staging or production once it passes those checks, removing manual deployment steps from the release process.

7.5.2Why It Exists

Manual testing and manual deployment are both slow and error-prone at any meaningful team size or release frequency — a step forgotten once eventually causes a production incident. CI/CD exists to make verification and release entirely automatic and repeatable, so shipping a change is as fast and reliable as the pipeline that checks and deploys it, not dependent on someone remembering every manual step correctly.

7.5.3A Typical Pipeline

  • Trigger — a push or pull request automatically starts the pipeline, with no manual initiation required.
  • Build — the code is compiled/bundled, catching build-breaking errors immediately.
  • Test — the automated test suite (7.4) runs, blocking the pipeline on any failure.
  • Deploy — on success (and often only on the main branch), the change is automatically deployed to staging or production (7.8).

7.5.4Common Mistakes

  • No automated tests gating deployment, so CI/CD ships broken code just as fast and automatically as it would ship working code.
  • Flaky pipeline steps ignored or routinely re-run until they pass, training the team to distrust — and eventually ignore — pipeline failures altogether.
  • Deploying directly to production with no staging environment, removing the last chance to catch an issue before real users are affected.
  • No rollback plan if an automated deployment introduces a production issue.

7.5.5Best Practices

  • Never deploy on a failing or skipped test suite — treat CI failures as hard blockers, not warnings.
  • Deploy to a staging environment first, with production deployment gated behind a final check or approval.
  • Automate rollback (or design for fast, easy manual rollback) as part of the deployment pipeline itself, not as an afterthought discovered during an incident.
Real-World ExampleA typical Cloudflare Pages setup auto-deploys a preview build for every pull request and a production build on merge to main — CI/CD running invisibly in the background as a routine part of the git workflow (7.1) rather than a separate manual process.