This is the final installment of our Cycle Time Breakdown series on the most effective tactics to speed up your development cycle time. The other posts were:
- Tactics For Reducing Coding Time
- Tactics For Reducing Pull Request Pickup Time
- Tactics For Reducing PR Review Time
- Tactics For Reducing Deploy Time ← You are here
In this piece, we’ll look at the last part of a development cycle: deployment.
Table of Contents
- What Is Deploy Time?
- Does My Team Have a Long Deploy Time?
- My Team Has a Long Deploy Time…Now What?
- Common Causes of High Deploy Times
- Conclusion
What Is Deploy Time?
You’ve written some new code. You create a pull request, which then gets reviewed. You respond to the comments, update the PR, and the PR gets approval to be merged into production.
From there, a developer’s job is pretty much over, but that doesn’t mean that the code is live. It still has to go through testing. Perhaps your organization merges new deltas in batches every couple of days. Or maybe they’re putting out fires so no new code is being released into production.
The amount of time between when the code is ready and when it is live is called deploy time.
The longer it takes for your app to deploy, the longer it will take you to retry failed deployments and recover from outages. By decreasing deploy time, you can speed up your cycle time, decrease your mean time to restore, and lessen the damage of a high change failure rate, which are three of the four DORA metrics.
Does My Team Have a Long Deploy Time?
Many tools can show you cycle time phases and DevOps metrics, but this is just half the story. Only LinearB shows you how your team stacks up against the industry averages.
Through our DevOps research on almost 2,000 engineering teams, we established benchmarks for 9 key engineering metrics.
Elite teams take less than fours to deploy new code into a production environment. Yes, that is incredibly fast but that’s only the best of the best. If you deploy within 48 hours, you’re still a high performing team. But if deployment to production takes over a week, then there is plenty of room for improvement in your DevOps processes.
My Team Has a Long Deploy Time…Now What?
Next, you want to identify the causes. The best next step is to go deeper into the data.
By breaking down the top-level deploy time into smaller parts, you can suss out the main drivers of a high deploy time and take targeted action to address them. Here are some questions to ask yourself:
- My deploy time is high now, but is it typically this high? Was it ever lower or higher?
- What is my mean time to deploy over the last week, month, three months, and six months? Are these numbers trending up or down?
- Do all my teams have high deploy times or just one or two?
Use LinearB to see cycle time metrics for each team over different periods of time. And dive deeper into the data with one click to see the cycle time phases of individual branches.
Your next steps will vary greatly if the high deploy time you’re observing right now turns out to be anomalous or systemic. If it’s anomalous, then you need to locate some rare, unusual factors that have sprung up. If it’s systemic, this means that bigger changes are needed to your team’s processes.
Common Causes of High Deploy Times
Here are some of the most common causes to look for:
Personnel Bottlenecks
In order to ensure that only high-quality code gets merged into production, some teams allow only some developers to merge PRs into the main branch. This is well-intentioned, but it often turns out to be a bad DevOps practice. Maria Gutierrez, VP of Engineering at Twitter, learned the hard way that she had to stop being a bottleneck in her deployment pipeline and diversify responsibility in her team in order to enable continuous delivery:
Senior devs especially tend to get overburdened because they have the most knowledge and can contribute in the greatest number of ways. LinearB’s Team Health metrics help you manage the bandwidth of your team members. We’ll even warn you if a team member has taken on too much work and is at risk of burning out, so that you can check in with them to see how you can better distribute responsibility within the team.
Inefficient Testing
I once worked at a startup where our test suite took about 20 minutes to run all the way through. Tests unearth bugs that need to be fixed, so before creating a PR I would typically need to rerun the tests multiple times before they all passed. All these hours spent running tests added to deploy time.
Your tests should not only be robust and comprehensive, but they should also be fast, so that you can spend time writing code, not waiting for the tests to complete.
Deltas Are Too Big
As we’ve looked at previously, big deltas (and the big pull requests they result in) cause problems at each stage of the development cycle. They lengthen coding time, and they discourage people from reviewing them because they take a long time to review.
Big deltas also cause long lead times for deployment. They are more likely to create bugs, so developers put off merging them in. Delaying merges like this cuts against the principle of continuous integration / continuous deployment (CI/CD) software delivery.
In contrast, small deltas are much safer. It is much easier to understand what is going to change in an application because of a small delta, and therefore much less scary to push it live.
LinearB can help you to drive down the size of your teams’ pull requests. We measure PR size and our automated bot, WorkerB, can alert you when a big pull request has been created. This enables you to intervene right away and prevent that big PR from slowing everything down as it makes its way through the development cycle.
Start Reducing Deploy Time Today
Now that we’ve covered the tactics to reduce your deploy time, you should:
- Understand each of the four components of cycle time
- Know the key metrics to track for each one
- Have actionable strategies to increase your development velocity.
You can use LinearB each step of the way and drive continuous improvement in your teams. With our benchmarks and metrics, you can measure your performance and identify places to improve. With our Team Goals, you can set specific goals that will keep your teams focused and motivated to get better, and our WorkerB bot will help you drive progress toward those goals.
Although LinearB does a lot, we’ve made sure it’s super easy to get started. To see how quickly you can start leveraging engineering metrics to improve your development teams’ processes, reach out to schedule a demo or learn more from one of our customers.
