IT Release Management: ManageEngine’s playbook for faster and successful rollouts and continuous delivery

Featuring ManageEngine’s release and deployment management framework for feature delivery efficiency and collaboration across enterprise teams.

Glossary

Introduction

Picture this: You’re gearing up for your next launch. There’s a lot of excitement and a little tension in the air. It’s a big deal, and you can’t wait! You have to roll out quickly with reliability and ensure it doesn’t disrupt services, especially for the top-tier customers relying on you for their day-to-day operations. With a high-stakes launch like this, you can’t afford to miss any details. That’s why you need a robust release management framework.

Release and deployment management is the process of rolling out software updates or deliverables to users without interrupting services. It’s not just about getting it out there; it’s about how fast and how efficiently it’s done.

So how do you do it?

Is this e-book for you?

If you think you need a new release management process in place or if you’d like to fine-tune your existing process, then you’ve come to the right place. In this e-book, we’re getting up close and personal with the teams behind our successful rollouts to understand ManageEngine’s approach to release and deployment management.

By the end of this book, you’ll gain key insights for a solid and, more importantly, scalable release and deployment management framework.

This means we’ll be taking a microscopic look at:

• Workflows and standard operating procedures.
• Metrics that influence decision-making.
• How-tos and templates.
• Our biggest challenges and how we handle them.

Make no mistake, we’re far from perfect. Although release management isn’t unheard of, it’s still an evolving discipline in ITSM and it has a long way to go. We hope our two decades’ worth of trial and error will be a good learning experience for product managers, engineering heads, and development teams alike.

Let’s get started!

Change vs. release vs. project management

A common question that arises when talking about release management is, “Isn’t it just project/change management?” No! Although interconnected, release, change, and project management deal with different aspects of the release cycle. They also require dedicated roles for their respective duties. It’s a complex process—you can’t have one manager doing it all!

Think of it as a 10,000 piece jigsaw puzzle.

• The change management team decides what picture should be on the puzzle. What do customers want? What picture would make them happy? Why do they want it? What did the previous puzzles lack that we should now incorporate?
• The project management team ensures we have the materials needed to design the pieces, and it also decides how long it should take to put it together.
• The release management team then has the demanding job of cutting the pieces into the right shapes and assembling them into one big picture that makes sense.
• The change management team then reconvenes to get customer feedback. Did this picture work? What do they want next?

Are change management and release management the same?

No. While change management provides a medium for analyzing the consequences of a change, release management is used to deploy that change efficiently. Both are interconnected, however, and need each other for streamlined delivery of products and services.

For major releases, a change advisory board (CAB) must provide approval before the release is deployed into the live environment.

Are project management and release management the same?

No. Project management helps organize the resources required for a release while release management utilizes these resources to implement changes. A project may not always result in a release. Like change management, project management and release management are interconnected and rely on each other to ensure streamlined delivery.

The magic triangle:

Navigating through the tricky relationship between configuration, change, and release and deployment processes

We've talked about release and change management.

What about configuration management?

Per Axelos, configuration management is defined as "the process responsible for ensuring that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed."

A configuration management database (CMDB) is a centralized repository used to monitor all the individual components, or configuration items, involved throughout the release process and map their relationships. A configuration item can be any entity required for a release to be carried out, like a server, an employee, or a service like email.

Everything related to a release has to be documented and up to date in your CMDB because:

• You’ll refer back to it for each release.
• It has information on the latest working version (in case you need to roll back).
• It helps you prepare for the audit season.

At Zoho, we use our own repository to ensure the contents of each release are stored. This includes changes implemented in releases and the status information on all authorized software and hardware. We allow developers to use external repositories, and they can also migrate to the organization’s repository service.

There are many reasons why we chose to self-host. First, using a personal repository made room for features like code review, code validation, and static code analysis that are unavailable in the free versions of external repositories. Our repository team is also working on additional features and integrations. Second, self-hosting is both cheaper and safer. Growing as an enterprise, we have to face facts: Eventually, we’re going to be a target for hackers. Instead of a “we’ll cross that bridge when we get to it” mentality, we’re being proactive and doing what we can to step up our security at every level.

Finally, the connection between change, release, and configuration management is a team with well-defined roles and responsibilities. Release management is a multi-department process. Apart from the release teams (which we’ll talk about in detail later), we also need to make sure other teams are in the loop: