DevOps transformation, only tools are not enough!

Agile software development has broken down the barriers between requirements analysis, testing, and development. In the software development process, development and operation and maintenance face the same isolation problem. The goal of the DevOps movement is to break down the barriers between development and operations and encourage collaboration between development and operations.

The emergence of new operation and maintenance tools and the establishment of agile engineering practices have made DevOps possible [1], but the understanding of the benefits of DevOps is far from enough. Even with the best tools, if we do not have the right culture, DevOps is just a buzzword.

The essential characteristic of a DevOps culture is the ever-increasing collaboration between development and operations roles. A cultural shift is needed at both the team and organizational levels to support this collaboration.

Shared responsibilities are one of the team cultures of DevOps, and shared responsibilities encourage further team collaboration. If the system operation and maintenance work is handed over to other teams, the development team will generally not care about the specific operation and maintenance work.

When the development team jointly shares the operation and maintenance work and responsibilities in the system life cycle, the development team can understand the pain of the operation and maintenance team, and can proactively simplify the tedious work in development and operation and maintenance (for example: automated deployment and improvement log).

They can also obtain additional requirements through production environment system monitoring. When the operation and maintenance team takes the initiative to assume the business goals of the system, the operation and maintenance team can work more closely with the development team to understand the operation and maintenance needs and provide support.

In practice, collaboration often starts when the development team realizes that it needs to know more about operation and maintenance work (such as deployment and monitoring) or when the operation and maintenance team adopts new automation tools and practices.

A culture of shared responsibility also requires some organizational changes. There should be no barriers between development and operations teams. At the outset, handing over documentation cannot be relied upon as a substitute for working together. The organizational resource structure should support the operations team to intervene as early as possible in the product delivery process and work together with other teams.

Putting development and operation teams together can effectively promote their work together. “Hand off and sign off” does not help teams share responsibility and can lead to a culture of blame. Instead, development and operations teams should be jointly responsible for the success and failure of the product.

DevOps culture blurs the boundaries between development and operations and will eventually eliminate them. A common anti-pattern when introducing DevOps into an organization is to create a DevOps role or DevOps team. Doing so will only create more barriers and prevent DevOps culture and practices from being spread and used across the wider team.

Another valuable organizational change is to support self-organizing teams. In order to collaborate more efficiently, development and operation and maintenance teams should make decisions independently and do not need lengthy change management processes when adopting changes. This involves trust in the team, changes in risk management methods, and the need to create an environment where failure is not a concern.

For example, a team needs to make a list of changes and get a bunch of sign-offs before they can be released to a test environment, and these changes are often delayed. We should rely on auditable version control instead of extensive manual checking. Changes in version control can be linked to the team's task management tool without manual sign-off and approval. The team can automatically deploy changes and shorten the testing cycle.

One impact of the change to DevOps culture is that it will become easier to deploy code to production. This requires further cultural change. To ensure that changes to the production environment are reliable, teams need to focus on building quality into the development process. This includes cross-functional concerns such as performance and security. Continuous delivery techniques (including code self-testing) allow for routine, low-risk deployments.

It is also important for the team to pay attention to feedback. In order to continue to promote development and operation and maintenance as a team, production environment monitoring is a very useful feedback loop, which can help diagnose problems and discover potential improvement points.

Automation is the cornerstone of DevOps operations and it can speed up collaboration. Automating testing, configuration, and deployment allows teams to have more time to focus on other valuable activities and reduces human errors. Another benefit of automated scripts and tests is always ensuring that the system's documentation is up to date. For example, automated server configuration means both development and operations teams can understand and modify server configurations.

Note:
[1]: Operation and maintenance tools include virtualization, cloud computing, and automated configuration management. These tools are supported in engineering practices such as continuous integration, incremental design, and code purification.

The above is the detailed content of DevOps transformation, only tools are not enough!. For more information, please follow other related articles on the PHP Chinese website!