For quite some time now, DevOps is changing the game for software builds and deployment. Add to that innovations like Infrastructure as Code (IaC), containerization, and highly automated cloud and on-prem activities, and you might feel like we do, that DevOps will clearly continue to see many more enhancements and new directions in the future. Without trying to harsh anyone’s buzz, one thing that is quickly becoming a hot topic of conversation is change management DevOps.
Before we dive into Change Management and DevOps, let’s just align about what we mean when we talk about Change Management. Do not confuse this term with Configuration Management. We are not talking about software revision control; we’re talking about something bigger. The term “Change Management” focuses on the methods and approaches that support, trace, and document organizational changes. For the sake of this post, we won’t discuss organizational change, but rather refer to change in processes, systems, or infrastructure, as part of change management, which also include changes in deployment environments. In the modern era, organizations must change their structure or infrastructure quite often according to market changes, technological changes, new legislations and regulations, and other forces that drive the need for a change. The bigger the organization is, the more challenging the change would become. Clearly, we need good practices and processes to support the success of the change.
The need for solid change management and DevOps to coexist is vital for continuing to protect the systems we oversee, with minimal fractions and shocks. However, the introduction of DevOps change management in and of itself is designed to “tap the brakes.” Just like any other machine with moving parts, it’s a matter of adjusting to these changes. For those ready for a challenge, this is yet another opportunity to make the process of change management just another step towards deliberate and well-communicated changes to production environments.
What do we mean when we talk about change management?
The concept of change management is not new. Some feel like change management hinders the velocity of software development teams. This is due to a need to implement traceability and methods that show an audit trail for changes affecting production environments. If integrated into already existing automation and practice, implementing DevOps change management can be less painful.
This type of change management for the modern enterprise or small business is recognized as IT Service Management, or ITSM. This is a method that is used to control all aspects of changes related to infrastructure and configuration to production. What may be foreign to some DevOps teams is the amount of information we are now required to retain for audit purposes. This can sometimes prevent small changes from happening as fast as they could due to the additional change management processes put in place.
How does change management fit in DevOps?
In many ways! The most relevant of which is the fact that it is required for many businesses. Not just for internal auditing reasons, but for compliance and certification. There are data standards that must be followed to do business across the globe. For example, the General Data Protection Regulation (GDPR) has been effective since May 25, 2018. Anyone doing business inside or outside of the EU must comply with these standards or risk hardships related to continued business in that region. These types of standards and regulations are part of the reason both Enterprise and smaller companies should consider DevOps change management.
Consider the fact that we are able to make changes on the fly. After all, that’s the whole reason we went into automation in the first place. While it might look like change management and DevOps don’t mix, the right DevOps mindset and tooling will show it is actually a safe option. In a sense, this protects the DevOps Engineers thanks to the additional communication and finalizing of processes that show due diligence.
In short, change management and DevOps aren’t just relevant as individual methodologies. They are both relevant and necessary to the point that integrating the two makes sense where the opportunity presents itself. Introducing automation tooling that promotes change management via faster iterations using your existing CI/CD tooling is a solid step towards combining the two disciplines.
Who are the stake-holders for change management and DevOps?
If you asked this question just a few years ago, you would likely get a smaller count of those that had a DevOps change management implementation. The size and scope of such implementation depends on many factors. With the addition of the earlier mentioned regulations and a focus on cyber security, the need to know what’s happening to customer-facing systems has expanded beyond just the IT or Software Teams.
Anyone who has to have accountability is smart to implement ways to show or prevent certain changes to production environments. It is easy to think of this as a “C.Y.A.” situation but having more eyes on the proposed change and a way to inform others of status along the way is the actual goal. Peace of mind is helpful to keep a well-oiled machine in motion.
There are definitely going to be exceptions depending on the task at hand. For instance, if we as DevOps engineers were to do a change management workflow for every access request, nothing would get done efficiently. Another possible scenario would be troubleshooting performance or errors in production. These and other operations executed on a production environment are low-touch and generally considered acceptable to be done without change management committee approval.
What are ways DevOps compliments change management?
From the start, the DevOps mindset helps with tracking changes by using branching strategies that aim to protect the main codebase. This is an entry point to aligning a change with a task in an Agile workflow. Whether the change involves releasing a new version to a production environment or changing configuration in such a resource. In the case of a software update, this initial “tracking” of the change through branching helps engineers troubleshoot, revert, or fix-forward only those changes.
Earlier, we mentioned today’s focus on cyber security and compliance. In many ways, DevOps has already embraced this with DevSecOps and a “Shift Left” approach to software development. Finding issues prior to them becoming an actual problem can prevent a lot of wasted time in a change management process.
Let’s look at a simple CM workflow:
- A request is made, and an initial analysis determines if the change should be approved or denied. While this sounds simple, the analysis not only consists of how the product is affected. It also surfaces how implementing the change may affect tertiary aspects around security, stability, and traceability.
- Planning is done by the implementation team and can be demonstrated to the change management board through documentation such as a release checklist.
- The board and other members involved in the change make an assessment and give the green light to move forward.
- The change is implemented as planned and any deviations are noted for the next release.
- Changes are reviewed to report their status to the group. Information on the success or failure and any other pertinent details can be discussed and documented.
- The change can be closed once all the prior steps have been completed.
The list of major companies that are successfully using change management grows with every sprint we work through. It’s no surprise that Google is an example of a very large company that has implemented this process. Along with them, are other recognizable organizations like Netflix, Lego, and Coca-Cola. You can learn more about companies and real life examples of successful change management, here.
Change management and DevOps Tooling
We talked a bit about some of the current technology in use that is being integrated into change management. The way teams use Git for their workflow is one way savvy teams are starting on their way to integrate traceable data for auditing or root cause analysis. But what other tools might DevOps teams use to assist with change management?
A simple tool, often used for showing a complete process, is a flowchart. Flowcharts and Process Mapping allows for a visual representation of the desired change. It is also referred to when looking to see if the change adheres to a specific order of operations. Similarly, Gantt charts are a favorite for project planning and also give the visual aspect to assist with a better view of the project.
There are also packages meant to help with the automation of workflows that may streamline a change management process. ChangeGear promises to help with that automation to support complex changes and business processes. Freshservice also helps with cloud-based change management by helping plan all aspects. They promise to help organizations streamline their planning from launch through necessary approvals.
Tasking feature requests or bug fixes are often done through Agile processes across the software development world. Part of that Agile methodology is the meetings, planning, and architecture information that is often included in the ticket in whatever tasking system is in use. Including markers in the development process is low-hanging fruit for a start in using change management and DevOps for automated compliance.
Scanning for security issues and compliance has become easier thanks to tools available in the software development industry that are designed to look for certain items. These items are based on current industry security standards as well as rules that can be created for specific uses on your team. They can be tied to an industry or based on regulations for compliance that are specific.
Still, more tools can be used in the process of change management that are the charge of many DevOps engineers and methods. Using Infrastructure as Code (IaS) allows engineers to design, validate, and implement new and changes to existing environments in a way that can be inserted into the process of change management. Tools like Terraform, Azure ARM templates, and Kubernetes manifests put modifications in a state that others can review and decide if the change should be approved.
Collaboration in conjunction with the tools already in place are the ways change management and DevOps work together for automated compliance. While not completely hands-off, many of the things we would normally check before implementing changes can be found using today’s tools.
In closing, we are just now seeing how automation can work with processes like change management. Finding new ways to use tools and engaging the community is one way to find more solutions towards combining change management and DevOps. Not all processes will work for your group. Focus on the portions that work for your environment and work towards continually improving ways to support change management through DevOps.
