On your way to easier deployments?

In my last blog post, I described the main area’s of interest to work on to get faster and easier deployments. For every area, the level of maturity may be different. In this blog post, I will dive deeper in the levels of maturity and what they mean.

Like I told in the previous blog posts, this information is based on the book “Continuous Delivery” by Jez Humble and David Farley

The Five maturity levels

In the model, they describe the following five levels.

  1. Regressive
  2. Repeatable
  3. Consistent
  4. Quantitatively managed
  5. Optimizing


There is no process for releasing and delivering software. A new deployment becomes an intensive event with a lot of opportunity to fail. A successful deployment is a victory. Although the number in the list says 1. In their book, Jez and David call the level -1. Minus because deployment is actually in the toddler stage.


When you are at this level of maturity, some stuff is being take care of. Changes management processes are in lace. There are clear guidelines of what to do and when to do it. Most of the times the organisations have a OTAP strategy, but most of the testing is done by humans. Only a small part of the tests, if any, is automated. Not a lot has been done to automate deployment. Most of the work is done by typing commands on a terminal based on a script in a paper document. In my view, this is the minimum level at which you can rightfully claim you are doing ITIL. As you can see this is still much lower than the levels proposed in the book


At this level of maturity, you have a broad set of automated tests. The tests are at a sufficient level to detected critical errors early end often. The deployment is getting more and more automated. Deploying a new version to an integrated testing environment becomes easy.

quantitatively managed

The testing and deployment are fully automated, and there is a pipeline in place to do the testing and deployments in OTAP environments. Bad versions are caught in the deployment pipeline before they reach production. Because deployments are easy and the quality of releases increase, teams start to do more and smaller deployments. The statistics of builds and deployments are tracked, and acted upon.


At the final level, not only all processes and tools are in place, but the whole organisation around building, testing and deploying software is constantly improving. Teams regularly discuss the problems and fix them. Every deployment, whether it is in production or any test environment is a vehicle for improvement.