It Release Management e Book

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
ACRONYM STANDS FOR
CAB Change advisory board
CD Continuous delivery
CI Continuous integration
CMDB Configuration management database
ELS Early life support
KPI Key performance indicators

QA Quality assurance
UAT User acceptance testing

01 Introduction
02 Is this e-book for you?
03 Change vs. release vs. project management
09 Chapter - one
A retrospective of the old release management process:
The good, the bad, and the ugly
11 Chapter - two
A look at release management as a critical DevOps function
at ManageEngine
15 Chapter - three
ManageEngine’s release management framework. / Release policy and
methodology / Types of deployment / Stages of the release manage-
ment life cycle / Metrics that matter
34 Chapter - four
Case study: How we rolled out Analytics Plus 5060 smoothly
42 Chapter - five
Conclusion / Common release management challenges and best
practices to deal with them / Final words
WHAT’S
INSIDE?
IT release management: ManageEngine’s playbook for faster and successful rollouts and continuous delivery / 01
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.
Change management Release management
The process of controlling The process of planning, scheduling,

the life cycle of all changes, and controlling the build, testing, and
enabling beneficial changes deployment of releases and delivering
to be made with minimum new functionalities required by
disruption to IT services. the business while protecting the
integrity of existing services.
Pre- and post-deployment Deployment activities

activities
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.
Project management Release management
The process of planning and The process of planning, scheduling,

coordinating the resources and controlling the build, testing, and
needed to deploy a major deployment of releases and delivering
release within the predicted new functionalities required by
cost, time, and quality estimates the business while protecting the
integrity of existing services.
Data collected is usually Data collected is required for the life

required for the length of the of the service to increase efficiency.
project.
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.
Configuration
People
Change Release
Development Controlled test environment Live environment
Back-out
Back-out
Testing
Acceptance
Development
testing
Deployment
Planning
ELS
Submission
Review and
close
Configuration management database[CMDB]

!
Incident Change
initiated
Customer CAB
approved
Release Release Development Quality assurance UAT Release Support Release

requester engineer lead lead owner engineer manager
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:
Pre-sales and sales

Before you even come up with a release request, consult
with pre-sales and sales. Most customers and leads are
upfront about their expectations. These teams work to
come up with use cases that will help you formulate a
release plan that has all the functionalities customers
require. They also need training before a release is
deployed.
Customer support
Your support team gets the most (brutally) honest
feedback about products and features because it comes
straight from the end users. It’s crucial to interact with
them to figure out exactly what customers are looking
for. Like sales, they also need proper training before
each release is deployed.
Marketing
In a competitive market, it’s not just about what your
customers want. The marketing team has the most
insight on what’s trending and what your next move
should be. They also update customer-facing content to
address new releases.
Legal
A legal team is needed in release management to review
compliance requirements. They may also mediate
vendor negotiations and beta testing if you have
external dependencies.
Finance
$ The finance team oversees all release-related costs, like
activity costs, resource costs, and procurement costs.
Chapter 1
A retrospective of the old release management process:

The good, the bad, and the ugly
?
The release management process at Zoho isn't centralized. Each product team has its own
schedule, process, roles, and tools to roll out updates effectively. This makes sense for us
because we have over 90 ManageEngine products alone. It wouldn't be possible for one team
to oversee all releases.
We have the right tools now but before we established a streamlined release management
process, we faced multiple challenges.
Problem 1:
Lack of dedicated tools
When we started out, we weren’t using the dedicated release
management workflow tool that we have now. Team members
didn’t have a top-level view of each feature’s status. Some
members felt the process lacked transparency—and they were ?
right.
When the schedule is made public and updated religiously, it

allows team members to plan out merging, testing, and other
phases of their current and upcoming releases. Knowing when
their input will be required also allows them to plan their day
accordingly.
Problem 2:
Lack of knowledge sharing between
collaborating teams
Initially, the entire release management process, including
testing, was handled by a few members, but tasks weren’t ?
divided across the entire product team. This made it
challenging to mobilize releases, and features started to pile
up on the stack. Overall, the whole process lacked flexibility.
Problem 3:
Unnecessary downtime for critical
resources
Let’s say we’re trying to deploy patches, like security patches or
OS patches, onto a mail server. If there are multiple patches,
they need to be applied simultaneously to avoid repeated
downtime and service disruption in the mail server. We
needed a clear strategy from day zero so we could map out the
required functionalities for each release and get them done all
at once.
Problem 4:
Lack of communication
Feature owners must get final approval from a designated
approval board. You do your job, send it to someone for
approval, and send it out. Sounds pretty straightforward,
right? However, this didn’t work out to be the well-oiled
machine we thought it would be. Approval, despite automatic
notifications, took an unusually long time, creating a setback
in the pipeline of releases.
Upon further assessment, we realized this may be because

reviewers aren’t always involved in the entire process; instead,
they were called in at the end for their approval. This meant
they needed more time to study the stage and understand the
release and how it affects users. We decided at this point that,
going forward, the best way to speed things up was to involve
the approval board at all stages of the release and engage in
discussions as needed.
Problem 5:
Non-parallel approvals
Approvals in each stage also took too much time because they
weren’t conducted simultaneously. We had to modify that
by enabling individual approval processes concurrently. For
instance, client review, API review, and migration review can
be done simultaneously since they’re done by different people.
Chapter 2
A look at release management

as a critical DevOps function
at ManageEngine
The traditional approach:

The waterfall methodology
Back when release management first became a
part of ITSM, the waterfall approach was the go-
to strategy for deployment. In fact, some of our
product teams continue to follow certain aspects
of it. The waterfall methodology is a simple linear
sequence of events, meaning you don’t start the next Plan
stage of the release cycle until the previous stage is
completed. Things going into the release are planned
upfront—requirements, prototype, designs, etc. The
development takes place in a separate branch. After
development and unit testing are complete, the code
is pushed to the main branch where it’s tested once Build
again and released. Unless any issues occur, the
completed feature isn’t touched again.
The problem with the waterfall method is that the

time invested in each stage isn’t always equal. We
Test
might spend, for example, 30% of the targeted release
cycle duration planning. We may not always know Test
exactly what our requirements and expectations are
at this stage, so as we build, we figure out what needs
to be redeveloped. If we notice flaws or want to tweak
features towards the end of the testing stage, we can’t
just let a substandard release go live—we’d have to go
back to the previous stage. So it’s not always ideal to
Release
stick to each stage in a rigid manner.
Pros Cons
Not complex Time consuming and can cause delays
Detailed High risk

documentation
Well-defined stages Unsuitable for complex or long/continuous projects
Easy to use Difficult to accommodate changes
The waterfall method isn’t commonly followed anymore, but it would be ideal for startups working
on a budget or smaller projects with well-defined requirements.
The agile approach

The agile methodology is an incremental approach wherein a release is divided into multiple
sprints or iterations. This way, we can deliver quicker and smaller releases with minimal response
time to changes and fewer defects. It relies extensively on constant collaboration between product
teams and developers. Interestingly, agile software development even has its own manifesto, which
is worth a read.
Develop
Develop
Develop
Test
Test
Test
Design Deploy Design Deploy Design Deploy
SPRINT’S SPRINT’S SPRINT’S

OUTCOME CUMULATIVE CUMULATIVE
OUTCOME OUTCOME
There have been over 50 frameworks developed over the years, the most popular being Scrum,
Kanban, Extreme Programming (XP), and Lean. The agile method is suitable for releases with
multiple variables or when you need to deliver within a limited time frame.
Agile methodology is commonly preferred over waterfall because it:
• Incorporates changes even late in the development stage.

• Focuses on customer satisfaction.
• Delivers high quality products.
• Reduces unpredictable delays.
• Results in higher ROI.
• Encourages engagement between teams.
• Increases productivity.
DevOps
While the agile approach bridges the gap between
product management and development, DevOps goes CODE DEPLOY
one step further. DevOps is a set of practices that
PL
combines development and IT operations.

AN
OPE E
DEV OPS
BUILD
E
AS
RAT
LE
It doesn’t have to be agile vs. DevOps. Combining

RE
aspects of the agile approach, such as incremental

progress, with features of DevOps, like automation, TEST M O N ITO R
metrics, and cross-disciplinary team collaboration,
allows you to deliver quality releases to meet the pace
your business requires at lower costs.
CI/CD
Continuous integration (CI), continuous delivery (CD), and continuous
deployment are commonly followed practices in DevOps.
Continuous integration:
The practice of merging small code changes into the main code
or code repository. Since each team likely has multiple developers
working together, CI helps ensure everyone is on the same page. This
synchronization occurs frequently, maybe even multiple times a day.
Continuous delivery:
Once a new code is committed, these changes are validated through
build and automated tests. CD is an extension of CI where the build
changes are deployed into the staging environment for functional and
performance testing.
Continuous deployment:
Often used synonymously with delivery, continuous deployment is
actually the next step. The difference between the two is the level of
automation. With continuous deployment, builds are automatically
deployed to the production environment and monitored.
Staging environment Production
A A M
Plan Build Test UAT Release
Continuous delivery
Continuous integration
Continuous deployment
A A A
Plan Build Test UAT Release
Continuous deployment is out of scope for on-premises products, but it works for cloud
solutions if you have the right resources to keep up. For any completed release, there will be
some minor issues or enhancements. We have a couple of team members who continue working
on the code constantly and they keep pushing it to the release branch. This code will be retested
and taken up as part of the subsequent release.
Benefits of CI/CD
• Fixes bugs quickly

• Faster quality releases
• Effective communication between developers
• Faster validation
• Faster troubleshooting during tests
Chapter 3
ManageEngine’s
release management framework
Release policy and methodology

Per IT Process Maps, a release policy is defined as “a set of rules for deploying releases into the live
operational environment, defining different approaches for releases depending on their urgency
and impact.”
What a release policy includes:
1. Release level and identification
Release levels are categorized as major, minor, or emergency based on the objective and urgency
of the release. Release identification refers to the number and naming conventions. For example,
major releases may be numbered in increments of one (V1.0, V2.0, etc.) and minor releases may
be numbered in increments of 0.1 (V1.1, V1.2, etc.). This varies based on the product team or
organization.
Level Definition Identification example
A release to introduce a new

functionality. It can also be an Launching a new product
Major
accumulation of previous minor E.g., Product V1
releases.
A release to makes changes to Adding a new feature

Minor
existing functionalities. E.g., Product V1.1
A temporary release required to

Bug fixes
Emergency quickly resolve an issue. It’s usually
E.g., Product V1.1.1
followed by a major or minor update.
2. Expected frequency of releases
3. Roles and responsibilities (which we’ll talk about in detail later)
4. Documentation requirements
08.Review 01.Submission
and close
07.Early life
support
Release 02.Planning
management
life cycle
06.Deployment
03.Development
05.UAT 04.Testing
The release management cycle at ManageEngine.
Stage 1: Submission
The first step of the cycle is to identify a required functionality. Customer-facing teams like pre-
sales, support, and product management work together to provide the development team with
their input in the form of expected user interfaces and use cases. The submission stage is the
primer that allows us to set the expectations for the entire cycle. What are our customers looking
for? How will this product or feature enhance the user experience? Once we determine these, we
move forward to stating the objectives of the release, including:
⃣ Business requirements.
⃣ Priority.
⃣ Risks and timeline constraints.*
⃣ Release type, methodology, and policy.
⃣ Scope of release.
⃣ Cost (if any).
⃣ Supporting documents for release requirements.
Release requester
*Constraints for release deployment: Releases are
dependent on multiple factors such as:
• Service-level agreements (SLAs) or operational-

level agreements (OLAs).
• Resource availability.
• Budget.
Verified by
• Security issues.
release
• Corporate policies.
coordinator
Listing our dependencies allows us to identify
maintenance windows, during which releases can be
deployed and users can be informed about services
that may not be available. This doesn’t apply to
emergency releases, which can be released at any
time.
After the release requester submits the required

details, a release coordinator verifies the information
provided and assigns a release engineer. The release
engineer is now the owner of the release and they’ll
be in charge of the next stage. The owner provides an
outline of the release implementation by:
• Communicating with teams for the release plan.

• Identifying the development team and the quality
assurance (QA) team. Release engineer
• Identifying other users for various roles in the

release, if any.
• Assigning due dates for the standardized release
process
Role Responsibilities
Release • Defines the release objectives

requester • Documents business requirements
• Sets metric targets
• Handles communication about the release scope to release
team leadership staff or the release coordinator
• Handles communication to key customer stakeholders
(optional; this can be delegated to the release coordinator)
Release • Submits the release implementation details and schedules

engineer • Oversees deployment of the release into the production
environment
• Carries out proper training, if required
Release • Verifies the planning

manager • Ensures user acceptance tests have been carried out
• Verifies that training has been provided to the affected user
community, if required
• Validates the back-out plan
• Stages the pilot tests
Development • Plans the release activity and forwards to testing

head • After confirmation from the release manager, builds the release
activity with the help of tasks
• Documents the release activity (timeline, risk, etc.)
Testing or • Creates the test plan

QA head • Identifies issues
• Approves the test stage after completion
• Notifies the release engineer if the build can be processed to
deployment
UAT owner • Tests the functionality of a new release

• Liaises with the development team to decide on test criteria
• Performs tests and reports back with issues in the release
• Approves the UAT stage after completion
RACI matrix:
A responsibility assignment matrix can also be used to map out each member’s task in the
entire release management process.
R – Responsible, A – Accountable, C – Consulted, I – Informed
Development
Engineer Manager Coordinator Reviewer Testing team
head
Submission R AR I
Planning R AR AR
Development I I C
Testing I I C R
Deployment R A C C
Training/ support AR
Reviewer AR
Close AR I
Stage 2: Planning
The planning stage is handled by the release engineer. Tasks are distributed for different
participants of the release. For example, the QA team members are mapped to the release to test
out each build. If you have tasks that often repeat, add them as templates under each stage so you
can choose them quickly instead of entering the same details each time.
The planning stage requires:
1. Scope: Effects upon:
• Client-side business areas.

• IT services.
• IT infrastructure components.
2. A planned implementation date and time period, itemized according to:
• Development phase.
• Test phase.
• Rollout.
• Where necessary, reference to more detailed implementation plans.
3. Downtime details:
These consist of different downtime or maintenance windows required for completing the release
activity. The downtime is configured here and reviewed later in the review stage.
4. Back-out plan:
What happens if the release backfires? We need a plan B that tells us how to undo the release or
how the effects can be mitigated. A configuration baseline is a record of the last working state of
the service. If the release fails, we can go back to that checkpoint to ensure it doesn’t impact users
negatively. The configuration baseline can be defined in the release policy.
The release manager verifies the planning, validates the back-out plan, and approves moving on to
the next stage: development.
Stage 3: Development
The development stage is handled by the development
team lead. ManageEngine follows a software
development life cycle process, which dictates
how software is designed, developed, tested, and
implemented to satisfy the needs of end users.
A standard template for development consists of

sections like:
Release engineer
1. Details:
• Schedule period (start and end times)
• Actual time taken (start and end times)
• Description
• Attachments
2. Tools used. Monitored by

release
3. Tasks: manager
Work is usually distributed across teams or team
members, which are listed here.
4. Approvals:
Any approvals configured for this stage in the
workflow are displayed here.
5. Status comments.
You might be wondering why release management

has scheduled start and end dates and actual start end
dates. A release, or any project for that matter, relies
on many variables or has risks that may not always
work out the way you’d expect. You might face delays
in procuring hardware, or the finance team could
delay approval. In such cases, scheduled or baseline Development head
dates and actual dates help your team understand if
you’re ahead, on time, or behind schedule.
*Tools
There are hundreds of tools available for software development. Here, we’ll list some of the tools
preferred by our developers and what they’re used for.
Tool Purpose
Ansible IT automation
Ant Build tool
Zoho Cliq Communication and collaboration
Docker Container management
GitHub Distributed version control management
Jenkins Open-source platform for CI
Mercurial Distributed source control management
Selenium Test automation
ServiceDesk Plus Help desk and release management
Once the build is completed, the developers will provide the release notes and build URL.
Stage 4: Testing
Once the development team lead confirms the development
stage is complete, the QA team starts working on testing the
release package based on the tasks assigned to them. This
stage is overseen by the QA team lead or testing lead. As the
name suggests, the QA team handles planning, validates all
testing-related tasks, and maintains standards.
There are three major types of tests:
(a) Functional testing:

Development head
This determines whether the code satisfies the desired
functional requirements. Regression testing is also a form of
functional testing. It verifies that the code doesn’t unsettle
existing functionalities.
(b) Integration testing:

This tests if the code works well with integrations.
(c) Performance testing:

This monitors performance indicators. Load testing is a
form of performance testing. We add load to the system and
look for errors or breaks.
After these checks are performed, the team may perform

product-specific checks or secondary tests to ensure
satisfaction of business requirements and suitability for
deployment.
For this stage, we require the following:
1. A test plan:
This demonstrates how the testing has to be carried out.
QA head
2. Testing tasks:
Using tasks, the testing lead distributes work across their

team.
3. An issue tracker:
A document with issues recorded by the testing crew.
4. QA stage schedule start and end times:

These can be used by the testing lead to schedule tasks properly.
5. QA stage actual start and end times:

These can be used by the testing lead to record the actual time taken to complete the testing stage.
6. Approvals:
Before allocating the work, the testing lead needs to confirm that the proper build or environment
is provided to the team with necessary access and requirements.
Apart from these, we also use features like:
1. Testing stage-specific statuses:

These allow the testing lead to keep track of the status of the work happening.
Default statuses used:

• Pending for acceptance
• Accepted
• In progress
• On hold
• Rejected
2. Status comments:
When the testing lead specifies a status, they can also provide comments mentioning the reason
why it’s chosen. This provides clarity and ensures everyone in the team is on the same page.
3. Notes:
On a timely basis, team members can use notes to interact and collaborate.
Stage 5:
User acceptance testing (UAT)
In this stage, the end user will be provided with a test

environment to validate that the release meets end users’
expectations as per the release plan. The UAT stage is
predominantly handled by the UAT owner(s). They’re
responsible for planning and validating UAT-related tasks.
Ideally, this should be someone with an in-depth understanding
of the process or software. They’ll also be provided with the
requirement documents accepted by the QA team.
After the development stage, we select members from the QA

team to act as the end users and carry out acceptance testing. QA head
The team member will raise issues, if any, in a bug tracking
product. These need to be fixed by the development team before
release. They also need to verify compliance parameters, which
are part of the development cycle. This stage usually takes a
couple of weeks.
For this stage, we require:
1. A UAT plan:
This demonstrates how the testing has to be carried out.
2. UAT tasks:
Using tasks, the UAT owner distributes work across the team.
3. An issue tracker:
A document containing issues recorded by the UAT crew.
4. UAT stage schedule start and end times:

These can be used by the UAT owner to schedule tasks properly.
5. UAT stage actual start and end times:

These can be used by the UAT owner to record the actual time
taken to complete the UAT stage.
UAT owner
6. Approvals:
Before allocating the work, the UAT owner needs to confirm that the proper build environment is
provided to the team with the access and requirements mentioned.
Apart from these, we also use:
1. UAT-specific statuses:
These allow the UAT owner to keep track of the current status of the work happening.
Default statuses used:

• Pending for acceptance
• Accepted
• In progress
• On hold
• Rejected
2. Status comments:
When the UAT owner specifies a status, they can also provide comments
mentioning the reason why it’s chosen. This provides clarity and ensures everyone in the team is
on the same page.
3. Notes:
On a timely basis, team members can use notes to interact and collaborate.
Stage 6: Deployment
Types of deployment
1. Big bang vs. phased deployment

Using a big bang approach simply means updates are released all at once for all end users, whereas
phased deployment involves a release of updates in parts or for different user groups.
There are pros and cons for both methods.
Factor Big bang deployment Phased deployment
Implementation cost Low High
Risk High Low
Implementation time Short Long
Productivity Low (at first) High
ROI realization Fast Delayed
There’s no definitive answer on which deployment method works better. You should evaluate them
based on specific conditions such as budget, productivity, risks, and timeline.
2. Push vs. pull deployment

Push deployment:
An update is pushed from a central location to users simultaneously.
Pull deployment:
Updates are made available for users to download at their convenience or when a user workstation
restarts, e.g., mobile app updates.
Push Pull
Enforces uniformity Lacks uniformity
Requires accurate configuration data Doesn’t rely on accurate configuration data
Harder to scale up Not complex to scale up
Like the rollout strategy, there’s no right or wrong. Both push and pull models work, depending on
your bandwidth.
3. Automated vs. manual deployment
If your organization has fast release cycles, automated

deployment is a far better choice than manual deployment.
Benefits of automated deployment:

• Ensures repeatability and consistency
• Less prone to errors
• Takes significantly less time
• Supports larger target environments
• Increases productivity and efficiency
UAT owner
Manual deployment is preferred only in certain cases, like
rare releases and releases with limited cycles.
Now, let’s talk about the deployment process. It’s time

to take our build from the test environment to the live
environment. The deployment stage is handled by the
release engineer and overseen by the release manager.
The release owner must document:
⃣ Downtime for configuration items involved.

⃣ Schedule start and end times.
⃣ Actual start and end times.
⃣ Tasks.
After deployment, the release engineer confirms
completion of the stage.
Release engineer
Stage 7:
Training or early life
support (ELS)
ITIL® defines ELS as “a stage in the

service life cycle that occurs at the end of
deployment and before the service is fully
accepted into operation. During early life
support, the service provider reviews key
performance indicators, service levels, and
monitoring thresholds and may implement
improvements to ensure that service targets
can be met. The service provider may also Development QA
provide additional resources for incident and
problem management during this time.”
Customer satisfaction is key, right? The

objective of this stage is to keep all customer-
facing teams updated on new functionalities, Monitored by
assess overall performance, and quickly release
resolve any operational issues that pop up engineer
during the initial phase after deployment.
ELS promotes increased user satisfaction and
a reduction in number of reported incidents.
Requirements that must be

documented in advance include:
1. Resources allocated.
2. Time period.
3. SLAs and OLAs.
4. KPIs.
5. Exit criteria.
The development and QA teams are

responsible for training support staff who in
turn assist end users. The release engineer
ensures training and ELS are provided to
affected users relating to the release for the Support
time period as per the SLA.
Stage 8: Review and close
Review
The review stage helps determine whether the release
was successful or not. At this point, we should be
able to answer the following questions:
⃣ Does the release carry out its required function?

⃣ Are all the relevant teams aware of these changes?
⃣ Can this build template be replicated easily?
⃣ Can it be rolled back?
⃣ Is more training required for users? Reviewer
⃣ Is it user-friendly?
⃣ Have all configuration items and processes been
updated in the CMDB?
⃣ Have all the post-launch issues been resolved? Verified by

release
⃣ Is the documentation process complete? manager
The review stage is owned by the reviewer, who

is usually a member of the development or QA
team and who may not have been involved in the
build process. The release reviewer and a team
assess The release reviewer and a team assess
the release, including the entire release process’
efficiency, cost, and time effectiveness, impact,
intended and incidental outcomes, and more. The
processes involved in each stage of the release will
be thoroughly inspected. The review team also
determines whether the release met the specified
business requirements while causing little or no
disruption to the production environment. If it
meets the business requirements, SLA targets, and
end users have stopped reporting incidents, they can
verify the deployment and provide review comments.
Release engineer
Next review schedule: Metrics that matter

If the reviewer wants to re-verify the
KPIs put a quantitative value on how effective
deployment due to changes that may
your release management process is and identify
have occurred, they can choose another
areas of improvement. These metrics usually
date for it. In that case, the review stage
cover every stage and are best understood when
will be moved back to “In progress.” If
visualized graphically. We add release metrics to
there are any other minor issues that
our advanced analytics tool to keep track of our
don’t pose a threat or affect users, these
progress.
must be documented and addressed in

the next release.
Examples of KPIs for individual releases:
Close • Estimated release downtime in minutes or
hours
The life cycle of any release, be it • Total release downtime in minutes or hours
completed or canceled, ends with the • Deployment duration
closure stage. In this stage, the release • Number of incidents
manager associates a closure code for the • Mean time to repair
release and provides their comments, if • Difference in estimated and actual delivery date
any. The closure code provides details • Number of defects
on whether the release is closed due to
cancellation, rejection, completion, or Examples of KPIs for the overall release
other reasons, which makes it easier for management process:
stakeholders to understand too. Based on
the comments, the release engineer can • Number of releases
finally close the release. Resources taken • Release duration in days
up by this release can now be allocated to • Number of release back-outs
other tasks, i.e, your next release! • Number of releases by priority
• Number of releases by risk
• Average cost per release
• Average release cycle time
Chapter 4
Case study: How we rolled out

Analytics Plus 5060 smoothly
Analytics Plus is our on-premises advanced IT software.

It’s mainly used by businesses for augmented analytics,
predictive analysis, and other comprehensive reports.
In this chapter, we’ll follow a step-by-step review of the
Analytics Plus team’s release management process, find
out how it varies from cloud solutions, and see how they
successfully roll out monthly build updates.
The workflow is customizable and can be modified using the drag-and-drop canvas.
Stage 1: Submission
Person(s) involved:
Release requester > Release engineer (Shankar)
Start procedure:
The release requester submits required details to Shankar.
• Release level and identification

We follow a numeric increment for each build.
Major releases: Increments of thousands, e.g., 4000, 5000
Minor releases: Increments of 10, e.g., 4510, 4520
For this minor release, as per the naming convention,
we called it 5060.
• Release methodology: CI/CD
• Expected frequency of releases: Monthly Ideally, we’d like

to target one release every two to three weeks, but once
a month is a comfortable pace that allows us to address
pending issues and additional features users need.

• Roles
Role Team member

Release engineer or owner Shankar
Release manager Selva
Development head Masanamoorthy
Testing or QA head Bhagidaran
UAT owner Varies with each task
ELS head Anand
Reviewer Selva
CAB Not required for this release

• Business requirements
1. Instagram integration
2. Zoho Creator Cloud integration
3. Apply filter feature
End procedure:
Shankar is now the owner of the release.
Stage 2: Planning
Person(s) involved:
Release owner (Shankar) and release manager (Selva)
Start procedure:
Shankar submits a detailed implementation plan to Selva.
• Scope
• Scheduled start and end dates
Scheduled start date: Nov. 18, 2021
Scheduled end date: Dec. 1, 2021
End procedure:
Selva verifies the implementation plan and approves moving to
the next stage.
Stage 3: Development
Person(s) involved:
Development head (Masanamoorthy)
Procedure:
Masanamoorthy assigns tasks to his team members and

documents release activity.
1. Details:
• Schedule start and end times
• Actual start and end times
• Description
• Attachments
2. Tools used
3. Approvals
4. Tasks
Task Task owner
Template addition Daniel
Support document creation Cherubina
Test in ppm setup Pradhap
Test case creation Dheeraj
Enable feature via flag Pradhap
Behavior assessment Masanamoorthy
End procedure:
Masanamoorthy verifies completion of the stage and informs the QA team
Stage 4: Testing
Person(s) involved:
QA head (Bhagidharan)
Start procedure:
The QA team conducts various tests on each task to assess
performance.
Release type Time taken (estimated)
Minor 1-2 weeks
Major 5-6 weeks
Emergency 2-3 days
End procedure:
The QA team informs Bhagidharan once the code has passed
all the tests. He verifies that and then approves moving on to
the next stage.
Stage 5: UAT
Person(s) involved:
UAT owners
Procedure:
1. The UAT owners test out each code and report bugs.
They reported nine bugs for this release.
2. The report is sent back to the development team

for rectification.
3. The code is tested once again by the UAT owners.

4. Compliance parameters are verified.
5. The UAT owners approve the code and move on to the
next stage.
Stage 6: Implementation
Person(s) involved:
Release engineer (Shankar)
For on-premises products, we don’t require a deployment

process. While the other stages remain the same, the
implementation stage varies here.
Start procedure:
Shankar contacts the internal service delivery team, and they

use their upload tool to upload the build. Before rollout, we run
the code through the internal compliance tools to avoid any
last-minute surprises. The tools automatically block the build
from being uploaded if they detect any security issues.
If we suspect that a specific release may not work the way

it should, we introduce a turn-off switch and configuration
parameters along with it. So, if the functionality behavior is not
as intended and starts to affect customers’ day-to-day tasks, we
either turn off the feature or make immediate changes to ensure
it doesn’t continue to affect customers.
We also avoid major releases during long weekends or holidays.

Analytics Plus has a relatively small team; if customers face
any issues during an upgrade, we won’t have the bandwidth for
support.
End procedure:
For major releases, we would need CAB approval at this stage.
Since this is a minor release, we can skip that part and move on
to the next stage
Stage 7: ELS
Person(s) involved:
Development head (Masanamoorthy) and QA head
(Bhagidaran) > ELS head (Anand)
Start procedure:
The development and QA teams will provide sufficient training to Anand’s team members, and
they’ll provide use cases that will help them solve expected user issues.
If we need to update users about anything release-related, we send announcements or notifications

from release requests to users.
End procedure:
When Anand feels his team is fully equipped to handle any user scenario, he approves moving on
to the final stage
Stage 8: Review and close
Person(s) involved:
Reviewer (Selva) and release engineer (Shankar)
Procedure:
1. Selva reviews the entire process from start to finish

to determine if the release has met its goals.
2. Users report some bugs via email, which are promptly fixed.
3. He confirms that the release meets compliance requirements.
4. Selva verifies deployment and associates a closure code.

5. He passes it on to Shankar along with comments for
stake holders.
6. Shankar verifies once again that all necessary details

have been updated in the CMDB and finally closes the release.
Metrics:
When we say Zoho runs on Zoho, we mean it. The metrics are monitored in the analytics tool, which
is integrated with our help desk and its release management module
Shankar’s team will closely monitor these metrics and compare trends over multiple releases. Based
on these numbers, they can figure out which areas need optimization.
With this, we have successfully rolled out build update 5060 for Analytics Plus. Now, onto the next!
Chapter 5
Conclusion
Common release management

challenges and best practices to deal
with them
1. Poor build quality and release speed
Many organizations continue to put out substandard releases just to keep up with their schedule
and beat competitors. Aren’t they just setting themselves up for failure? There are plenty of ways to
improve quality and quantity.
• Best practice: Invest in the right tool

Pick a release management tool that allows you to monitor each stage of the cycle efficiently; not
just the stage but each action taken and by whom. Putting everything in a single, user-friendly
interface means you don’t have to spend hours combing through documents searching for answers.
You can also integrate it with other tools to increase productivity.
• Best practice: Automate

Manual releases take up time and resources and are prone to human errors. In a fast-paced release
cycle, manual testing and deployment do not help. It also means you’d have to spend more time in
the QA stage to clean up the mess.
If you haven’t already automated repetitive tasks, you’re wasting resources. Use CI/CD tools to get
building, testing, and deployment (if applicable) done quickly with accuracy. Automation frees
up your team from day-to-day tasks and allows them to focus on demanding, resource-heavy
operations.
• Best practice: Break it down

A great way to speed up your release cycle
is by splitting up your work into smaller
tasks and releasing them in stages, like DB
design first, followed by config APIs, then
feature APIs, etc. In all your stages, make sure
complete automation scripts are also a part of
them.
2. Lack of visibility
A common complaint from teams is that members are often not on the same page. For instance,
a member of the development team may not be aware that the review process is complete, or
a CAB member may not have been intimated about certain approvals. Not having detailed
documentation can be a real obstacle to effective release management.
• Best practice: Start from day 0

Release management shouldn’t be an afterthought. Start at the beginning and think long-term. An
effective release management strategy helps you establish and maintain consistency.
• Best practice: Document everything

Use proper documentation that has complete information from build tools to workflows. This
should be available for all team members to view at any given time, regardless of which stage the
release is in. A regularly updated repository with a back-out plan is a life saver.
• Best practice: Encourage transparency, and engage stakeholders

Put out a tentative release schedule ahead of time. Our product teams also use a channel
specifically to communicate information regarding releases, which has proved to be highly
beneficial while working remotely. Of course, the channel is only an additional support tool. Your
main focus should be the release management tool that monitors the stages in real time.
3. Uncontrolled variables in the live environment

When you’re writing a code, you can’t factor in every variable (known or unknown) because
they change with each environment. So if you skip staging and implement changes directly in
production, you’re just left with a bug platter.
• Best practice: Keep it real

Your staging environment should replicate (or at least be close to) the live environment. This way,
you can cruise through the acceptance stage and have minimal user impact upon deployment.
And don’t make changes directly in the production environment—run it through the staging
environment first to fix bugs.
4. Unsuccessful releases
Releases may fail, even if you think you’ve done everything right. There may be bugs, you may
have overlooked a test, or there may be miscommunication between team members. Good thing
you’ve got a back-out plan, right? So you implement your back-out plan and everything goes back
to the way it was. Now what? Now it’s time for analysis. What went wrong? How can we rectify the
situation?
• Best practice: Define success

Establish KPIs and continue monitoring them before, during, and after every release. KPIs allow
you to quantify success and identify weak areas that need improvement.
• Best practice: Save the date

Avoid weekends and public holidays to push out releases. The support period after a release is an
all hands on deck situation, and the last thing you need is three or four inexperienced members
dealing with unhappy users.
• Best practice: Training day(s)

Speaking of inexperienced members, why do you have them in the first place? Don’t rely on one
person who actually knows how to deploy or solve a problem. Can you imagine the chaos if they’re
not around? Provide sufficient training for everyone on the team and take turns performing each
role to familiarize them with the entire process.
• Best practice: Focus on your users

Releases aren’t about what you want, they’re about what end users need. Consult with the people
who actually use your services and take their feedback seriously.
Final words
Release management was formally introduced as a module in our help desk software in 2019. At
the time of creation, we set out with six goals:
1. Lower the risk in deploying the deliverables

2. Successful deployment
3. Better collaboration between teams and users
4. Proper visibility for stakeholders
5. Continual service improvement
6. Increase integrity in the live environment
We’ve definitely had the opportunity to realize these goals and reduce our downtime
simultaneously. There’s been a decrease in ad hoc requests for new software, and we spend less time
resolving incidents caused by poorly installed hardware and software.
Release and deployment management is a domain with plenty of room for growth. Down the road,
in additional features and more integrations (Jira, Zoho Projects) that will further streamline our
releases.
The bottom line:

Our teams love how easy it is to implement,
our customers love the quality and rate of
deliverables, and their increased engagement
with our products is a testament to the hard
work put in by the teams. If you haven’t
invested in a dedicated release and deployment
management tool, now’s your chance. Take ours
for a spin and let us know what you think!
Until next time.

It Release Management e Book

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

It Release Management e Book

Uploaded by

Copyright:

Available Formats

IT RELEASE MANAGEMENT

Featuring ManageEngine’s release and deployment

ACRONYM STANDS FOR

CAB Change advisory board

CMDB Configuration management database

ELS Early life support

KPI Key performance indicators

UAT User acceptance testing

Release and deployment management is the process

So how do you do it?

Is this e-book for you?

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

• Workflows and standard operating procedures.

Let’s get started!

Change vs. release vs. project

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

Are change management and release management the same?

Change management Release management

The process of controlling The process of planning, scheduling,

Pre- and post-deployment Deployment activities

Are project management and release management the same?

Project management Release management

The process of planning and The process of planning, scheduling,

Data collected is usually Data collected is required for the life

The magic triangle:

We've talked about release and change management.

A configuration management database (CMDB) is a centralized repository

Development Controlled test environment Live environment

Configuration management database[CMDB]

Release Release Development Quality assurance UAT Release Support Release

Everything related to a release has to be documented and up to date

• You’ll refer back to it for each release.

At Zoho, we use our own repository to ensure the contents of each

There are many reasons why we chose to self-host. First, using a

Finally, the connection between change, release, and configuration

Pre-sales and sales

A retrospective of the old release management process:

When the schedule is made public and updated religiously, it

Upon further assessment, we realized this may be because

A look at release management

The traditional approach:

The problem with the waterfall method is that the

Detailed High risk

Easy to use Difficult to accommodate changes

The agile approach

SPRINT’S SPRINT’S SPRINT’S

Agile methodology is commonly preferred over waterfall because it:

• Incorporates changes even late in the development stage.

combines development and IT operations.

It doesn’t have to be agile vs. DevOps. Combining

aspects of the agile approach, such as incremental

Staging environment Production

Plan Build Test UAT Release

Plan Build Test UAT Release

• Fixes bugs quickly

Release policy and methodology

What a release policy includes:

1. Release level and identification

Level Definition Identification example

A release to introduce a new

A release to makes changes to Adding a new feature

A temporary release required to

2. Expected frequency of releases