Release Management Process

Release Management Process

Why do you need Release Management Process?

In business, every user makes a difference. A blotchy release with bugs and crashes could drive away potential customers and disappoint existing ones. Frequent downtime and conspicuous bugs could result in your revenue taking a hit.

Multiple delivery teams often work in parallel in an organization, which can sometimes lead to conflicting release schedules or dependencies. Establishing a release management process helps your organization streamline your releases and visualize the big picture across all the teams in your company.

What is Release Management?

Organizations improve the quality, speed, and efficiency of building or updating software by focusing on release management. This is the process of planning, scheduling, and managing a software build through the stages of developing, testing, deploying, and supporting the release.

Objectives:

  • Increase the number of successful Releases, including reducing the number of Releases with unexpected outcomes.

  • Decrease the number of incidents caused by Releases.

  • Create a single documented process for managing all Releases.

  • Maintain a single repository for recording all Releases through the lifecycle.

  • Ensure that the process is adopted, adhered to, and escalated to management if there are compliance issues.

  • Streamline the procedures so that there is an appropriate balance between the complexity of the Release and the required controls.

  • Harvest lessons learned from the Release Management process.

Release Management Policies:

  • All projects bundled changes to an existing service (releases containing multiple enhancements/fixes) and cyclical changes to an existing service must go through the Release Management process and must have a completed request for change (RFC) with appropriate approvals.

  • Whenever possible, changes to an existing service should be bundled together and released on a regular (ex: monthly) basis using the Release Management process.

  • A single “Release Team” must be identified for every Release. The Release Team will be responsible for successful coordination and execution of the Release, as well as ensuring all required documentation related to the Release exists.

  • Proof that controls (initiation, testing, and approval) have been followed for all auditable Releases shall be stored with the ability to be reproduced.

  • Each Release shall be initiated through a standardized and approved process (service request, incident management, problem management).

  • Each Release should be well tested and verified prior to implementation.

  • All implementation work on the Release should be completed by the Planned End Date/Time.

  • Validation that the Release has been completed successfully should be confirmed through post-release testing.

Release Management Process Components

Request for changes or New Features

Whether it’s a request for new features for a product or the requirement for a new product, the cycle begins with identifying the need for changes.

Release Planning

All the stakeholders assemble to decide which features get shipped in the next release. Besides the development team, Release Lead, representatives from Operations and Management should also ideally be included.

Software Build

The development team works on building the software based on user stories and acceptance criteria.

Review

The new software code is reviewed and cleared through quality and security checks. It goes through unit testing, integration testing, acceptance, and UI testing.

Deployment

Sometimes a feature is deployed incrementally (Pre-Production Servers)—first to internal users of the organization, then to a select user community, before finally making it available for everyone. These initial users help catch any bugs and errors, so they’ll be fixed before the release is deployed to the live environment.

Support

The cycle doesn’t end as soon as the feature goes live. Marketing and Customer Relations teams coordinate with developers to create awareness and support material about the new feature for end users.

Feedback Collection

Customers who reach out with questions or feedback are often the ones actively using your product. Engage with them to know how your end users perceive a feature and to understand where you can improve. Then, synthesize the collected feedback to create actionable work items for the next release.

Release Team supports releases for AX-Solution Center:

  • Asia Regional Core Support (AX 2012)

  • Europe Regional Core Support (AX 2012) [Germany, Italy]

  • Europe V5 (AX 2009) [WFJ ,Benelux/Scandinavia, Spain, Ukraine, Switzerland]

  • Brazil (AX 2012)

  • Canada (AX 2012)

  • CERPD (AX 2009)

  • Grace (AX 2012)

Release Management Metrics & KPIs

Once a release management process has matured, a release lead can turn their attention to performance metrics with the aim of improving the process. Let’s look at a few:

Release Downtime:

This is the first important metric. Any software release runs the risk of downtime, the length of which may range anywhere from a few minutes to a number of hours or even days. For example, is downtime that is necessary and built into the release schedule, and it’s a good idea to compare this with actual downtime, which is measured post-release. There’s also unplanned downtime, which over a few releases may be a sign of root problems going unfixed.

The Type and Priority of Releases: 

Each release is categorized as major, minor, or somewhere in between and is assigned a priority: high, medium, or low. Over a number of releases, look at a breakdown of your releases by type and priority. There should be a good mix of releases by both size and priority.

The Number of On-Time Releases: 

Since on-time release is not assured, it’s as much about release delays. There are quite a few interesting nuggets of information to be gleaned. For example, do some development teams have more late or on-time releases than others? Is there a pattern of late or on-time delivery based on release prioritization? What are the root causes of repeatedly late releases?

Share

NISHANT SL

‘’My self Nishant SL working as a Release Lead in AX Solution Center”, I have Total IT experience of 11 years and experience includes leading teams in a distributed object-oriented environment using technologies like Microsoft Dynamics AX 2012,2009, D365, .NET, X++, C#, .NET CORE, MVC, Salesforce and Release Management. A proven leader who is a dedicated, self-directed with strong communication & organizational skills

Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from Youtube
Vimeo
Consent to display content from Vimeo
Google Maps
Consent to display content from Google
Spotify
Consent to display content from Spotify
Sound Cloud
Consent to display content from Sound