DORA metrics: measuring delivery without gaming the numbers
Four measures describe delivery performance well. They are useful for finding constraints and harmful when used to compare teams.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Feedback within a few minutes is what makes a pipeline trusted.
- Build once and promote the same artefact through environments.
- Rollback must be a rehearsed single action.
- Flaky tests destroy trust faster than missing tests.
Feedback speed decides adoption
The single most important property of a pipeline is how long a developer waits for a verdict. Beyond a few minutes, people stop watching, context-switch and return later, and the value of the feedback collapses.
Split the pipeline into stages: fast checks that run on every push — lint, unit tests, type checks — and slower integration and end-to-end suites that run on merge or on a schedule. Parallelise aggressively and cache dependencies properly.
Quality gates that hold
- Tests must pass; no override without a recorded reason.
- Dependency and container scanning with a defined severity threshold.
- Secret scanning to stop credentials reaching the repository.
- Build artefacts produced once and promoted, not rebuilt per environment.
That last point is regularly skipped and matters: rebuilding per environment means the thing you tested is not the thing you deployed.
Deployment should be boring
Automate the deployment path completely, including production. Manual steps are where mistakes happen and where knowledge concentrates in one person.
Use a progressive strategy — rolling, blue-green or canary — and make rollback a single, rehearsed action. A rollback that has never been executed is not a rollback plan.
Flaky tests are a pipeline emergency
A suite that fails randomly teaches everyone to re-run rather than investigate, and at that point the pipeline no longer protects anything.
Quarantine flaky tests immediately, raise them as defects with an owner, and fix or delete them within a defined window. Tolerating them is far more expensive than the work of resolving them.
Keeping the pipeline maintainable
Pipelines accumulate steps and rarely lose them. After a couple of years the configuration is long, partly duplicated across repositories and understood by one person.
Extract shared logic into reusable workflows or templates so a change to the build process happens once. Keep the pipeline definition in the repository it builds, so it is versioned with the code it applies to.
Review the pipeline periodically as you would any other code. Steps that no longer serve a purpose, caches that never hit and checks that are always skipped all cost time on every run.
Frequently asked questions
Fast checks under five minutes and the full pipeline under about twenty is a reasonable target for most teams. Beyond that, developers stop treating it as immediate feedback.
Continuous delivery always deployable, with a human approving the release suits most organisations. Fully automatic deployment works well once test confidence and observability are strong.
Make them backward compatible and deploy them separately from code, so the old and new versions can both run during a rolling release. Migrations that require downtime should be a deliberate exception.
