Building a CI/CD Pipeline That Doesn't Slow You Down
A pipeline that takes forty minutes and fails for unrelated reasons half the time doesn't make your releases safer. It makes engineers merge without waiting for it, or stop trusting a red build enough to investigate before overriding it, which defeats the entire point of having one.
Here's how to build a pipeline people actually rely on, not just one that technically runs.
What actually belongs in the pipeline versus a pre-commit hook
Anything fast enough to run before a commit (formatting, a quick lint pass, a narrow set of unit tests) belongs there, not in CI, because catching it locally is faster for the engineer and cheaper for your build infrastructure. CI should handle what genuinely needs a clean, consistent environment: the full test suite, integration tests against real dependencies, and the build itself.
Teams that push everything into CI end up with a slow pipeline that's really running local-sized checks at cloud speed. Moving the fast stuff earlier is often the single biggest speed win available, and it costs nothing but a pre-commit hook.
Keep the build fast, or people stop trusting it
Once a pipeline regularly takes long enough that engineers start something else while waiting, they stop watching it closely, and a real failure gets missed or merged around instead of investigated. There's no universal target time, but if your team routinely merges before the pipeline finishes, that's the signal your current speed isn't working, regardless of what any benchmark says it should be.
Parallelizing test suites and caching dependencies between runs are usually the two changes that make the biggest difference, and both are worth doing before reaching for a bigger, more expensive runner.
Where deployment frequency actually comes from
Deployment frequency isn't really a CI/CD metric on its own, it's a downstream effect of how much of the release process still requires a human to decide and act. Teams in DORA's fastest-deploying cluster ship on-demand deployments, sometimes multiple deploys a day, while teams in its slowest cluster might go as long as 180 days between deployments1. The gap between those two isn't really about tooling sophistication, it's about how much of the path from a merged change to production still needs someone to manually decide it's safe.
Automating the deploy step itself, behind feature flags and real test coverage, is what actually moves a team along that range, not a faster pipeline alone.
Test flakiness is a pipeline problem, not just a testing problem
A test that fails intermittently for reasons unrelated to the actual change trains engineers to re-run the pipeline instead of investigating red builds, which is functionally the same as not having that test at all. Track flaky tests specifically, separate from genuine failures, and treat a consistently flaky test as a bug in the pipeline's reliability, not a minor annoyance to route around.
A pipeline where a red build reliably means a real problem is worth far more than one with broader coverage that people have learned to ignore.
A worked example: cutting a slow pipeline down
Say your pipeline takes forty minutes end to end. A first pass usually finds the test suite running sequentially when it could run in parallel across several workers, dependencies getting reinstalled from scratch on every run instead of cached, and a handful of genuinely slow integration tests that could run less often, say on merge to a main branch rather than on every commit, without meaningfully weakening the safety net.
Common mistakes that make a pipeline slow and untrusted
A handful of habits recur across teams with pipelines nobody trusts:
- Running the entire suite on every commit instead of a fast subset, with the full suite reserved for merges
- No visibility into which specific step is slow, so speed work targets the wrong thing
- Flaky tests left in place because no one owns fixing them
- A pipeline that blocks merges but has no clear owner when it breaks for infrastructure reasons unrelated to anyone's code
Fixing the ownership gap alone tends to resolve most of the others over time.
What Good Looks Like
Good here means a red build reliably means a real problem, the pipeline finishes fast enough that engineers actually wait for it, and deploying to production doesn't require a person to manually decide it's safe each time.
Building The Capability (5-Stage Skill Ladder)
How to Get Started
Frequently Asked Questions
How fast should a CI pipeline realistically be?
Fast enough that engineers wait for it rather than merging around it, which is a team-specific bar rather than a fixed number. If people are routinely starting other work and forgetting to check the result, that's the signal to invest in speed, regardless of the actual minute count.
Should we run the full test suite on every single commit?
Not necessarily. A fast, representative subset on every commit with the full suite running on merges to a shared branch is a common pattern that keeps feedback quick without weakening the safety net where it matters most, at the point code actually reaches everyone else.
What's the first thing to fix in a pipeline nobody trusts?
Flaky tests, almost always. A team that's learned to re-run a failing pipeline instead of investigating it has effectively stopped using it as a safety check, and that habit is hard to undo once it sets in, so it's worth fixing before anything else.
Sources
Where we quote a benchmark, we show its source. Other figures in this guide are estimates or general guidance, so check them against your own numbers.
- Deployment frequency by DORA performance cluster (max days between deploys). DORA Accelerate State of DevOps 2024 (Google Cloud), cluster table via Octopus Deploy analysis, 2024.
Related Guides
Building a CI/CD Pipeline That Actually Catches Bugs
How to build a pipeline that blocks real regressions instead of just style errors, from test selection to what actually belongs as a merge gate.
A Worksheet for Sizing Your CI Pipeline's Real Cost
A step-by-step worksheet for pricing out what your automated test pipeline actually costs in compute and engineering wait time, and where to trim it.
What Your CI/CD Pipeline Actually Costs You
A way to think about CI/CD pipeline cost beyond the compute bill, including engineer waiting time, flaky test triage, and what to fix first.
CI/CD Stages That Actually Catch RAG Pipeline Regressions
A standard test suite misses RAG failure modes. Here are the CI/CD stages worth adding: retrieval gates, model version checks, and a real test index.
Building a CI/CD Pipeline for Agent and Tool Code
What changes about continuous integration once prompts and tool definitions ship alongside code, and how to test both before they reach production.
Where to Put Security Gates in Your CI/CD Pipeline
A decision guide for placing SAST, dependency, and secrets scanning in your CI/CD pipeline so gates catch real problems without slowing every deploy.