Rev-Trac Release Management Workbench – Strategies for successfully handling release go-lives

With the introduction of the Release Management Workbench, Rev-Trac 7 now allows for an organization to recognize and manage the statuses of the various SAP changes within a release or multiple releases.

In the support environment, it is normally obvious as to how SAP changes can be promoted or delayed. Most often it is due to the progression of the development.

Simply put, a change which is ready before anticipated might be expedited into production.

However, a change which is not ready for production in time for the scheduled support release window, might be delayed to a later window.

In a project environment, it is often more complicated, and business commitments as well as customer-facing deadlines need to be accounted for.

As such, it is typical for a Release Manager to reduce the risk of a project go-live by staging waves of functional release, which can each require downtime of production.

In a modern Dev-Ops environment, using an agile development and release methodology reduces the system downtime.

This allows for more frequent functional go-lives consisting of smaller pieces of functionality.

There are many ways that an organization can configure the Rev-Trac Release Management Workbench to handle project releases, here are some of the common trends amongst our customers:

  1. Wave approach to production go-llves
  2. Initiative based releases
  3. Hyper-care period after production go-live

Wave approach to release management

The wave approach allows for an organization to include multiple releases within a project build. Each wave will typically act as a prerequisite to the subsequent wave.

In some cases, SAP changes can be dragged and dropped between waves if there is no dependency.

This allows for different pieces of functionality to be built at different velocity, while allowing for testing to commence on the waves as they become ready.

Initiative Based Approach

In this approach, a multi-levelled release management hierarchy is used as follows:

Release > Initiative > Change

When an organization has several large chunks of functionality that are required for development, they can be put into initiatives.

An initiative is treated as a single mini project or a larger business requirement, consisting of multiple changes.

In this case, the SAP changes remain static within an initiative, however, each initiative can be moved amongst various releases based on their progression and the business requirement for go-live.

In some cases, a business can complete several initiatives and hold them from release to production until the business is ready for the functional enhancements to be received.

Hyper-Care after Go-Live

A hyper-care release can be setup exactly like a subsequent release, however will include:

  • Bug fixes found during the early days of a go-live
  • Minor Changes left out of the go-live due to delay of the TCO
  • Minor modifications if go-live functionality was not as expected

It is also possible to configure a hyper-care period, which allows changes to flow through to production in an expedited fashion to ensure that post go-live issues are managed without the red tape of a typical support change.

There are many methods for managing releases in Rev-Trac. Feel free to reach out to our in-house experts to find out what the best approach to release management is for your organization.