ALM Coffee Party V – Dual Landscape Part 3

Two landscapes for one productive system

As recommended by the FB methodology, the project-driven changes unfold along a 4-system project landscape that includes an additional pre-production system.

image-2 › blue.works — Figure 1 Two system landscape cutover scenario 1

There are various scenarios for the cutover (go-live) of a release from the project landscape to the shared production system, see the list in the FB Configuration Guide, chapter “Cutover Checks and Post Cutover Activities: Configuration – Overview”.

We opt for “Scenario 1”, as it is called in the FB Configuration Guide, because it fits better with our proposal for the coexistence of major and minor releases.

Projects

One of the major advantages of the turnkey solution Focused Build is the fixed structure of the projects with their phases and the predefined quality gates. FB follows the agile project paradigm and organizes the work in the decisive implementation phase in waves and sprints. If you prefer waterfall projects, simply create only one wave and one sprint per project.

image-3 › blue.works — Figure 2 Example of a quarterly project

Pre-Production System

The pre-production system is not a second QA system. Its advantage is obvious: the integration and regression tests that take place there are not invalidated by constant new imports. This is because every change forces the tests to be repeated: a new side effect could have crept in as a result of the change.

In the test phase on the pre-production system, only corrections to errors discovered during testing are permitted. Focused Build offers the specialized “Defect Correction” process type for this purpose.

Development can continue during the freeze of the pre-production system, but it is done for the next release or the next phase cycle.

In the pre-production system, everything and only that which will actually go live in the next go-live is tested extensively and intensively.

image-4 › blue.works — Figure 3 Testing in a 4 system landscape

Maintenance

As the FB methodology expects a project plan with many Q-gates, I recommend using the classic ChaRM change documents for transports within the maintenance landscape. As long as only corrections and minor adjustments are made to existing processes, three systems should be sufficient in the maintenance landscape.

With active FB, the use of Request for Changes or IT Requirements is unfortunately not supported in the standard for minor release cycles (FB SP10). If you need the RfC for an approval workflow in the maintenance landscape, you must create “normal” phase cycles instead of minor release cycles¹.

From the lab

The dual system landscape with major and minor releases is outlined here on a Solution Manager sandbox system.

For the sake of brevity, I assume that you are familiar with the SAP documentation for the tools used and the FB-specific IMG.

The two system landscapes

Maintenance landscape

image-5 › blue.works — Figure 4 Maintenance landscape with the project development system as the retrofit target

Project landscape

image-6 › blue.works — Figure 5 Project landscape

image-7 › blue.works — Figure 6 Logical component group BL SOLMAN LCG with development and maintenance branches

Change Control Landscape

We give our demo its own Change Control Landscape (CCL), because release management is based on this. A CCL can only have one release.

image-8 › blue.works — Figure 7 Change Control Landscape

Since we want to operate the project landscape with FB, we have to configure the new CCL in Customizing (see below), and when starting the CRM WebUI we have to select the business role “/SALM/RLSMNG – Release Manager”.

image-9 › blue.works — Figure 8 Release Management Configuration Task Type

image-10 › blue.works — Figure 9 and the mapping

Major Releases

We go into release planning and plan a whole year in advance. It is more convenient to create only the major releases first, and the minor releases for the major releases afterwards.

As the minor releases are only possible after the go-live of the previous major release (there is no release 0), we simply set the initial release to the next best date in our demo. If you are already using standard ChaRM, you can dispense with this small start-up aid by operating the maintenance landscape with ChaRM as before until the go-live of Release 1.0 (sounds ChaRMant, doesn’t it?).

The big Project Go-Lives are usually held at the weekend.

image-11 › blue.works — Figure 10 Creation of quarterly releases for one year

image-12 › blue.works — Figure 11 Initial planning manual adjustment of go live dates at the beginning of the quarter

We are now adding a release cycle.

image-13 › blue.works — Figure 12 Release 10 with cycle

The very first time, the task plan for the project landscape is created. All further cycles will share this task list.

image-14 › blue.works — Figure 13 The new project task list

Minor Releases

Now we mark the release 1.0 and add 14-day minor releases for the maintenance landscape. We choose Thursday for the go-live day. This means that you still have Friday available for any necessary corrections in the event of go-live problems.

Figure 14 A package of minor releases

We adjust the dates manually. Release 1.6 unfortunately has to be added in a second step, as the application is simply too intelligent when calculating the dates and refuses to create 6 minor releases in one go in one quarter.

image-16 › blue.works — Figure 15 Six 14 day minor releases

And this is the task plan for the maintenance landscape:

image-17 › blue.works — Figure 16 Maintenance task list

Customizing phase model

In order to be able to create Request for Change for the minor releases of the maintenance landscape when the FB is active, the following entries must be added via the view cluster /TMWFLOW/VC_PHMD:

image-19 › blue.works — Figure 17 Customizing phase model

If you don’t want to miss the next part, you can read it here.

↩︎

Riccardo Escher

Riccardo is a Senior ALM Consultant and has in-depth knowledge of all areas of Solution Manager and ABAP development. He has extensive experience in the areas of ChaRM and the Solution Manager Test Suite.