DORA change lead times are critical to your engineering team’s velocity. If you can reduce them, you’re shipping features and remediating bugs faster. The strategy here? Find your bottlenecks, and start optimizing from there.
What is lead time for changes?
Lead time for changes represents the time it takes for a commit to get deployed to production. It’s one of the four key DORA metrics. Change lead time measures the efficiency of your deployment process — how long does it take for a commit to get tested, verified, reviewed, approved, and pushed to production?
According to DORA, Elite performing engineering teams have a change lead time of under a day. High performers have a change lead time of between one day and one week. Change lead times are indicative of your overall DevOps performance, although “ideal” change lead times will vary between orgs.
How to measure lead time for changes
The base formula is change lead time = deploy time - commit time.
- Commit time is the timestamp that a piece of code is committed to either
mainor a feature branch - Deploy time is the timestamp that a given commit is deployed to production.
We have a more detailed guide on measuring DORA change lead times — check it out to learn more.
Ways to improve change lead time
Improving your lead time for changes is a continuous process. The best way to start is by gradually iterating on your team’s processes then assessing the resulting DORA outcomes. Rinse and repeat. Below, we’ve compiled some steps you can take to make a sizable impact on your change lead times.
Analyze stages of change lead time
There are several stages that change lead time can be broken down into. These stages make up your deployment process, and will be more or less the same every time you deploy.
By analyzing the stages individually, you can find where your team’s biggest bottlenecks are, and hone in on them. See: “How to Measure DORA Lead Time for Changes”.
Invest in self-service infrastructure
One of the easiest bottlenecks to eliminate is “wait time”. There are two main sources of wait time: people and infrastructure. If you start with infrastructure, working on process will be much more straightforward.
Enabling your developers to test their changes and deploy them without any manual intervention can save them hours (or even days) of change lead time. On-demand (ephemeral) environments are one of the easiest ways to shift testing and review left. Developers can see how their code changes fare in a production-like environment earlier on in the pipeline, so they can resolve any bugs before code review. And stakeholders won’t have to wait until staging to submit product feedback.
Self-service infrastructure ensure that code changes are never idling — they should be pushed to an environment ASAP. This way, they’re ready for review as soon as they’re committed and tested.
Improve your test suite
How much of your manual review and UAT process could you automate? Collaborate with QA to see what current testing processes might need attention. Refactoring your test suite is a huge undertaking, but that shouldn’t stop your team from gradually and continually improving it.
Once you invest in self-service infrastructure, you can run your tests earlier and more often. You may want to make sure your tests are up to the task: maintainable, reusable, and not flaky.
An effective test suite prioritizes end-to-end and integration tests. This guarantees the same quality checks are repeated against every commit. Plus, this will reduce the amount of manual QA required for every code change and help uncover bugs prior to staging. DORA recommends taking code review feedback and adapting it into your automated tests.
Use trunk-based development
Trunk-based development encourages devs to reduce commits to their smallest possible units. Each working branch originates directly off the trunk, and merges right back into it. Keeping commits small makes them easier to test and verify, and reduces the odds of merge conflicts.
Smaller commits are also easier to review, so they flow through the deployment pipeline rather quickly. Google’s 2023 DORA Report recommends small changes as a process improvement, leading to a positive change for all four key metrics:
“Smaller changes are easier to reason about and to move through the delivery process. Smaller changes are also easy to recover from if there’s a failure. Teams should make each change as small as possible to make the delivery process fast and stable.”
Make code reviews a priority
If your commits aren’t getting reviewed shortly after they’re pushed, you’re unnecessarily increasing your change lead time. Plus, when code reviews happen earlier, it’s more likely that developers will have time to improve a feature, and have time to ask for a follow-up review. In turn, the quality of the code stays high. The developer also isn’t undergoing as much context switching — they remember the feature’s intended behavior, and can more easily pick up where they left off.
Instant environments == shorter change lead times
When trying to get features to the test/review stage more quickly, you can eliminate infrastructure wait times with ephemeral environments. As soon as (or even before) a feature is complete, you can get it deployed to a short-lived environment. You can run your full test suite against this, remediate changes, and then share with stakeholders for feedback.
Adopting a solution like Shipyard can help cut out days of change lead time. You’re testing earlier, more often, and enabling async reviews. Your DORA metrics will thank you.
