Welcome to part 2 of the twelve-factor DevOps blog series. In the first part, we gave a brief introduction to what DevOps is and what it hopes to accomplish, plus discussed the importance of automation. Today, we’ll be addressing the topic of unification.

Factor 2: Unify

Once you’ve begun automating your processes, you’ll realize that they often have many similarities. At this point, you need to unify them by creating shared libraries and tasks, and then reuse the same tool across the processes. This is a familiar concept to software engineers and is easy to extrapolate to other areas of the business.

In a software build process, no matter what application you’re building or language you’re using, you’re going to want to execute the same general steps:

• Perform static code analysis
• Perform a vulnerability scan
• Compile the code
• Run unit tests
• Package the application for distribution

You could use different tools to execute the code analysis on an app-by-app basis, but by reducing that to one, you have can have a deeper insight into how the tool works and what it means, as well as have fewer integration points.  This also lowers the overall complexity of your workload and allows you to focus on more important things.

The static code analysis stage of a CI/CD pipeline can be written directly into the pipeline of every codebase, but that becomes harder to maintain as the number of repositories grows, especially if you need to change the process. A standard library for the pipeline takes a small number of inputs and then executes the same steps every time, in keeping with DRY principles and the automation we discussed earlier. Now if you must update the process, you only change the process within that library instead of each distinct place you use it.

It’s critical to realize that unifying will almost certainly surface technical debt.  As you work through unifying your processes, you are likely to find that you’ve changed how you’ve done things over time. Identify the places where exceptions exist and evaluate them to determine if they need to remain distinct or not.  If the exception should not exist, you’ll need to bring the process up to your current standards.

For example, we have a client who used manual FTP and SSH commands to deploy applications to their servers.  We showed them how to automate this process by using Ansible.  That, unfortunately, left them with two distinct processes.  We then worked with them to identify the applications that were no longer necessary and update the deployment process for the ones that were still in use.

Finally, unification does not mean that you can only have one tool or process for everything.  Smart DevOps means picking the best tool or process for the job and using it where it’s appropriate because not everything can be handled a single, common process or tool. Python, Java, and Go utilize different tools, but as long as you are working within a single language, you should use the same tool(s) and processes for every application.  It’s okay to do something in two or three ways if that’s the minimal number of processes you need.  The goal is a reduction in variability, not its absolute elimination.

Editor’s note: This post is part of a 12-part deep-dive series on the foundations and benefits of DevOps.