What CI/CD Actually Is

What is it? #

Continuous integration means every change is automatically built and tested as soon as it is pushed. Continuous delivery means it is automatically prepared for release; continuous deployment means it is released without a human step.

The problem it solves is feedback delay. Without it, a broken change is discovered days later by someone else, and by then several changes are tangled together.

A pipeline is a sequence of automated stages. Each one either passes or stops the change from progressing.

The effect on how a team works is larger than the tooling suggests. When deploying is fast and reversible, changes become small and frequent, which is what makes them safe.

Think of it like this #

A production line with inspection points rather than one inspection at the end.

A fault caught at the second station costs a minute to fix. The same fault found after assembly means taking the whole thing apart, and by then five more were built the same way.

Simple example #

A developer pushes a branch. Within three minutes, linting, type checking and tests have run, a preview environment exists, and the pull request shows a green tick or a precise failure.

Code #

The pipeline

developer
   │  git push
   ▼
 GitHub / GitLab
   │  webhook triggers the pipeline
   ▼
 ┌─────────────────────────────────────────┐
 │  CI                                     │
 │   lint        code style and obvious errors  ~10s
 │   typecheck   type errors                     ~30s
 │   test        unit and integration tests      ~2m
 │   build       the deployable artefact         ~1m
 │   scan        dependency and image scanning   ~30s
 └──────────────┬──────────────────────────┘
                │ all green
                ▼
 ┌─────────────────────────────────────────┐
 │  CD                                     │
 │   deploy to staging                     │
 │   smoke tests against staging           │
 │   deploy to production (auto or manual) │
 │   health check                          │
 │   rollback automatically if unhealthy   │
 └─────────────────────────────────────────┘

The three terms, precisely

Continuous Integration    every push is built and tested automatically
Continuous Delivery       every passing build is ready to release;
                          a human presses the button
Continuous Deployment     every passing build is released automatically

Most teams practise CI plus continuous delivery. Full continuous
deployment requires high confidence in the test suite and fast rollback.

What changes when you have one

before                          after
------------------------------- -------------------------------
deploys are events              deploys are routine
large batches of changes        small changes, several a day
"it works on my machine"        one environment, one build
manual steps, sometimes missed  the same steps every time
breakage found days later       breakage found in minutes
rollback is improvised          rollback is a tested path

Pipeline speed matters more than it looks

under 5 minutes    developers wait for it and act on the result
5-15 minutes       they switch tasks; feedback loops lengthen
over 15 minutes    they stop waiting, batch changes, and merge on hope

Optimising pipeline time is optimising the team's feedback loop.

How it works #

A push triggers the pipeline through a webhook. The CI system checks out the code in a clean environment and runs the configured stages in order.

Stages are ordered fastest-first for a practical reason: linting failing in ten seconds is better feedback than the same change failing after a four-minute test run. Cheap checks act as a filter.

Each stage either passes or fails the pipeline. A failed stage stops progression, which is the mechanism that keeps broken changes out of the main branch.

Branch protection is what gives that teeth. Without a rule requiring the pipeline to pass, it is advisory, and someone will merge past a red build at some point.

The build stage produces one artefact — a container image, a bundle, a package. That same artefact is deployed to staging and then production, which is what makes staging meaningful.

The deployment stages include verification. A health check after deploying, with automatic rollback on failure, is what turns deployment from a hopeful action into a controlled one.

The speed table is worth taking seriously. Pipeline duration directly shapes behaviour, and a slow pipeline produces large, risky batches regardless of intent.

Real-world use #

GitHub Actions, GitLab CI, CircleCI and Jenkins all implement the same model with different syntax. The concepts transfer completely.

Teams typically start with CI only — tests on every push — which is the highest-value step and takes an afternoon.

Deployment automation follows, usually staging first. Automatic production deployment comes when the team trusts the tests and the rollback path.

The cultural effect is what people notice most. Deploying five times a day sounds risky and is safer than deploying monthly, because each change is small and the path is exercised constantly.

The pipeline is also documentation. It states exactly how the software is built, tested and deployed, which is more reliable than a wiki page that drifts.

Common mistakes #

• A pipeline that exists but is not required to pass before merging.
• Slow pipelines, which push developers back to batching changes.
• Building different artefacts for staging and production.
• Deploying with no health check or rollback path.
• Tests that fail intermittently, training everyone to re-run rather than investigate.

Practice #

Map your current path from commit to production, listing every step and marking which are manual. Then identify the single step whose automation would save the most time or prevent the most mistakes, and estimate how long the whole pipeline would take once automated.