A frequent exercise for many SAP organizations is to refresh SAP QA Systems from Production. This ensures that suitable and up-to-date data is available for testing. With testing becoming increasingly important the need to refresh QA Systems is also on the rise.
As an organization’s SAP DevOps processes mature, one would expect to find test failures being picked up earlier in the development process (‘shifting left’). Therefore tracking test failures and the reasons for the test failure is an important mechanism for management to be able to improve agility and speed of delivery. Recently while onsite with a customer, I was asked about a Rev-Trac reporting capacity for tracking rejections during the testing phase.
Just like servicing a car, or painting a house, Rev-Trac will require occasional upkeep to ensure ongoing brilliant performance. Due to the nature of fast moving businesses with requirements changing priority, experiencing delay or sometimes being cancelled altogether, the modern SAP shop leveraging Agile and CICD techniques will eventually find abandoned transports remaining in their non-production systems.
There’s a new feature in Rev-Trac 7 that provides for cross request synchronization primarily intended for release management. Updates to the Release Management Workbench focus specifically on release and change status synchronization and adds the capability of synchronizing any request type, including non-SAP requests. Automatic Request Status Synchronization will now establish (and document) non-SAP change status synchronizations with Rev-Trac change request strategies, including release and change status synchronization.
A few of our customers have asked us about the ability to put a change control process around Rev-Trac configuration modifications. It often a tricky subject to discuss, as there is an irony in the need to put Change Control around the Change Control tool. As Rev-Trac is written in ABAP and runs as a transaction in SAP, it is possible for organizations to benefit from the use of multiple Rev-Trac instances; at least a Development and a Production environment.
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 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?
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.
As a follow-up to my May 27 blog on the topic of dynamically adding an approver to a Rev-Trac change request – I thought I’d cover the ability to pre-select approvers, which can really help prevent confusion.