DevOps Metrics #2 [Release Frequency] metric: Solidify

DevOps Metrics #2 [Release Frequency] metric:

Published March 29, 2017

Once you start adapting more and more <a href="http://solidify.se/7-keys-success-with-devops/">aspects of DevOps</a>, the need for follow-up on the initiative is becomes more vital for your success (or lack thereof). Through the use of various DevOps metrics you can create a picture of what works well, what doesn’t, and identify areas for improvement. It’s not only about using tools for analysis, but also think about what to actually analyze. Consequently, these metrics will very between organizations, but some numbers are always good to keep track of. One of those numbers is the <a href="http://solidify.se/increase-release-frequency/">release frequency</a> metric. <h2>DevOps and metrics</h2> The focus of DevOps is often on development itself. You need to quickly implement new solutions and respond to customer feedback. However, DevOps is a lot more than just software development. With DevOps, you also work to incorporate security and increase the <a href="http://solidify.se/devops-metrics-mean-time-to-recovery-mttr/">mean time to recovery</a> after a production error. Many metrics aims at either measuring your personnel, your processes or your technologies. When tracking your release frequency metric, you more or less put them all together in the sense that a great release frequency can most certainly be traced back to all three parts. <h2>The release frequency metric</h2> It’s one thing for the IT department to create pipelines that are fast enough to be able to handle releases on demand. The other side of the coin belongs to the business department. When IT no longer is the bottleneck, it’s simply up to management to decide how often and when to ship new releases. This, however, is often not the case. The speed of the IT department is the bottleneck that management needs to take into consideration. This means that as fast as the pipeline is ready to ship a release, it will do so – regardless if this results in 3 times a month, 3 times a year or even less frequently. When you work with DevOps, each small code addition becomes a potential new version to publish, given that all tests in the pipeline approves the addition. Release frequency is all about increasing the IT department speed. By doing so, you allow yourself to efficiently meet management’s and the business department’s needs and requirements. It can be used once you’ve determined how many releases you and your organization would want to do each year, month and week. Once you know that number, you can easily track your progress towards that goal. <h2>IT vs business</h2> When the IT department becomes faster and more agile, the time required to ship each release will automatically decrease. When the pipeline uses more and more automation, the time needed for manual processes is also cut. This in turn results in every subsequent release being more and more manageable. The question “How often should be publish new releaess that have passed our pipeline?” then goes from being an IT related issue to a business related one. With more releases, you hopefully also see more user feedback and can respond with new features faster. Some organizations, such as <a href="http://solidify.se/6-best-devops-companies/">Netflix and Amazon</a>, has chosen to simply not take this decision. They completely and fully trust their pipelines and the flow that automatically deploy new releases more continuously than by publishing distinct versions. In these cases, the release frequency metric ends up being several times per day (or even faster).   Have you started working towards an increased release frequency? Which part of the process was the most important? Let us know in the comments below!