Chris Drake

Simplifying Project and Support Track Synchronization

Chris Drake | August 27, 2016

The Release Management Workbench allows for an organization to group together many changes, synchronize the transports from the changes to a release, and deploy in mass using minimal approvals.

The introduction of the Release Management Workbench has created so many new possibilities for managing changes, and for managing parallel project tracks. A theme which seems to be coming up quite a lot is around the process of synchronizing changes from a parallel project track into the support track after production go-live, often termed ‘backflushing’.

The two main considerations for ‘backflushing’ project changes into the support track are as follows:

  1. Sequential system, process driven vs Shared target, migration job driven
  2. Change approval queuing vs Release approval queuing

When combining these considerations there are four possible ‘backflush’ settings:

  1. Sequential system, process driven & Change approval queuing

This method requires an individual change request to be configured with a strategy, which will account for the migration to each project track system, as well as every support track system and production.

This method can allow for migrations to the support track systems to occur before or after production go-live, providing an option for further testing before go-live.

It is worth considering that the management of changes to each track system will require extra care with sequencing and tighter control from the Release Manager to ensure that all changes within the project are included.

This method can be useful to provide a higher regulation around migration, but a more relaxed approach to managing releases.

  1. Sequential system, process driven & Release approval queuing

This method requires the release to manage migrations to each support track system, either before or after production go-live.

It is suggested that, if testing is occurring in the support track systems before production go-live, the change requests are configured to handle the test success/failure, while the release is configured to manage the mass migration of all of the subordinate changes.

This method provides a higher level of regulation around migration, while incorporating a tight and controlled approach to managing releases.

  1. Shared target, migration job driven & Change approval queuing

This method requires a single change request driven approvals to production, which also queues the transports to all support track systems.

Once the transports are queued, an appropriately authorized Rev-Trac migration administrator can trigger migrations to occur, either starting with the production system or applying the transports to the support track systems first.

This method gives the migration administrator control over when the transports are imported into each system, however does not provide a controlled approach to managing the release. As such it is up to the migration administrator to utilize sequence checking utilities and change status reports to ensure that the queue is appropriately populated before triggering the migration jobs.

  1. Shared target, migration job driven & Release approval queuing

In my opinion, this is the easiest method to manage and provides the most efficient method to go-live.

This method requires only a single approval to production at the release level. All underlying support changes will be gathered, and the transports will be appropriately sequenced and queued to all support track systems as well as production.

The organization can trigger the migrations to the support track systems and production in any sequence, but with assurance that all changes within the release have been accounted for.

This method assumes that no testing is required for the project release in the support track systems, and all “work in progress” support changes can be overwritten in the development systems.

NOTE: Outside of the advice given in this article, organizations should consider sequencing, transport reapplication and appropriate testing to occur before these methods can be used.

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