Large organizations with high volume of changes, often experience many challenges around managing transport sequencing. This can take a huge toll on an organization’s Basis team when managing transport sequencing to ensure that day-to-day support changes or large projects experience successful and safe production go-lives.
In this month’s article, I would like to briefly touch on how Rev-Trac manages each of these transport sequencing issues.
Object conflicts in transport sequencing
Object conflicts occur when users affect a common object in parallel. Rev-Trac’s 3-part object conflict detection prevents these issues as follows:
- Extended locking ensures that developers do not inadvertently perform changes to a common object without being notified and/or seek approval from a Change Manager
- OOPS overtake warns of any out of sequence migrations, such as migrating V2 to Production before V1 of the same object has been migrated
- OOPS overwrite warns of any downgrades, which may be caused by V1 being migrated into Production, overwriting V2
Change specific dependencies
Rev-Trac requests allow for developers to control the sequence of their transports within the scope of their own change. For example, the developer creates a program and migrates it to QA resulting in failure, as the Data Dictionary objects were not included. The developer then adds his Data Dictionary objects to a subsequent transport and re-sequences the transports on his Rev-Trac request to allow for the Data Dictionary transport to be migrated first, followed by the transport containing the program.
Cross change, business process dependencies
Two developers are working on different changes, however developer B’s change is dependent on developer A’s change. To prevent developer B from concluding his work and progressing his change before developer A’s change has arrived in the target system, Rev-Trac provides transport dependencies, which can be set across Rev-Trac requests, and will be honoured when a user attempts to migrate the changes. This will ensure that the pre-requisite change and related transports are migrated first.
Cross change, cross application dependencies
In some cases it is important that changes affecting the ECC environment arrive in their respective target environments before a corresponding BW change. For example, there are two main ways to handle this in Rev-Trac:
- By using source specific migration, a single Rev-Trac change ticket can manage transports and the transport target system migrations for both environments, which allows a single test script and a single migration approval for all transports. This method will ensure that the ECC changes are successfully migrated to their target system before the BW changes are migrated.
- A dependent Rev-Trac change can reference the pre-requisite Rev-Trac change to ensure that status checks occur against the dependent request. This can ensure that the operator of a BW change cannot approve the migration to production until the pre-requisite ECC change is in a status of “In Production”.
In a scenario where different developers are required to operate in their respective environments, separate Rev-Trac change requests can be used and option 2 above becomes the alternative method.
There are several other less common and more complicated transport sequencing scenarios that may be experienced.
However, in all cases Rev-Trac has been able to assist and ensure that an organization experiences successful and safe production go-lives.
For more information on transport sequencing, please contact us.
