CI/CD Introduction

What CI/CD actually means#

CI/CD is shorthand for three related but distinct practices:

• Continuous Integration (CI) — every developer merges (integrates) their code into a shared branch frequently, often several times a day. Each merge automatically triggers a build and a test run, so integration problems are caught within minutes, not weeks later during a painful "merge day."
• Continuous Delivery — every change that passes CI is automatically built into a deployable artifact and verified as ready to release, but a human still clicks the button to actually push it to production.
• Continuous Deployment — the next step past delivery: every change that passes all automated checks is deployed to production automatically, with no manual approval step at all.

The distinction between delivery and deployment trips people up constantly: delivery ends with a release candidate a human approves; deployment removes that human gate entirely. Both sit on top of the same CI foundation — you cannot safely do either without a solid, automated test suite running on every change first.

The pipeline stages concept#

A CI/CD pipeline is a sequence of automated stages that a code change passes through before it reaches users. A typical pipeline looks like this:

 commit/PR -> build -> test -> (approval) -> deploy -> monitor

• Build — compile the code, install dependencies, produce a deployable artifact (a binary, a Docker image, a bundled frontend, a zip of a PHP app).
• Test — run automated tests against that artifact: unit tests, integration tests, sometimes linting and static analysis. If anything fails, the pipeline stops here and the change never reaches deploy.
• Deploy — push the artifact to an environment: staging first, then production. Deployment strategy (all-at-once, rolling, blue-green, canary) determines how much risk a bad deploy carries.
• Monitor — after deployment, automated health checks and observability tools confirm the new version is actually behaving correctly in production, ideally with a fast rollback path if it isn't.

Each stage acts as a gate: a failure at any stage stops the pipeline and prevents a broken change from reaching the next stage. This is the entire point — the pipeline is a series of increasingly expensive-to-fail checkpoints, ordered so the cheapest, fastest checks (compiling, unit tests) run first and the most expensive ones (deploying to production) run last.

Why it matters#

Catching integration issues early. Before CI became standard practice, teams would work on long-lived feature branches for weeks, then face a miserable "integration hell" merging them all together at once — conflicting changes, incompatible assumptions, and bugs that only appear when two features interact. Running the build and test suite on every single commit means an integration bug is caught within minutes of being introduced, when it's cheap to fix and the author still has full context on the change.

Fast, reliable releases. Manual deployments are slow, error-prone, and stressful — someone has to remember the exact sequence of steps, and it's easy to skip one under pressure. An automated pipeline runs the exact same steps every time, which means deployments become boring, frequent, and low-risk instead of rare, high-stakes events. Teams practicing mature CI/CD routinely deploy multiple times a day; teams without it might deploy once a month, with each release carrying far more accumulated risk simply because it bundles far more change.

Fast feedback for developers. A developer who breaks the build finds out in minutes via a failed pipeline run and a notification, not days later when a teammate whose work depends on it finally pulls the branch and encounters the fallout.

Common mistakes#

• Treating CI as "just running tests" without also failing the build on lint/type errors — small consistency issues accumulate quietly.
• Skipping tests locally because "the pipeline will catch it" — this turns the shared pipeline into a slow, expensive local test runner and blocks the whole team when it goes red.
• No fast rollback strategy — automating deployment without a way to quickly revert a bad release just makes it easier to break production faster.
• Overly long pipelines that take 30+ minutes to give feedback — developers stop waiting for results and start merging blind, which defeats the purpose.