Automated change management in a DevOps world
If you’re an IT engineer like me and you’ve worked in an enterprise environment, you’ve probably had to deal with ITIL, the ITSM framework (v1 through v3 in particular). In theory, ITIL should have a positive influence on the quality of IT services when the implementation of processes are effective and not overly bureaucratic.
That said, ITIL can feel like a burden sometimes. As an engineer, I am only concerned about executing my change and I’m confident that the result will be successful.
And then there was DevOps, the holy grail, a methodology that can solve all software development and deployment problems. Agile iterations, Continuous Integration and Delivery, T-shaping, you name it.
I have to admit that all this bolsters my ego as an engineer, albeit unjustly. On paper, I should be exempt from the Change Management circus because I have a glass bowl that allows me to predict the outcome of software deployment.
But is that justified?
Some myths about ITIL and DevOps
1. ITIL and DevOps are mutually exclusive
ITIL and DevOps are just as different as fire and water and DevOps is supposed to be the superior option. However, when both ITIL and DevOps are implemented optimally, they won’t be in each other’s way, but rather complement each other.
DevOps is a software development philosophy that aims to optimize cross-functional collaboration and reliability of deployments.
On the other hand, ITIL is an implementation framework of IT-service management, designed to better integrate IT with business demand and strategies.
There might be some overlap but in essence, these two systems address different problems.
2. DevOps is a replacement for ITIL
This is simply not true. IT departments might be moving away from process silo’s, but somehow they still need to engage with IT-service management.
3. ITIL slows down teams by subjecting them to complex processes and the obligation to provide documentation
When ITIL processes are aligned to the organizational culture and business strategy, they will have a supporting effect instead of an obstructing one.
An important difference between ITIL and Continous Delivery is end-to-end automation: Continuous Delivery pipelines are automated processes.
Besides a possible Pull Request review or a production deployment gate, there are no manual activities in the pipeline. Also, it’s not always clear what exactly will change in the application or underlying infrastructure during deployment.
If we want to engage with Change management, then we should automate the activity of the Change registration. Implementing manual gates in the pipeline for the engineer to do a manual change request is not desirable in my opinion.
Automated Change management and Continuous Delivery
To achieve Automated Change management in a Continuous Delivery pipeline, we need the following components:
1. Repeatability and Predictability
Repeatability and Predictability are some of the pillars of Continuous Delivery. We utilize immutable infrastructure and use low-risk deployment methods that assure us that the deployment is safe, which can be proven when audited by merely codifying our infrastructure and pipelines.
2. Automated Standard Change
Now that we have a safe low-risk deployment method we can implement an Automated Standard Change.
Try to achieve this in cooperation with the Service Management organization, so that the ownership is clear and the innovation is achieved together.
3. Quality services
Instead of registering a Change request in a graphical user interface, we should be able to register a change by consuming an API of the Change Management system (modern service management platforms like ServiceNow exposes its services through an API).
If this is not available out of the box, it should be developed.
4. Automate the change registration
When it comes to change registration, we are not interested in activity from feature branches or automated testing in the pipeline, but rather, the actual change in the application and/or the underlying infrastructure.
How it works:
- Before a production deployment is executed in the pipeline, we create an automated change via the change management API.
- When the deployment is ended, be it with success or failure, the change is automatically updated and closed with evidence logs.
5. Don’t be part of the pipeline process, but observe
Instead of doing automated change management from within the pipeline, it is better to observe the deployment pipeline or job and invoke automated change management.
The advantage is that automated change management operates independently from the pipeline.
As an example, within AWS this can be achieved by observing emitted Cloudwatch events from pipeline jobs by using an independent micro-service.
In closing
Until now we assumed that most organizations have implemented ITIL v1-v3. But what about ITIL v4? At first glance, ITIL v4 aims to align with methodologies like IT4IT, Agile, DevOps, and Lean.
We will dive deeper into this in a future blog.
