There is a famous quote by Peter Drucker that states, “You can’t manage what you can’t measure.” In our industry, measuring how quickly we can get working software into the hands of our customers has become a mantra for agile development teams, and it’s even being talked about in the boardrooms.
Customers measure the value of software by how quickly it can solve their problems. Customer needs change constantly. Just like us, they are responding to the needs of their own customers. Reacting quickly to customer feedback and turning that feedback into working features is key to customer satisfaction and retention.
Having these directives in mind, it’s no wonder our teams are being asked to deliver working software sooner. Often, the main roadblock in achieving this goal lies not in developing the features but in getting them deployed.
Let’s focus on three areas that determine your team’s deployment performance, which, in turn, directly impacts your software development effectiveness.
1. Frequency of Deployments
When I meet developers, I ask them a simple question: How often do you typically commit your code? A typical answer is a few times a day or even a few times per hour. However, if you ask the same person a question about how often their application is deployed to production, the answer varies widely.
Some will say weekly or daily or still – very rarely – even a few times a day, which is software development nirvana. However, a more common answer is monthly or quarterly. I’m also not surprised if someone says that they release annually. They say it with an honest level of pride and accomplishment.
Let’s put these two things – code commit and deployment frequency – into a broader perspective. If the goal of measuring software development effectiveness is getting working software into the hands of the users, it doesn’t matter how often you commit your code but how often you can give your users new value.
Delivering small improvements to your customers has more impact on client satisfaction than giving them a big gift (new release) once a year.
2. The Control of the ‘Launch’ Button
Triggering a deployment includes someone instructing a deployment, pushing a “deploy” button, or committing triggered deployments. How many people in your organization can promote the application to a production environment? If this privilege is limited to a single person or just a handful of people – we have a problem.
There are many reasons you might want to limit access to production. It could be because you don’t have safety measures built into your deployment process, such as role-based access control. You may believe in the delusion that you can protect your organization just by having fewer people with access to the production environment.
The reality is that artificially limiting user access to production significantly reduces your chances of deploying frequently. Imagine if the “person in charge” must take a sick day or is traveling. Remember that access to the production environment is also required for bug fixes when your organization applies a fix-forward versus rollback strategy.
3. The Level of Deployment Automation
Measuring software development performance is directly correlated to the level of process automation. You can’t manually deploy to hundreds or thousands of customers in a reasonable amount of time. The manual process does not scale, as time is the one thing we can stretch.
Ask yourself: Is your deployment process manual, partly automated (where parts of the process are automated, such as scripts that can be triggered to perform application deployment tasks), or can you claim that you fully automated your deployment process where there is no manual intervention, apart from push-button approvals.
The more you automate your deployment process, the more productive your development team can be. For complex deployments, you may need to target many customers, sets of infrastructure or even physical locations. You might need to apply different configurations or hit agreed maintenance windows for customers or regions. One way to accelerate software delivery for these scenarios is tenanted deployments.
Tenanted deployments capture these differences and apply them to a shared deployment process, allowing the complexity to be automated. You can manage tenanted deployments with tags, variables and customizations while reducing the cognitive load for team members.
There are many ways deployment frequency impacts software development effectiveness. When you deploy more often, you reduce deployment risk, increase quality and get feedback sooner. One action you can take to reduce batch sizes is to increase deployment frequency. Smaller batch sizes will also allow you to recover faster when a problem arises.
Remember that the longer the time between deployments, the more changes and points of failure build up.
As you think about ways to increase software development effectiveness, think about the deployment process as a way to get close to the ultimate measure of developer success–getting the working software into the hands of customers sooner!
To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2023 – November 6-9, 2023.