How to close the gap between DevOps and Change Management

Lately, I have seen a gap arise between developers and the Change Management process. A gap that is perfectly logical, considering the Change Management process is obstructing the developers. It is undermining the true essence of DevOps – shortening the time-to-market of products and improvements (Dev) and maintaining product and process governance (Ops). However, the change process is often not in scope in DevOps, and therefore, left out in the DevOps Way of Working. But applying DevOps without any Change Management is actually only applying ‘Dev’ and forgetting about the ‘Ops’ part!

 

The problem
Developers have to manually request a change for every deployment they do, meaning less work can be done in a single Sprint. And on top of that, the developers don’t understand the need for changes, since all that will be changed is already registered in their commits. What happens is that less and less change requests are logged, meaning you will gradually lose visibility and control (the ‘Ops’ in DevOps). Eventually, this will result in audit findings, making it harder to trace and solve (P1) incidents or it might even turn out to be causing those.

Using standard change templates already simplifies matters, but it still forces the developers to exit their bubble to execute the change process. They would rather reuse most of the information already provided in their commits than copy/pasting this in a change template. In this case, automation with the Now Platform is the magic word, as it will unify the developers and the change process. But the technology will not accommodate the key principle of DevOps, team effort, all on its own. To be successful, you will need to align people and processes too.

People
Aligning people to processes is key. The developers must to be aware of the change template(s). Both the Change Managers and developers have to agree on how to populate the change template. Questions like which fields or values can be reused in certain cases or which values can be extracted from known data sources are examples of questions that the teams should answer while aligning. After that, you have to determine in which situations the Now Platform should be invoked. I will dive into that further under “Technology”.

Processes
Usually, a change process is already in place. But this process might not (fully) support automation. Many organizations use steps or phases that are not easy or logical to automate, like a Change Implementation Plan that needs to be written and added to the change, for example. Therefore, the cycle of a change might not even be complete while the commits are already put into production. For example, the developer has created a new change request and assumes that his job is done. The source code was reviewed, and the merge requests have been approved, resulting in a deploy to production. But what he didn’t notice was that the change was actually set on hold because a major update was already scheduled for the target server – resulting in a deployment failure.

You can prevent situations like this by incorporating a risk-based approval step. For non-production services, the fault tolerance is usually higher opposed to production services, since there are no end-users. So you might want to have an approval in place for production releases too, while that might not be necessary for non-production releases. Another countermeasure you can take is using the automation capabilities of the Now Platform, which will prevent deployment of non-approved and unwanted changes.

 

 

Technology
As soon as the people are aware of the change management process, and Change Management is ready to be automated, you can start leveraging the power of the Now Platform to integrate with (and set up automation for) several products:

• Product Backlog
  All changes in DevOps stem from Stories. Why risk losing change requirements because of unknown change roots? When you integrate Jira with ServiceNow using our Connector4U application for example, you will be able to synchronize Stories from the Jira backlog to the ServiceNow instance. Then you can use all of this data to populate or enrich the change request. And when you set up a bi-directional integration, Stories can even be enriched with an URL leading to the change later on, so that deployment can be tracked from both systems.

• Source Control
  Every change to source code is stored in a central repository. Usually, one or multiple Stories from the backlog will result in a new version release. So, all commits that contribute to that release will be bundled in the Source Control. However, these commits have to be deployed to production in the end and a change request will need to be created for that to happen. You can automate this step entirely with ServiceNow. By using change templates and risk-based approvals, the source control only has to call an API and provide a simple payload with some data to enrich the change request. This already adds great value to the CI/CD pipeline. But that’s certainly not the only step you can automate!

• Automated Tests
  What if the pipeline contains an automated test that has to be executed before deployment can take place? There is no reason why a person has to press that button manually. ServiceNow can automatically trigger this after the change has been approved. After response, the change either proceeds or when the test fails, a task is created for the developers.

• Deployment
  After approval and a successful test, ServiceNow can trigger the actual deployment as well. How? By merging the developed code with the production code or over an API. Upon response, ServiceNow notifies the product owner and/or the users about the product update.

• Documentation
  After a successful change deployment, the product documentation has to be updated as well. You can configure ServiceNow to include a link to the Knowledge Base leading to the product feature article once a change has been completed. That way, you keep the developers informed automatically. To further ease the documentation process, you can even extract useful data from the merge requests to populate the Knowledge Article.

The added value
Stop letting Change Management delay code deployments for days or even weeks. ServiceNow DevOps instantly solves this problem thanks to its extensive integration capabilities with DevOps tools. This means you can free your developers from their administrative tasks and benefit from:

• More developing time
• Faster time-to-market
• No audit findings
• Less P1 incidents
• Happy Product Owners

If I have sparked your interest with my article, please don’t hesitate to contact me to discuss how we can solve your DevOps or Enterprise DevOps challenges.

---

Watch our webinar recording

How to thrive in a fast-changing world using Enterprise DevOps

Learn how to align DevOps teams to business goals with ServiceNow and how to speed up change without compromising on control nor agility.

---

Join 1400+ ServiceNow professionals

Sign up to our monthly Flow@Work Exclusive newsletter to get free access to our expertise and lots of tips and tricks to make work flow on the Now® Platform.