Improve your Information Technology Infrastructure Library with automation

It may seem that with automation and agility, an Information Technology Infrastructure Library (ITIL) is outdated or old school. I don't think we've seen the end of this methodology yet, though. ITIL has served numerous IT organizations as a guideline and blueprint for processes, and it continues to be a significant tool for the IT professional. You can modernize your approach to ITIL with the automation of Red Hat Ansible Automation Platform and the principles of infrastructure-as-code (IaC), to make ITIL agile,  automated and more relevant than ever, including:

• Configuration management
• Change and release management
• Incident and problem management

What is change and release management?

Change and release management are related, but they are distinct.

• Release management: Planning, scheduling and controlling the build, test and deployment of a release. This is relatively easy to understand when it comes to a specific piece of software, but less so when it comes to infrastructure and configuration, but more on that later
• Change management: Planning and executing changes to a running system is something few operation teams like to touch. A change plan typically documents things like duration, impact analysis and a rollback plan. Such a plan must be reviewed and approved by a Change Advisory Board (CAB). In most organizations, a CAB is often understaffed and meets too seldomly, so approval is either perfunctory or takes too long. To reduce the amount of approvals required, it's common to define standard changes that are essentially pre-approved (but must be documented)

Release management and automation

It's all too uncommon to see infrastructure being properly versioned and released. Everything-as-code (EaC) makes this possible, if not easier.

The term "everything" encompasses, at the very least, infrastructure, configuration, documentation and (soon) policy. Ansible code placed in Git (or any other supported source code management system) together with its documentation can be handled like program code.

Following recommended practices common in software development, but possibly new to administrators, here are 7 steps you can take to improve your release management:

• Use branching and tagging to keep track of releases
• Version releases using semantic versioning
• Provide proper commit messages following the conventional commits specification to help generate meaningful and complete release notes without much effort. With proper commit messages, you can parse the output of git log to create release notes
• Use CI/CD pipelines to automate the build, packaging (e.g. as collections) and publishing of releases
• Automate tests in your pipelines to maintain the expected quality for each release
• For extra security, sign your releases using Ansible (ansible-sign), Git, or both
• Ensure that your automation content and its integration into Ansible Automation Platform is done automatically, and with versioning, using configuration as code (CaC) so that everything is under release management

To avoid overwhelming your teams, you can introduce each step individually and gradually, as part of a comprehensive automation journey.

Change management and automation

Automation and EaC introduce a further shift in ITIL thinking: Changes need to be considered and reviewed as they are made to the code (or to the inventory) before this modified code is applied to the environment. This means that change reviews are effectively delegated to the peer review process of merge or pull requests in Git before they hit production (automation) code. There are many ways to organize those reviews, but they need to be done to guarantee quality and knowledge-sharing between peers. That said, it must be clear that they don't replace automated testing. The two are complementary.

Once the automation content is in production, the aim of an organization must be to ensure that approvals don't stand in the way of the efficiency introduced by automation. In a perfect world, that would mean that each automated change would be considered a standard change. We don't live in a perfect world, so here are some real-world alternatives:

• Make sure automated changes are pre-approved, through a service portal integrated with your automation platform, ideally based on Ansible Automation Platform.
• If pre-approval isn't an option, make sure that the approval is integrated into your workflow so you avoid wait times. The following diagram shows how such a process could be implemented in the automation controller workflow (for example, using the certified servicenow.itsm Ansible collection):

A change approval process triggered through Ansible Automation Platform, creating a ticket and releasing the workflow once approved

A similar approach can be used to only notify your ITIL tool of choice about ongoing changes. A more modern approach could be to use ChatOps, if that fits your organizational setup.

A proper release management of your automation content makes rollbacks easier by allowing you to pick a previous release and apply it. The truth is that it makes it easier, but not always easy, so every aspect must be considered carefully. This especially applies to data changes, but that's out of scope for this article. Perfect rollbacks remain one of the big challenges of IT, even with automation.

Make change easy

Automation, especially with Red Hat Ansible Automation Platform and everything-as-code, can greatly improve the efficiency of an IT organization, especially releases and changes. You need to be ready to reconsider how processes, ITIL or otherwise, can be adapted to modern requirements without losing sight of why they were introduced in the first place. Most importantly, you must bring the people living those processes along with you, and that's one of the biggest challenges of all. It's also where Red Hat’s services can help.