Much of the movement in DevOps has happened from the perspective of software development. And, while systems managers have adapted to the new order, the one area that has been a drag on achieving greater DevOps success is in change and release management.
And at least one service management provider believes automation is the key to bringing change management and release management up to speed with the rest of the development and delivery capabilities that are driving organizational transformations.
Rohit Jainendra, general manager and vice president of the DevOps unit at ServiceNow, said in many organizations, it can take as long as 23 days to get a change approved. Using policy-based, automated change and release management, he said that changes can be made and approved instantly.
Jainendra said he believes the key to modernizing and evolving practices around change is to leverage the data being generated by the tools developers use to create policies for automating change. “There is a rich set of information that’s being produced by these DevOps tool chains as well as the information that’s being collected from operational environments, in terms of performance monitoring and event management, and so on. There’s a lot more data that’s now available that lends itself to a more policy-based approach or automation of the change process itself.”
Why do we need this type of change? Jainendra explained it’s because the current method of approving changes has some amount of friction, which slows the process down. Users have to go into the change management tool, log in a ticket, provide information about the change, fill out a multi-question form, and then wait for a change approval board to review the changes. “If all the information has been provided, then the CAB can go ahead and approve it; otherwise, there’s a back and forth in terms of the data that needs to be provided — things like test results, or was there any adverse performance impact because of that change,” Jainendra explained. “Those kinds of questions have to be answered before the change can be approved.”
And, in the current development world where Agile development is practiced and companies are now looking at orders of magnitude increases in making changes to applications, it’s becoming impossible to keep abreast of that work with manual processes.
To solve the problem, Jainendra spoke of gathering all the data being thrown off from test tools, pipeline tools and project management tools, to create policies around change and release approval. “How can change become an API, that regardless of the tool that you’re using, how can we then sort of invent the ability to create a change from whichever environment the developer is in? If they’re using Jenkins for CI and CD, or running their builds in the pipeline, maybe it’s a plug-in that sits inside of Jenkins that can then create that change record at the time of need. Or, if you’re a developer who does all their work in Jira, where you have your stories and so on, perhaps there’s a button inside of Jira that can also grab the necessary data and create that change ticket inside of ServiceNow.”
Once that is done, the policy model can be created for automatic approval of changes. If changes are for non-revenue-generating applications, or if regression tests pass, when the changes fall into categories such as those, the system should be able to automatically approve them, freeing up people to focus on the more high-risk changes that do require more in-depth analysis and understanding before they can be approved.
“The change in posture is leveraging data in a much bigger way than we have traditionally have,” Jainendra said.
