§ CAPABILITY

CI/CD Pipeline Implementation

A pipeline fast enough that people wait for it. Build time is a delivery constraint, and a twenty-minute pipeline changes how a team batches work whether anyone intends it to or not.

Who
Delivered by a senior team assembled for the engagement, against a defined scope.
Request a call How the work runs

What you're seeing

Engineers start something else while the build runs.
Usually means The pipeline has stopped being feedback and become an interruption. Past roughly twenty minutes people batch their changes to avoid waiting, and batching is what makes each deploy risky.
Red builds get re-run before anyone reads them.
Usually means The pipeline fails often enough for reasons unrelated to the code that failure has stopped carrying information. Everything it might catch is now uncaught.
A one-line change runs the entire test suite.
Usually means There is no selective execution. In a monorepo this is the single largest available saving, and it is usually left on the table because the dependency graph was never described.
The artefact is rebuilt for each environment.
Usually means What was tested in staging is not what ships to production. They are usually the same, and the times they are not are precisely the times it matters.

Build time is a delivery constraint

It is not developer comfort, and framing it that way is why it stays unfunded.

A slow pipeline makes batching rational. If a build takes twenty-five minutes, waiting for each small change is a bad use of an afternoon, so changes accumulate and ship together. Larger change sets are harder to review, harder to bisect when something breaks, and carry more risk per deploy. The pipeline’s speed has quietly set the team’s release size.

So the first step is measurement: where the minutes go per stage, and how often the pipeline fails for reasons unrelated to the code. Both numbers are usually a surprise to the people who built it.

Most of the saving comes from three places. Caching between runs. Running only what a change affects. And parallelising stages that were written sequentially because that was easier to reason about at the time.

Gates that mean something

Every blocking check needs a stated reason, and everything without one should not block.

The failure here is gradual. A check is added as advisory, someone makes it blocking because it kept being ignored, it starts failing for reasons unrelated to the change, and people learn to override. That habit is not confined to the check that taught it — once overriding is normal, the checks that genuinely mattered are being overridden too, and nobody notices because the pipeline still says it is enforcing them.

A short list of gates people respect is worth considerably more than a long list they route around.

Build once, promote the artefact

The same artefact moves through every environment, with configuration supplied externally.

Rebuilding per environment means the thing verified in staging is not the thing running in production. Usually they are identical. The occasions they are not — a dependency resolved to a different patch version, a build argument that differed, a cache that was warm in one place and cold in another — are precisely the occasions that produce an incident nobody can reproduce.

It also makes rollback cheap: promoting the previous artefact is a pointer change rather than a rebuild under pressure.

Where it sits

This capability sits under Platform Engineering, where the pipeline is the paved path itself, under Software Development where a build needs somewhere to run that its own team can operate, and under Engineering Velocity where build and review latency are frequently the largest measured items in the account of where time goes.

Two neighbours share the gate. QA & Test Strategy decides what the suite is responsible for and how long it may take. Release & Deployment Verification picks up after the deploy, which is the half of the path this one does not cover.

How the work runs

  1. Measure the current pipeline

    Where the minutes go, per stage, and how often the pipeline itself fails for reasons unrelated to the code.

  2. Cut the critical path

    Caching, parallelism, and cutting work that runs on every commit but only matters on some. Ten minutes is a working target; thirty changes team behaviour.

  3. Make the gates meaningful

    Every blocking check justified. A gate that is routinely overridden is worse than no gate, because it teaches overriding.

  4. Build once, promote the artefact

    The same artefact through every environment. Rebuilding per environment means the thing tested is not the thing shipped.

What arrives

  • A pipeline with build time under an agreed budget, enforced
  • Cached and parallelised stages with the dependency graph documented
  • Quality gates each with a stated reason for blocking
  • One artefact promoted across environments

What it costs your team

Around three hours a week from a lead engineer during setup, near zero afterwards.

Next step

Tell us where this is breaking and we'll say what it takes to fix.

Request a call

How we decide

  • Build time is treated as a delivery constraint with a budget

    Costs Holding a budget means occasionally rejecting a legitimate new step, or paying to make it faster.

    A slow pipeline does not cost the minutes it takes. It costs the context switch, and then it changes behaviour: waiting becomes irrational, so changes get batched, so each deploy carries more, so deploys get scarier. Ten minutes for the gate that blocks a merge is a working target; past twenty the behaviour change is reliable.

  • Every blocking check has a stated reason, and the rest do not block

    Costs It means demoting checks somebody added deliberately, and having that conversation with them.

    A gate that is routinely overridden is worse than no gate, because the habit of overriding transfers to the gates that mattered. Blocking is for things that must be true. Everything else is advisory, and advisory checks that block are how a team learns that the pipeline is negotiable.

  • One artefact is built once and promoted through environments

    Costs It requires configuration to be genuinely external, which some applications are not written to allow.

    Rebuilding per environment means the thing tested is not the thing shipped. They are usually identical, and the occasions they are not are exactly the occasions that produce an incident nobody can reproduce. Promotion also makes a rollback a pointer change rather than a rebuild.

Frequently Asked Questions

The automated path a change takes from being pushed to running in production: building it, testing it, checking it against whatever must be true, and deploying it. Continuous integration is the first half — every change verified against the mainline — and continuous delivery or deployment is the second.
Under ten minutes for the gate that blocks a merge. Past roughly twenty, engineers context-switch while waiting and start batching changes, which raises the risk carried by every deploy. The number matters less than the behaviour it produces, and the behaviour change around twenty minutes is very consistent.
Almost always three things: nothing is cached between runs, everything runs on every commit regardless of what changed, and stages that could run in parallel run in sequence. Measuring where the minutes actually go takes an afternoon and usually surprises the team that built it.
No. Blocking is for things that must be true — the suite passes, the security scan finds nothing critical, the build succeeds. Advisory checks that block get overridden, and the habit of overriding does not stay confined to them.
They make selective execution both necessary and possible: build and test only what a change actually affects. Without that, a monorepo runs everything for a one-line change and the pipeline gets slower with every service added. With it, a monorepo is frequently faster than the equivalent set of separate repositories.

Sources

Page reviewed