iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If the cheapest check that can reject a change runs last, developers wait longer than necessary for useful feedback. Reorder checks by balancing their ability to catch failures, their measured runtime and cost, and the dependencies between pipeline stages—not by sorting every step into a simplistic cheapest-to-most-expensive list.
What should run first in a CI/CD pipeline?
A useful starting point is to run inexpensive checks that can reject a change before committing resources to later work. In “Making deploys boring,” Harsh Pahurkar describes the principle as running the cheapest check that can reject a change first, with an example sequence of linting, tests, image build, image push, and deployment.
Treat that as a heuristic, not a universal ordering. A check can only run when its inputs and environment are available. For example, deployment depends on an artifact being built; a check that needs a deployed service cannot precede deployment merely because it is quick or inexpensive.
How to decide whether a check belongs earlier
Inventory the checks in your own pipeline before changing their order. Use actual pipeline observations rather than assuming which check is cheapest: the available guidance does not establish universal runtimes or costs.
#1 Best Overall
- What can it reject? Identify the failure or property the check can establish. A check that cannot affect whether the change proceeds may not belong on the critical path for every change.
- What does it cost and how long does it take? Record observed runtime and direct compute or service costs in your system. Cost and duration are related, but not interchangeable: a short check may consume costly resources, while a longer check may be inexpensive.
- What does it need or produce? Note prerequisites such as a built artifact, pushed image, test environment, or deployment. Also identify outputs that later stages require.
- How trustworthy is the result? Track flaky failures and distinguish them from reliable rejections. A check that regularly fails unpredictably can undermine confidence in pipeline results.
Then move a check earlier when it can reject a change and its prerequisites are already satisfied. Preserve the dependencies that make the pipeline valid, even when that means an expensive or slow stage must come before a downstream check.
When to run checks in parallel
Checks that do not depend on one another may be candidates for parallel execution. Keep dependent steps in the required order—for example, an artifact must exist before it can be pushed or deployed. Parallel work can change elapsed pipeline time, but the benefit depends on the checks, available capacity, and dependencies; measure the result in your own pipeline rather than assuming a particular speedup.
Rank #2
Keep feedback fast and credible
Fast feedback matters only if teams can trust it. A separate CI/CD guide discusses pipeline duration and fast feedback, and cautions that tolerated flaky tests erode trust; its suggested timing targets are recommendations from that guide, not universal thresholds. Use your team’s own requirements and measurements to set targets, and address recurring flaky failures instead of treating them as normal noise.
A practical reordering workflow
- List every check and stage. Record what each detects, its observed runtime and direct cost, its prerequisites, and any output consumed downstream.
- Mark dependencies. Keep required producer-consumer relationships intact, such as building an artifact before pushing or deploying it.
- Identify early rejection opportunities. Among checks whose inputs are ready, prioritize those that can reject a change without first paying for avoidable later work.
- Look for independent work. Consider parallel execution only where checks have no unmet dependencies and the pipeline has suitable capacity.
- Compare outcomes after the change. Check pipeline duration, resource or service costs, and failure reliability against your previous measurements. Keep the new order only if it improves the outcome without weakening the checks.
What this principle does not tell you
The phrase “the cheapest check in our pipeline ran last” points to a real ordering problem, but it does not identify which check was misplaced, what consequence followed, or what remedy the original author gave. Those incident details are not established by the available article listing. The general ordering principle above comes from separate CI/CD guidance and should not be mistaken for a verified account of that specific post.
Rank #3
For a broader treatment of build, test, and deployment automation, see the book Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation. Its current edition and retail availability are not established here.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
