Change Management in the World of Continuous Delivery

In your career, have you ever submitted a service ticket? For example, submitting a Jira ticket or a Service Now ticket to accomplish a task. For those in engineering, tickets can be seen as a currency and a curse at the same time. Change management can take many forms, from tickets to get IT tasks done to approval/audit processes (e.g. manual approvals of changes). The infamous “change advisory board(s)” or CABs might still be around in your organization. 

What Did Change Management Look Like Before Continuous Delivery?

The quintessential ticket-driven change management, e.g. traditional change management, was the experience before the rise in Continuous Delivery practices. Lead time for changes for additional infrastructure took significant time. On the other side of the coin in change management, the evidence needed to progress a change through (e.g. in change control board) could take significant time to document and include in a ticketing system. 

In the below infrastructure example, software developers would need to coordinate additional resources and/or changes to be deployed as their changes march along the software delivery/development life cycle, though the needed infrastructure/capability to deploy changes/configuration are not done by the developers, but system engineers. 

On average, tickets would have to be facilitated and appropriate lead times adhered to. Creating net new infrastructure with a low risk of change before a deployment (e.g. no risk of downtime) would still take long lead times. 

The tickets would be disparate because different teams would fulfill each request. 

The old adage is very true: you cannot improve what you cannot measure. Lengthy manual approvals can be quite subjective and hard to measure. The final result of a manual approval is “approved” or “denied” status. The incremental steps and evidence that the approver has to go through might not be accurately captured. For system/infrastructure-related tasks, the progression is similar: the ticket is completed. Each team fulfilling requests would manage specific metrics. With the DevOps movement focused on breaking down silos, lengthy change approvals themselves are pillars of silos and must be rectified.  

How Did the World of DevOps Improve/Worsen Change Management?

Prior to the DevOps movement, ITIL (Information Technology Infrastructure Library) was a popular set of practices for IT Service Management. ITIL/ITSM are pretty process-heavy. When several advances in technology, such as Infrastructure as Code (IaC) and containerization paired with the DevOps movement, teams could execute a lot quicker and more consistently. 

Where Does Change Management Happen in CI/CD?

There are multiple places where change management can occur in CI/CD (Continuous Integration and Continuous Delivery/Continuous Deployment). Typically, change management is used as a judgement call to progress the CI/CD pipeline. Common areas that incur change management rules are usually entry/exit criteria - for example, after a build and before/after being deployed to an environment. 

Three Tips to Improve Change Management in CI/CD

The great thing about modern CI/CD platforms is that you can model your entire process as a pipeline/workflow. Looking at our most common CI/CD Patterns blog post and eBook, there is a wide variety of pipeline choices out there. 

Model Everything

Sometimes, change management can seem like a black box; the granulator of tracking a ticket is left to the team fulfilling the request, or the approver, to determine what metrics look like. However, if you model the entire process, including timings for those requests/approvals, bottlenecks can become very apparent. Working with the team that fulfills the request to expose additional metrics can shine a light on how to reduce bottlenecks. 

Lowest Common Denominator 

Bespoke change management processes are detrimental to automation. Running with the status quo is safe, but does not better the craft of delivery. Even small shifts/changes in change management can benefit the entire delivery pipeline. DevOps/platform engineering teams have to create tools/products/processes to try to capture as much of the workload as possible. Finding one part that transcends applications - for example, the automatic creation of a ticket - can be the catalyst for improvement. 

Experiment With Change Management 

Experimentation is key in modern software development. As an example, for an emergency change in a production environment, why are certain change processes skipped in the name of brevity? Looking at success ratios there can paint a picture that some stringency of change management can be reduced. Finding the balance of making new standard changes approved with the same speed of emergency changes is one key experiment. Experimenting with different levels of overhead might not be the most pleasant exercise for development teams - though in the culture of experimentation, nothing is off the table. 

How Harness Does Change Management

The Harness Platform is capable of many points of view when it comes to change management. Harness is an excellent orchestrator of automated confidence building. However, depending on the industry, sometimes an approval needs to be made by a human or another entity. Harness has support for leveraging manual approvals in the form of Jira/Service Now tickets or inline of the pipeline execution itself. 

Below is a Jira ticket that was automatically created during a pipeline execution in Harness. By moving the Jira ticket to the Approved state, the pipeline can continue to progress. 

In totality, the deployment pipeline can support as many automated or manual approvals as required to deploy artifacts safely. 

For example when deploying to QA, Harness can orchestrate the myriad of automated tests for coverage. 

No matter where you are in your change management journey, Harness is here to help. The Harness Platform has the ability as much automation or as much human-centric tasks as your organization requires. By modeling all of your processes in Harness, you can start to see where the bottlenecks appear and can start to make improvements in those areas. 

Cheers,

-Ravi