During recent months, I’ve worked with several customers to implement Release Management strategies alongside a cloning strategy to reapply/retrofit changes to parallel tracks. The introduction of the Release Management Workbench within Rev-Trac has created so many new possibilities for managing changes and parallel project tracks. A common theme that seems to be coming up quite a lot, is around the process of getting changes from a parallel project track into the support track after Production go-live.
Rev-Trac 7 has introduced the Release Management Workbench, which allows organizations to bundle change tickets and manage many changes as a single release. This feature has been well received amongst RSC’s customers, however there are now advanced scenarios for consideration when utilizing this highly efficient approach.
Rev-Trac change control automation software just keeps on getting better – here is one more feature you can enable to make your migrations flow without stopping. The standard Rev-Trac migration job can be configured to stop on a return code value or proceed through all transports regardless of the return code. But what if you want to stop processing the migration queue only for UNEXPECTED return code values?
We’ve created a Rev-Trac report that allows customers to retrieve the details of a Rev-Trac Change Request that have had their approval status rejected.
The dust is starting to settle since the release of Rev-Trac 7 late 2015. Many of our customers are adopting the new features and taking advantage of the new web UI. It is our goal to have all of our customers using Rev-Trac 7 Web UI and to have implemented Salt on their Rev-Trac controlled systems in time to receive the powerful third component of the Rev-Trac Application Lifecycle Management (ALM) suite due for release late 2016.
Did you know that using Rev-Trac automated release management techniques can reduce the volume of individual request approvals needed to migrate large volumes of transports? When companies are looking to accelerate the pace of IT change delivery this can be a significant step in the right direction.
This month we had an analyst ask us if a code freeze was still necessary during projects or upgrades when using Rev-Trac. This is quite topical and so I wanted to discuss the concept and the validity of a code freeze for an organization using Rev-Trac. A code freeze is a period where normal support changes are put on hold in a support track, typically in preparation for a project (such as an EHP upgrade) go-live.
Rev-Trac has long supported a release management strategy for the mass management of change requests. The initial version was a manipulation of request status dependencies to emulate the feel of a group of changes. Now with the release of Rev-Trac 7, RSC has completed the Release Management capabilities combining some powerful functionality to allow an organization to better control…
Just a quick tip this week, and it is specific to those running Rev-Trac on SPS09 or higher.
The Rev-Trac Executive Matrix report enable users to gain a snapshot of the state of play of request statuses by project, by developer, by request type and by range of other criteria.
Our newest Melbourne based customer has been implementing Rev-Trac for an environment which has a fixed 2 tier BAU (support) track and project track. In this particular case, there are different outsourced partners managing each environment and I am training the Basis staff from each environment on how to administer Rev-Trac.