Phases of DevOps maturity

Organizations should be looking to mature the more they process and adopt different DevOps best practices. This is known as maturity, and four phases are used to describe the phases of maturity in DevOps.

These phases are as follows:

• Waterfall
• Continuous integration
• Continuous delivery
• Continuous deployment

Throughout the cycle of DevOps transformation, organizations should move from waterfall toward continuous deployment, visiting each stage along the way. However, it is worth noting that waterfall is not always the starting point; some organizations start later in the phases.

During the transformation process, you will find that different teams gain maturity quicker than others. There are many factors for this, including the type of work that the team does, the processes they have to follow, and, to a degree, the level of automation and tooling they already have in place.

Waterfall

The term waterfall will be common to you if you have worked on projects in the past. Waterfall is a project delivery mechanism where tasks are completed in a sequential order to achieve a specific goal. It can also be used to explain a method of software development.

Where development teams write code over a long period of time, those teams then merge their code in order to release the latest version. In this case, so many changes have been made to the code base that integrating the new version could take months. This is because the code looks so different from the previous version.

Waterfall has been in the world of project management for a long time, and even with the adoption of Agile getting more and more popular, many projects are executed using the waterfall methodology successfully.

The advantages of using waterfall as a delivery method are as follows:

• Simple model to use and easy to understand.
• Rigidity makes it easy to manage; each phase has specific deliverables.
• In smaller projects, it works well as the requirements are well understood.
• Stages for delivery are clearly defined.
• Milestones are well understood.
• Arranging tasks with resources is simple.
• Processes and their results are well documented.

That being said, waterfall does have several disadvantages, as with all process models. Some of these disadvantages are as follows:

• No time for revision or reflection.
• High amounts of risks and uncertainty.
• Not a good model for projects that are complex and object-oriented.
• Poor model for long-term projects.
• No working software is produced until late in the project.
• Measuring success within stages is difficult.
• Integration is done at the end in a big bang, making identifying bottlenecks hard.

Agile addresses some of these challenges and together with DevOps, you can address a large number of the challenges described here.

Continuous integration

Continuous integration (CI) is the practice of quickly integrating newly developed code with the rest of the application code to be released. This saves time when the application is ready to be released. This process is usually automated and produces a build artifact at the end of the process.

The process of CI contains a number of steps, and these are critical to achieving CI, which is meaningful and efficient. Automated testing is the first step toward CI. Four main types of tests exist that can be automated as part of CI. These tests are as follows:

• Unit tests: Tests that are narrow in their scope. They usually focus on a specific part of code, such as the method of a function, and is used to test the behavior of a given set of parameters.
• Integration tests: Ensures that different components work together. This can involve several parts of your application, as well as other services.
• Acceptance tests: In many ways, this is similar to integration tests. The big difference is that acceptance tests focus on the business case.
• User interface tests: Tests that focus on how the application performs from a user's perspective.

  Important note

  One vitally important element of CI is that you integrate early and integrate often.

When you integrate early and often, you reduce the scope of changes, which, in turn, makes it easier to identify and understand conflicts when they occur. Another big advantage of this approach is that sharing knowledge is easier as the changes are more digestible than big bang sets of code changes.

Another note is that if the main branch becomes broken by a commit in code, then the number one priority is fixing it. The more changes that are made to the build while it's broken, the harder it will become to understand what has broken it.

Every new piece of work that you implement should have its own set of tests. It's important to get into this habit of writing granular tests and aiming for a level of code coverage, as this gives you a comfortable level of knowledge that you are testing the functionality of your application sufficiently.

The value of CI is realized when the team makes changes on a frequent basis. It's important to make sure that your team integrate these changes daily. Integrating often, as you may recall, is key to making sure we can easily identify what is broken.

Continuous delivery

Continuous delivery (CD) is an approach where teams release products frequently and with high quality, and with a level of predictability from source code repositories through to a production environment using automation. It builds on the work that's done in CI to take the build artifact and then deliver that build to a production environment.

CD is, in fact, a collection of best practices associated with Agile. It focuses your organizations on developing a highly streamlined and automated software release process. At the core of the process is an interactive feedback loop.

This feedback loop, sometimes referred to as continuous feedback, centers around delivering software to the end users as quickly as possible, learning from experience, and then taking that feedback and incorporating it into the next release.

CD is a separate process to CI, but they chain off each other and in mature organizations, they are used together. This means that on top of the work you have done in CI to attain levels of automated testing, you can now automatically deploy all those changes after the build stage.

With CD, you can decide on a schedule that best suits your organization, whether that's daily, weekly, or monthly – whatever your requirements may be. If you want to get the true benefits of CD, then deploy to production as soon as possible to make sure that you release small batches that are easy to solve in case of problems that may arise.

Continuous deployment

Continuous deployment is one step beyond continuous delivery. Every change that passes through all the stages of your production pipeline is released to your customers. There is no human intervention – a failed test, at this stage, will prevent new releases to production.

Continuous deployment is a great way to speed up the feedback loop and take the pressure off as there is no release day. Developers are then able to focus on building high quality software while seeing their work go live minutes after they've finished working on it. Continuous integration is part of both continuous delivery and continuous deployment. Continuous deployment is very similar to continuous delivery; the difference is that releases take place automatically:

Figure 1.1 – Showing the differences between continuous integration, delivery, and deployment

In this section, we have looked at the major phases of maturity in DevOps. Armed with this information, we can now look at how Agile plays a role in DevOps.