{{announcement.body}}
{{announcement.title}}

DevOps Adoption Practices

DZone 's Guide to

DevOps Adoption Practices

From our recent DevOps Guide, we explore some of the steps that should be in your roadmap for a DevOps implementation.

· DevOps Zone ·
Free Resource

This article is featured in the new DZone Guide to DevOps: Implementing Cultural Change. Get your free copy for insightful articles, industry stats, and more!

In the 2018 DZone Guide to DevOps, I provided a view on how to approach your DevOps roadmap, and I think it is time to provide a second chapter. Last time, I focused on which applications to choose for the roadmap; this time, I will talk about the practices. While there are several ways of approaching this, we see certain patterns. I will start with the most common one, which follows five steps. At the end, I will provide two alternative views so that you can pick and choose what works best for your organization.

Before I describe the three different perspectives of the roadmap, I want to highlight the core engine for change: the plan-do-check-adjust cycle. Each significant change you make should be driven by this improvement process, which means that before you implement a change, you need to define how you will determine the success of that change. Clear success criteria and/or metrics that show you whether the change has made the difference you were hoping for are important and need to be defined before you implement any modifications. If you follow this process and align roughly with one of the following patterns, I am sure you will see significant progress. After all, your context is unique, and hence, you need to have a roadmap that supports the ability to adapt as the roadmap hits your context. 

First Step: Reduce Variables

Many organizations start with an environment that is full of variables: different processes, different environments, different tools, and several permutations of configurations and data. All this makes automation hard and reduces your ability to learn as each variable could be the cause of the problem. The first step is to look at all those variables and see what you can remove. Can you align the patch levels across environments? Can you deploy the same version of the application across environments? Some variables can only be removed later on, but understanding what all the variable pieces are and doing a clean-up first will make later efforts easier.

Second Step: Document the End-to-End

Someone once told me: "You cannot automate what you cannot document." After all, automation is a form of documentation of a process. What is even more important is that automating a bad process just creates more problems. I also think that writing down a solution forces you to think it through in a way that verbal communication or just starting to write code does not. Don't write huge documents but write enough so that someone else can look at it and review your new process for automation. That way, you get the chance for a peer review. I also know from experience that it is very difficult to get to 100 percent automation immediately. Having process documentation is important for visualizing how much of the process is automated. Below is an example deployment process diagram.

Image title


Third Step: Start With SCM, Build, Deploy, and Environments

Following the same line of thinking, the first capabilities that make sense to automate are the ones that reduce variability in the solution: SCM, build, deploy, environment configuration, or provisioning. Having gaps in any of these will mean that your environments are potentially not aligned and any problems you find might have more to do with the environment than with the application itself — the typical "it worked on my machine" problem. I have seen integration test environments where less than 30 percent of defects were functional and all others related to these core DevOps practices. On a positive note, these are the easier ones, and in my experience, you can almost always solve these with high levels of automation; even not 100 percent automation adds value here as you reduce variability.

Fourth Step: Test Automation

The next step is to invest in test automation. Test automation is by far the DevOps/Agile practice that I see fail the most. The problem is that in test automation, you are testing the whole system and hence, you require a framework that can orchestrate across the system and manage the data flows. But one thing is certain: if you don't use test automation on a stable and predictable base of environments and applications, then all you do is very quickly and automatically validate that you have a problem. That is not the point of test automation; rather, it is to validate that your application works correctly.

Fifth Step: Self-Service Capabilities

Once you have a decent level of automation, you can start to enable them as self-service capabilities managed by a platform team. This will help you to establish autonomous teams and reduce the silos. Your Agile teams can consume these services as required and can provide feedback back to the platform team for further enhancements. This is logically similar to using a provider like AWS or Azure, except that you provide a solution that is contextually meaningful for your organization.

Alternative A: Use a Technology Tree

The above five steps have proven to be very useful for me, especially in the context of having a central platform team that enables Agile teams. If you prefer a more federated approach, then I can give you an alternative solution. Inspired by the technology tree from the computer game Civilization, my team and I created a technology tree for continuous delivery. A technology tree describes certain technologies or practices and the prerequisites required to enable it (e.g. you need wheels, engines, and combustion to build a modern car). In our technology tree, we had a description for each DevOps practice supported by outcome and progress measures that teams can use to see how they progress and what impact it has. We handed this technology tree out to all our teams and they could fill it in as they progressed. We did highlight a few central capabilities like our asset repository and our test automation framework, which teams had to integrate with, but otherwise, they could create their own journey.

Image title


Alternative B: Look at the Roadmap From the Puppet State of DevOps 2018

Last year, Puppet came out with a new State of DevOps that looked into the common adoption roadmaps, and their research led to a very similar roadmap to the one I described above. For full details, you can read the report here. In summary, this roadmap aims to normalize the technology stack and reduce variability first, before implementing core DevOps practices and automating infrastructure delivery. As the last step, the enablement of self-service capabilities aligns with the last step of my roadmap described above.

Image title

As you can see, there is no one correct way to adopt DevOps, but there are common approaches that have proven to be successful. There is no need to make your own painful experiences of failed automation projects or DevOps transformations. Take one of the proven roadmaps and adapt it along the way with the PDCA cycle and you will be on the right track. Just make sure you are not biting off too much too quickly. Take small, incremental, and iterative steps in your transformation.

This article is featured in the new DZone Guide to DevOps: Implementing Cultural Change. Get your free copy for insightful articles, industry stats, and more!

Topics:
devops ,implementing devops ,self service ,variables ,devops guide ,roadmap

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}