Chris Drake

Rev-Trac Release Management Workbench – Strategies for handling release go-live’s

Chris Drake | March 4, 2016

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 Changes within a Release or multiple Releases.

In the Support environment, it is normally obvious as to how 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, while 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-Lives
  2. Initiative Based Releases
  3. Hyper-Care Period after Production Go-Live

Wave Approach

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, 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 leveled 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 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 team at [email protected] to find out what the best approach to Release Management is for your organization.

Chris Drake

Chris first joined the company in 2007 on the front line in customer support. In the role, he gained a comprehensive knowledge of the concerns and priorities customers have from both a user and strategic decision-maker standpoints. Working in the field as an implementation consultant, Chris has a deep understanding of SAP and change management and the impact manual processes have on SAP systems stability.
See all articles by Chris Drake