ALM Coffee Party V – Dual Landscape Part 4

Practice

After so much theory, we now want to see how the dual landscape is put into practice.

Initially, the two teams (project and maintenance) work separately, each with its own cycle time. Thanks to the pre-import functionality of the work item (S1MJ) and the normal change (SMMJ), both teams can, if necessary, put a change into production before the planned go-live. This desire usually arises in the maintenance track. But these should remain exceptions.

With such exceptions, the Urgent Corrections (S1HF/SMHF) should be avoided in any case, because these are very dangerous, as they release the original transport as soon as the status changes to “ToBeTested”, so this time bomb must be set to productive as quickly as possible (see my blog, chapter “Hotfix”).

Projects

Focused Build: In addition to the very useful openSAP course mentioned in Part 1, SAP’s own ALM Media Center should be mentioned here.

The FB methodology briefly summarized:

• The project teams work in cycles through waves and sprints; development tools are Requirementsthat are used by the business for the respective processes and/or process steps in the Solution Documentation which the software architect can then convert into Work Packages (WP) per wave are taken over into the development and Work Items (WI) per sprint.
• Testing is carried out with easy-to-generate test plans and test packages.

Extensive checks ensure that the appropriate documentation is available for each status of the WPs and WIs.

A comprehensive dashboard accompanies the control of the whole system. What could possibly go wrong, I would like to add with a wink and having lost my job.

Maintenance

Meanwhile, the maintenance team responds to incidents with the necessary error corrections and implements any minor change requests from the specialist department, which are put into production with every minor release or cycle go-live, for example every two weeks.

The art of the fugue

But now you ask yourself at some point: Yes, but what happens if both teams, project and maintenance, change the same object at the same time? It is precisely this possible collision that is the crux of a dual landscape, which makes it complicated but exciting in its counterpoint.

Fortunately, SAP has taken precautions here. A crucial component for collision detection is the Cross System Object Lock (CSOL).

In a nutshell: CSOL is embedded in all(!) editors and maintenance transactions with a transport connection: For every change that is recorded in a transport, a lock entry is stored in the Solution Manager, which is only removed again with the final release or cycle go-live. I refer you to the beautiful blog by Dolores Correa.

And these CSOL entries are not only important for downgrade protection, they also control the most exciting functionality of such a complex landscape: the retrofit.

Retrofit

Retrofit basics

The task: An error correction is carried out in the maintenance environment and goes live with the next minor release. If the same object undergoes a change in the project landscape that will later go live with the next major release, this project change will overwrite the correction from maintenance if we do nothing: The error that has already been fixed will therefore reappear.

To prevent this regression, the error correction must be retrofitted from the maintenance landscape to the project landscape, i.e. both changes, the maintenance correction and the new feature in the project, must be merged for the project landscape. There is only one direction for the retrofit: from maintenance to project. There is also a very nice blog by Dolores about the retrofit.

Retrofit practice

As soon as a correction is saved to an object in the maintenance development system, which is also in the project landscape on its way to the production system, a dialog pops up showing the key of the object and the conflicting transport and its change document number (work item). The developer is now forewarned. She can still simply click away the warning.

The maintenance developers or customizers are responsible for retrofitting the correction transport into the project landscape.

The ideal time for the retrofit is when the normal change receives the status “TestedOK”, as the correction is then stable because it has been tested; the “real” transport is now released and imported into the maintenance QA system via a batch job. Of course, it is checked that no untested changes have crept in at a later date.

The transport is now in the import queue of the production system, the change itself is also waiting for the next maintenance go-live. Now maintenance and project need to talk to each other about how the two conflicting changes in the project landscape can be combined. The initiative for this must be taken by the maintenance team. No productive implementation of the correction without a prior retrofit in the project landscape!

The team members are technically supported by the ChaRM Retrofit tool, which categorizes the individual maintenance transports to be retrofitted and greatly facilitates the blending of the two landscapes. Unfortunately, the Retrofit tool is still an SAP Gui application (it flickers a bit when started from the CRM WebUI), but a very powerful one.

Transports to be retrofitted are categorized using a traffic light colour scheme.

“Green” transportation

These are transports or objects that do not experience any collision and are not on any exception list.

We recommend the FB Standalone Extension Retrofit Automation: Simply set up and enjoy. A batch report takes care of all conflict-free maintenance changes and distributes them to the project landscape. The quietest option is via Transport of Copies (ToC). A small note if you use the ToC scenario of the Focused Build Standalone Extension “Retrofit Automation”: Org transports that were created with the RHMOVE30 report are blocked against copies of ToCs and must be placed on the exception list.

“Yellow” transports

If a change in the maintenance landscape collides with a change in the project landscape, the object is marked as “yellow”. This means you have to mix the changes. However, this merging is supported here by the retrofit tools (SCWB, BC-Set).

The trick here is to select the appropriate target transport in the project landscape.

If the project transport containing the collision can still be changed, it is clearly the right choice

Otherwise, you must create a new transport in the project landscape and ensure that it goes live together with the project transport that has already been released.

Either you take the FB Work Item back into development or, if this is no longer possible, you create an FB Defect Correction for the same release. FB and the underlying TMS will ensure that everything goes live correctly and in the right order.

In all these cases, the retrofitting user needs a changeable transport task, otherwise the target transport will not appear in the transport selection of the retrofit tool.

“Red” transports

If an entry is marked as “red”, it can only be retrofitted “manually”. This means that the maintenance change is repeated in the project landscape with the appropriate maintenance transaction.

Two cases must be distinguished here.

The maintenance landscape entry collides with a change in the project landscape, but is not “yellow” but “red” because neither of the two tools supports merging, so it can only be entered manually: Thus, the same rules for selecting the appropriate target transport apply here as for the “yellow” entries, namely to pay attention to the common go-live.

If, on the other hand, the entry is “red” because it is on the exception list (implicitly, such as SAP notes, modifications, etc., or via customizing in the exception list), but there is no collision with a project change, then a normal work item must be used for this manual maintenance in the project landscape. This means that “red” changes go live a second time, but that’s the way it is. It is best to accept it, avoid manual intervention and not think about it any further, because: It works.

Retrofit strategy

Experience shows that the retrofit queue grows faster than you would like if you disregard this golden rule. As the retrofit tool calculates the dependency of the transports on each other, an old, non-retrofitted transport can very quickly block the retrofit of a whole batch of newer transports.

It is recommended to establish a retrofit team (or at least a retrofit master) that has the following characteristics: Responsibility, initiative, expert knowledge, governance, regular monitoring of the retrofit queue, coordination between maintenance and project.

This is because the retrofit queue must be empty when the project is cut over (go-live). Incidentally, the cutover checks from Focused Build check exactly this.

Communication is key! In practice, the retrofit team or the retrofit master, in consultation with the project management, establishes specialist retrofit jour fixes at which maintenance and the project discuss the collisions and summarize them in a project transport.

Rule for the subject-specific teams: One of mine and one of yours.