1. IBM Software Thought Leadership White Paper
7 Proven Practices to Strengthen
Release Management

2. 2 7 Proven Practices to Strengthen Release Management
Contents
2 Abstract
2 Background
2 Solution
4 Benefits
4 Summary
4 About IBM UrbanCode Release
The effort it takes to get an application from development to
production can be a long and painful process, but it doesn’t have
to be. Proper release management practices can ease the pain in
deployment processes and get the applications deployed quickly
and successfully.
Abstract
This white paper will discuss key tips for improving a release
process and strengthening release management. Once the
following practices are in order, the process can be enabled to
keep up with the pace of Agile, and reduce the risks associated
with rapid deployments.
Key Findings
●● Releases are risky. Often homegrown scripts, manual steps,
and runbook orchestrations contribute to the risks involved
with application releases.
Recommendations
●● Having a controlled release process can strengthen release
management by ensuring quality, reducing manual tasks,
deploying applications consistently across environments,
and more.
Background
Customers’ constant demands for improvements are driving
industry changes. The increased pace of innovation has brought
about numerous advancements in technology and an accelerated
pace of change.
Development teams, making the changes to meet customers’
needs, realized that they could not keep up with the increased
demand. Many of those teams turned to Agile methodologies.
Agile methodologies would help developers create a steady
stream of features and solve customer’s problems as they arose.
Agile solutions allowed developers to make rapid changes.
However, organizations were unable to achieve the full benefit
of Agile. Legacy deployment processes delayed the release of the
applications because they were built for infrequent releases.
For that reason, they were a poor match for the increased pace
of change. Even when development teams executed Agile
practices perfectly, bottlenecks appeared elsewhere in the
delivery pipeline.
These frequent changes overloaded the operation teams who
were faced with deploying these applications. Changes could
not go to production comfortably because of the increased
possibility of outages. Therefore, the operations team would
delay the deployment and delay the application changes.
Manual tasks complicate the path to production. In order to
achieve the benefits of Agile practices, organizations and
operations teams must create a process that can keep up with
changes and comfortably deploy to production.
Solution
The solution to achieving the full benefits of Agile is to examine
the current processes and modify them so that frequent releases
become less painful to deploy. In addition, implementing release
management practices can provide focus on the entire release,
from build to production. The main objective of managing a
release or deployment process is to establish a reusable process
that can predictably deliver business value in terms of
applications, while protecting the critical systems in use.
Release management encompasses all the elements of a release—
both application and infrastructure.

3. 3IBM Software
The following are seven practices used to strengthen release
management:
1. Establish a single source of truth
Today’s development teams are positioned around the world,
each handling a different part of the application. These teams
have their own set of tools and processes for deploying the
applications. A global team, different processes, and different
tools can create a larger challenge when coordinating and
orchestrating the release.
When orchestrating a global application release, create a single
source of truth that will update in real time. Doing so will
coordinate all parties responsible for the release (stakeholders)
and provide visibility and traceability into who created what
and when.
2. Automate painful tasks
Manual steps in the deployment process create a number of
risks. For one, if the step is not documented correctly, or the
step is missed in future environments, it can cause a failed
deployment and production outages. In addition, manual steps
are difficult to track and manage.
To resolve the problem, automate as much of the process as
you can. Automation provides a secure and successful way to
complete steps crucial to the deployment of applications.
The ideal process will be completely automated.
3. Manage inter- and intra- application dependencies
Avoid relying on developer oral history to understand dependen-
cies. Complex deployments may contain components that are
dependent on one another. If Component A is dependent on a
specific version of Component B, not deploying that version of
Component B can cause a release failure.
Only promote components that were tested together and known
to be compatible. As the application moves through various
testing environments, it ensures that the exact versions (bit for
bit) are being deployed in every environment.
4. Make “what is where” visible
Not knowing what is on a machine, or in an environment, is
exceptionally risky. This is especially true as you deploy to
upper environments. An undocumented component existing
in an environment is not likely to be compatible with the
components in the upcoming release. In addition, tracking the
applications that were deployed to a downed machine is a
time-consuming, mission-critical task.
Making “what is where” visible ensures that application environ-
ments contain the desired component version. In addition, it
makes tracking what applications were on a downed machine a
quick process. Proper inventory into a release provides complete
visibility into different versions of your application.
5. Make certifications and approvals visible
Certifications and approvals ensure quality. It is important to
define quality attributes across the release lifecycle. Until
quality attributes are defined, an application with multiple bugs
and incompatibilities with other applications can be passed to
upper environments.
By making certifications and approvals visible, stakeholders
know what is required for an application to proceed into the
next environment of the lifecycle. Define a quality gate to
establish minimum entrance requirements to an environment.
A gate is a mechanism that ensures items cannot be deployed
into an environment unless they have a gate-specified status.
6. Deploy consistently across environments
Deploy applications consistently across environments. When a
process differs from build, test, and production environments,
the chances of errors increase; Because the production process
is not being practiced in earlier environments, steps that are
unique to the production environment might be incorrect.
Use your test environments to practice the deployment process
used in production.
When orchestrating an application releases, design a single
process that is used in every stage of the lifecycle. By providing
teams with a structured path to production, visibility and
authority is provided to all stakeholders.
­ ­

4. Caveats:
●● Often, an item in an upper environment doesn’t exist in a
lower environment; for example, a load balancer does not exist
in the “Dev Test” environment. During these occasions,
run load balancer steps conditionally.
●● If processes are completely different, consider a lower
environment process and an upper environment process.
Avoid having a process per environment.
To diminish the variance between environments, consider
building environments through automated provisioning
strategies. DevOps people call this “infrastructure as code.”
7. Make the release plan easy to consume
A release plan that can be edited on the fly during a planning
meeting, and easily understood, makes it obvious to everyone in
the room what the impact of the change is. A proposed change
should be previewed and approved without calling another
meeting, saving time and money.
A plan that is too hard to understand, on the other hand, will
largely be ignored. This will result in change management
theater, rather than actual assessments and management of risks.
Benefits
If these seven practices are followed accordingly, it could
provide an established and controlled release process enabling
business benefits on two levels. On the macro-level, the process
can have a standard path through all environments. On the
micro-level, each deployment can be from a known source,
to a known location, in a known way.
Summary
Pressures from the business are producing frequent,
incremental releases that increase the number of applications
needing to be released. Applications that were deployed
quarterly are now released monthly, weekly, or daily. This puts
tension on operations teams. Companies can ease the pains of
deployments by implementing release management practices
into their deployments.
About IBM UrbanCode Release
IBM UrbanCode Release transforms error-prone and chaotic
release planning into streamlined release events, replacing
spreadsheets with a collaborative solution that eliminates
breakdowns in communication enabling more frequent
releases at lower risk.
For more information
To learn more about IBM UrbanCode Release, please contact
your IBM representative or IBM Business Partner, or visit the
following website: ibm.com/software/products/us/en/ucrel
Additionally, IBM Global Financing can help you acquire
the software capabilities that your business needs in the most
cost-effective and strategic way possible. We’ll partner with
credit-qualified clients to customize a financing solution to
suit your business and development goals, enable effective
cash management, and improve your total cost of ownership.
Fund your critical IT investment and propel your business
forward with IBM Global Financing. For more information,
visit: ibm.com/financing
© Copyright IBM Corporation 2013
IBM Corporation
Software Group
Route 100
Somers, NY 10589
Produced in the United States of America
September 2013
IBM, the IBM logo, and ibm.com are trademarks of International Business
Machines Corp., registered in many jurisdictions worldwide. Other product
and service names might be trademarks of IBM or other companies.
A current list of IBM trademarks is available on the web at “Copyright
and trademark information” at ibm.com/legal/copytrade.shtml
IBM UrbanCode Release
This document is current as of the initial date of publication and may be
changed by IBM at any time. Not all offerings are available in every country
in which IBM operates.
THE INFORMATION IN THIS DOCUMENT IS PROVIDED
“AS IS” WITHOUT ANY WARRANTY, EXPRESS OR
IMPLIED, INCLUDING WITHOUT ANY WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND ANY WARRANTY OR CONDITION OF
NON-INFRINGEMENT. IBM products are warranted according to the
terms and conditions of the agreements under which they are provided.
RAW14329-USEN-00
­ ­
­ ­ ­ ­ ­
­
Please Recycle