What you will take away
- Ten minutes is a design constraint that keeps developers in context.
- Order stages so the cheapest check fails first.
- A tolerated flaky test destroys trust in the whole pipeline.
Why ten minutes is the number
Under ten minutes, a developer waits for the result and keeps the change in their head. Beyond it they switch tasks, and the cost of the context switch is added to every fix. Past thirty minutes, people batch changes to avoid the wait, which makes each deployment larger and riskier - the opposite of the intent.
Treat pipeline duration as a product metric with an owner. It creeps upward one test at a time, and nobody notices until it is forty minutes and the team has quietly changed how it works.
Order the stages by cost
- Lint, format and type checks first - seconds, and they catch a real share of mistakes.
- Unit tests next, running in parallel across workers.
- Build once, producing an immutable artefact that every later stage and environment uses.
- Integration tests against real dependencies in containers rather than mocks.
- Deploy to staging automatically; deploy to production on a tag or an approval.
The rule behind the order is that a failure should cost as little as possible. There is no reason to spend four minutes building an image for a branch that will not compile.
Where the time actually goes
Usually dependency installation and image building. Cache the dependency directory keyed on the lock file, use layered images so only the application layer rebuilds, and keep the base image lean. Those two changes typically halve a slow pipeline before any test is touched.
After that, parallelism. Split the test suite across workers by timing rather than alphabetically, and run independent jobs concurrently instead of chaining them out of habit.
Build the artefact once and promote it. Rebuilding per environment means you tested something you did not deploy.
Deployment gates worth having
Automatic deployment to staging on every merge, with a smoke test that exercises the critical path. Production behind either an approval or a progressive rollout - canary a small percentage, watch error rate and latency, then expand.
Automate the rollback trigger. If the error rate crosses a threshold during a canary, the pipeline should revert without waiting for a human to notice, and tell the team what it did.
Flaky tests are a pipeline emergency
One test that fails randomly teaches everyone to rerun the job. Once rerunning is normal, the pipeline no longer prevents anything, and a genuine failure is dismissed as noise.
Track flakiness, quarantine an unreliable test out of the blocking path immediately, and fix or delete it within the sprint. A deleted test is honest; a rerun habit is not.
OrbixEdge Engineering
The engineers who build and run the systems we write about - platform, cloud and product teams shipping for clients in retail, health, logistics and fintech.
