DevOps by the Numbers - Five Metrics to Watch
By Divesh Rupani

Tim Buntel recently sat down with Alan Shimel of DevOps.com and explored DevOps by the Numbers. This discussion looked at how to approach the measurements and metrics of a Continuous Delivery transformation. Tim spoke on tough questions like “are we getting better at delivering high-quality software faster and at scale?” and “has all this effort been worth it?!” After listening to the entire discussion we compiled the top 5 DevOps metrics to watch:

Time to Delivery

“Looking at your time to delivery across all the phases in your development process is a great tool to help you identify which of those stages you should tackle first.” – Tim Buntel, VP of Products

This provides insight into the specific processes slowing the pipeline down and what actions should be taken to decrease time to delivery. It’s important to remember, however, to focus your automating efforts on a select few areas of inefficiency at a time, as opposed to trying to do everything at once.

Deployment Frequency
Examining how often a company deploys software tells a lot about what is causing bottlenecks that slow down the process. A benefit to regular deployments is that it provides more opportunity to improve your software.

“If it takes you a very long time and you’re deploying less frequently then you’re going to be less able to respond. That suggests that you need to rethink the batch sizes that you’re delivering.” – Tim Buntel, VP of Products

In addition, processes dependent on manual labor as opposed to automated ones will only lengthen time between deployments. Automation will not only increase frequency but will also provide you with enough time to respond to any errors.

Change Volume

“Releasing frequently is only important if what you’re releasing is valuable. Thinking about what the volume of changes in the releases is a really important metric to bring into the conversation.” – Tim Buntel, VP of Products

However, the value of change will differ depending on each company’s specific software process. Agile companies often turn to user stories or points as the unit to measure change volume. It is essential for each release to come with its own meaningfulness in order to be a change worth making. Be sure to steer clear of lines of code as a unit of measurement as they tend to lack the complexity necessary for change.

Success Rate
Frequency and meaning behind your releases may be all for neigh unless it actually works. Be sure to keep an eye on the success rate, which, despite its name, is a unit of measurement focused on the number of times deployment to production resulted in failure. Failure is not to be feared, but rather embraced as an opportunity to learn.

“It’s important to get your releases and changes into production, but if they result in an outage it’s important for you to know that it happened because that’s going to tell you whether there’s quality in both your code and your process.” – Tim Buntel, VP of Products

These failures are usually a warning of configuration drift, which is often experienced by organizations undergoing a DevOps transformation.

MTTR (Mean Time to Recovery)
The debate between measuring Mean Time to Recovery (MTTR) and Mean Time Between Failures (MRBF) is very prevalent in DevOps. Our recommendation is as followed:

“Focus on time to recovery because faster delivery—being more agile—opens up more opportunity to failure but they’re not inherently bad. What’s important is can you react to them…can you take the evidence that comes out of that event and prevent it in the future.” – Tim Buntel, VP of Products

Failures in continuous automation are inevitable, but true failure lies in not responding to them fast enough. After all, knowing how well your team can handle unfamiliar situations is more useful than how long they’ve gone without them.

Above and Beyond
These five  metrics are the primary measurements used to optimize DevOps processes. However, depending on your industry there may be others that can come in handy. Adoption, or whether people are actually utilizing these new changes, can also be beneficial. This can be measured by a variety of factors such as application traffic, calls to Application Program Interfaces (API’s), new user sign-ups, and performance. Consumer happiness with the product is another useful measurement that uses social media to receive feedback from users. Business impact such as trial conversions, or what the market is saying about the company, helps prove that DevOps is a useful tool and can improve the continuous delivery process. Finally, and not as common is cultural impact, which focuses more on the internal such as staff turnover or morale gaged from surveys.

Listen to the entire discussion!

Continue reading about Continuous Delivery in the enterprise with “Simple Steps to Improve Applications Deployments to Microsoft Environments.”

The post DevOps By The Numbers – 5 Metrics To Watch appeared first on XebiaLabs.