Unless you are a greenfield start-up, most companies will have a number of IT products which are built on code developed and deployed using processes created from days well before DevOps.

Starting with a clear vision and strategy for the specific outcomes we desire has allowed us to put in place the technical and cultural building blocks in our product for the permanent transformation of our product delivery pipeline. We have a simple but clear vision to:

• Have a holistic approach that optimises the efficiency of the whole system, not just some parts
• Re-engineer the product architecture and the release processes to improve deployment frequency and deployment lag
• Demonstrate improved behaviour of the product in production to the operations teams
• Conform to all appropriate company compliance standards
• Ensure all stakeholders in the delivery pipeline are involved in creating the solution.

Our aim is to deliver this vision using the “configuration as code” DevOps model with standard software engineering principles. The outcome we desire is to reduce the time from code commit to the deployment of high quality, highly secure small functional artefacts into production.

Cultural changes

Tools are a necessary but not sufficient condition for DevOps to succeed. As well as new tools and methods, it is important to understand that business processes and cultural habits will also need to change. Changes will often experience resistance unless the benefits DevOps can be demonstrated.

Because of previous deployment issues, most companies will have additional governance processes and separation of duties to reduce the risk of production issues. This will naturally create silos, which are anti-patterns to DevOps success. Breaking down these barriers must be done in a sensitive way so as not to imply lack of commitment or professionalism from either side. Building relationships and demonstrating deployment competence of the development teams are often the only way to change opinions. This takes time and effort.

John Kotter’s 8 stage change process is a useful tool to manage business change (see diagram). Key to this is building a guiding coalition. Initially, it is important to spend time building relationships across the different disciplines and silos. This helps determine whom the key decision makers are, what strategies and tools are already being used, and what degrees of freedom there are to make changes. Finding ways to demonstrate business value (short-term wins) are an excellent way to gain trust and respect across the various stakeholders and between silos.

Source: https://www.kotterinc.com/8-steps-process-for-leading-change/

Automated testing

It is also important to understand potential objections and address those objections in any DevOps strategy. For example, it is vitally important to prove that the new processes deliver higher quality and more secure artefacts than previous deployment pipelines. This means implementing a “shift-left” testing policy particularly by using automated testing earlier in the software development cycle. In many organisations, testing is often performed late and usually includes manual or semi-automated testing. Using automated testing enables us to provide quality gates earlier in the continuous delivery pipeline. This ensures greater confidence in deployments into test environments and eventually into production. It also enables regression testing to be performed when modules are changed reducing the risk for production deployments. This does, however, have implications for the new skills and behaviours required in both software development teams and testing teams.

Tools and recipes

Continuous delivery is such a different paradigm to the usual deployment methods that stakeholders, particularly budget holders, need to be shown why investment in tooling is important. Adopting some tools and choosing an appropriate project to demonstrate business benefit quickly is often a better approach than company-wide initiatives over a longer period. Which tools are chosen are usually less important than adopting DevOps policies and principles such as using recipes, adopting version control for all code (not just source code) and using appropriate pipeline orchestration. As with any coding discipline, our knowledge of how to build pipelines grows as we gain experience writing more and more complex pipelines.

Continuous delivery

While there is still work to be done, the early results we have seen in our product have demonstrated the business value to various stakeholders and allowed us to gain credibility within the development and operations teams. Each new delivery gives us more confidence and enables us to grow our knowledge in building relationships across teams and using DevOps techniques.

Written by Director of DevOps at ADP UK, Keith Watson