One of the primary goals of the DevOps mindset discussed in Chapter 1, Introduction to DevOps, is increasing the flow of value to end users. To do this, software must be deployed frequently, maybe even multiple times per day. To make frequent deployments possible, two things are important: automation and quality. Automation has been discussed extensively in the previous chapters, and so now it is time to move on to the topic of quality.

Once an automated build and release pipeline is in place and changes are starting to flow to production at an increasing speed, it is time to start measuring the quality of these changes. Even more importantly, this allows us to abort changes that are not of sufficient quality. What actually makes quality sufficient can differ from project to project. When creating games, a few bugs might be annoying for the user but nothing more. When creating software for airplanes or medical use, a single bug may cost lives. In software, higher quality is more expensive and/or takes more time. So, there is a trade-off between the number of features we can deliver and the quality that can be guaranteed. For every project, there is a different optimal trade-off between these.

Before quality can be measured, it is important that you first establish how to measure the quality of software. A common approach to monitoring the quality of software is to gather one or more metrics. For example, it could be decided to collect a set of five measurements every week. Graphing these metrics over time provides insight into how the quality of the software is evolving. An example of this might look something like the graph shown here:

The next sections discuss several examples of metrics.