Rev-Trac’s Release Management Workbench, Rev-Trac now allows organizations to group together many changes, synchronize the transports from the changes to a release, and deploy in mass using minimal approvals.
When an organization utilizes one or more parallel development tracks, they have to manage retrofits to ensure that transports put into production are added into each parallel track.
When using Rev-Trac to perform the retrofits, most customers configure Rev-Trac to clone the request once the request is approved for production.
This ensures that not only is the change captured for retrofitting, but the resulting clone requests can then be used to analyze the change to determine whether or not to perform the retrofit.
There are two options for triggering requests cloning when retrofits are required, each with different consequences and benefits
Triggering cloning at the change request level
For my part, the best set and forget method is to manage cloning and retrofitting at the change request level.
This is where each and every change request, and its associated transports, are cloned and considered for retrofitting on its merits.
As discussed in a previous article, clone requests should only ever be reapplied or rejected as a whole. An organization should never pick and choose at the transport level.
As such, cloning and retrofitting at the change request level allows further granularity for managing the retrofit process.
When used in conjunction with Rev-Trac locking, our customers find that over 90% of changes can be automatically retrofitted without conflict, meaning only up to 10% will require reworking in the parallel development system.
Further to this, any conflict reports will have a smaller number of object collisions, making the side by side analysis of the objects affected more manageable.
Triggering cloning at the release level
Triggering cloning to occur at the release level can be a valid approach, and is best used without the ability to reject the retrofit, but rather force the retrofit despite any potential conflicts.
This method is more useful in the early stages of the parallel track’s project build, as there may still be a lot of time to correct any conflicts in the parallel track.
The benefit is that consistency between the two tracks is guaranteed. However, this method becomes difficult to manage closer to the time of the parallel track’s project go-live, as conflicts will likely break the project’s functionality.
Some organizations have chosen to utilize the big bang approach of release level cloning for the first 50% – 80% of the parallel track’s project build and switch to the granular control of change request level cloning for the final stages of the build.
There are many methods for managing releases in Rev-Trac. Feel free to reach out to our experts to find out what the best approach to release management is for your organization.
