DevOps Audit and Its Capability Maturity Model

DevOps Audit

DevOps Audit is the measurement to find the state of DevOps Culture and Practice in a Software development environment. Since DevOps is increasingly becoming part of the IT industrial cycle of software development, it ought to have a proper measurement to boost the product cycle by improving through required points generated after an Audit. The DevOps Audit aims to benchmark the current DevOps Practices to industry best practices as per the DevOps Maturity Model.

Capability Maturity Model

The Capability Maturity Model (CMM) defines an increasing series of levels of a software development organization. The higher the level, the better the software development process, hence reaching each level is an expensive and time-consuming process. The model contains four dimensions: Quality, Automation, Communications/Collaboration, and Governance.

The 5 Maturity Levels of the Model:

1. Initial level

There are no methods or tools defined for communication and no clear roles between team members. In this, decision-making is centralized and automation does not exist. Governance is jumbled and procedures are not predictable. Quality has no significance and is done on an ad hoc basis.

2. Managed level

The team communicates in a better-coordinated way to different stakeholders. Decision-making is centralized but decisions are more shared with the team. The team has better-defined roles and responsibilities. However, communication between teams is not shared. Automation and governance are ad-hoc basis and not standardized in organization and processes and customs vary between different teams. Quality starts to have value but it is managed on each project on an ad-hoc basis. Proper tools can be used but should be based on project needs.

3. Defined level

Communication is more definite. Different departments are informed in a coordinated way and involved in the process early. Defined level automation is normalized across the organization. The organization provides support, training, and a standardized framework. Governance and processes have organization standards. Quality also has organization-wide standards and tools, which are adopted by teams.

4. Measured level

This level is an improvement on the measurement and metric system of DevOps in software development. Here, each dimension has metrics used to improve processes. Automation helps collect the metrics and visualize them.

5. Optimized level

Each dimension requires optimization toward organization goals and objectives. The model is used as a basis for this evaluation. Sharing information at the organizational level is done by a subjective evaluation of a team member’s point of view. The team does not have documentation available to support claims. At the managerial level, more coordination may happen than assumed in this evaluation, but it is not visible at a team level.

These are categories in which these stages are compared for a Project

Culture & Process

In Culture & Process, the model sees that the project identifies the need and sets the organizational goal, sets up your DevOps for rolling out those goals, then plans cross-team building activities, and last spreads the words as in planning lots of sessions to discuss/educate/debate on DevOps.

Communication & Collaboration

In Communication & collaboration, we aim for use of a common CI server by the Dev & Ops team. Jira and wiki should be used effectively by dev & ops so that they can distribute the task easily and can handle it properly.

Automation

In Automation, the model categorizes the levels on the basis of automation at different parts of the project. The SCM, Ticketing, and CI server integration. Example integrating JIRA with GitHub and Jenkins. The level and amount of automation orchestration in the project are also part of the category.

Monitoring & Logging

In Monitoring & Logging, health checks need to be done for App/OS/Docker/Services. There should be a centralized tool used to view and identify the failure in the whole flow. In case of failure in Production, there needs to be an urgent meeting call or self-healing thing.

Security

In Security, there should be an IAM user for Authentication and need to use a vault for handling the secrets. They should define security rules by the security team. And last, there should be disaster recovery plans for the project.