ALM Coffee Party V – Dual Landscape Part 2

Release Management

The basic idea of release management is that all projects share common test and go-live phases.

Initially, the change or release manager has to stand up to project egotism (“Our go-live date is sacred”): Not an easy task, as projects are full of budget and strategic importance, and therefore very powerful.

But the change or release manager has very good arguments on his side.

After all, isn’t the productive system even more strategic than the most important project?

Yes, it is even vital for the company or the authority. Due to the peculiarity of ABAP instances to abort running programs with a short dump if the executable unit (load phase) has changed at runtime, every go-live means stress for the productive system. This often requires downtime. A joint go-live of the projects will therefore minimize the risk of abortions and the costs of downtime.

Joint integration and regression tests increase the quality of the release, as hidden side effects can be discovered in the process, since all changes will come together in the production system anyway. The testing effort is also minimized: the regression tests validate the core processes simultaneously for all parallel projects: An enormous saving!

The only disadvantage of release management is that the fixed go-live dates require a certain flexibility – agility is the buzzword – in the scope of the functions to be introduced: If the development or testing of a functionality is not finished, it must be assigned to the next release. This hurts at first. This modern agile approach therefore requires a training and familiarization phase, and there will also be many discussions at the beginning, but over time the timing of the introductions will become established.

Good planning and good monitoring of project progress is key here!

Major and minor releases

Major Releases

The projects are within the scope of the major releases, which generally take three to six months. If a project requires an even longer runtime, it simply selects the go-live date of a suitable higher release.

Such major releases also involve major changes to the core processes and therefore require complete regression and integration tests.

Annual upgrades

A recommended practice is to plan four major releases per year and reserve the second quarter for upgrades.

Once this procedure has become established, you no longer waste time discussing when IT will be given a window for an upgrade: Usually never!

Not only do you get the latest features and Fiori apps through regular upgrades. But you also avoid the effort of identifying and reporting errors that have already been rectified.

The annual regularity of upgrades reduces the delta between SAP releases, and the teams carrying out the upgrades become more experienced and efficient: Upgrades are much faster and less painful, because the larger the delta, the more complex the upgrade project becomes.

After all, a regular annual upgrade will avoid the cost trap of trying to prepare the system for an aggressive new implementation by importing lots of SAP notes (corrections) only to realize later, having learned from bitter experience (here we go again!), that an upgrade cannot be avoided after all (this was my experience with an implementation in Brazil, for example). Of course, this naive approach delays the project.

Minor Releases

Minor releases have a shorter term. They bundle error corrections and smaller extensions; they go live much more often and only require the regression tests of the core processes and the tests of the respective extension.

In a dual landscape, maintenance takes place in a separate transport landscape, the maintenance landscape.

If you want to plan minor releases together with major releases in systems with active FB, you have to consider the restriction that you cannot use request-for-changes (RfC) without additional customizing, which is acceptable for all companies that have outsourced the RfC workflow to an external ticketing system anyway.

Standard ChaRM

If, on the other hand, you save the not inconsiderable costs for an external ticketing system and use the built-in Request for Change (RfC) workflow instead, you use the classic ChaRM without release management for the maintenance landscape. Then you are more flexible when planning the go-live dates for maintenance.

FB Enhance Pace

Since SAP Solution Manager SP16 (Focused Build SP11), you can also use the new Focused Build ENH Pace instead of the classic ChaRM. This is useful if you are already using Focused Build for the Requirement2Deploy process. You don’t have to configure the standard ChaRM, but can use this turnkey solution, and the team members move in the familiar Fiori environment.

The disadvantage is that FB ENH Pace only supports continuous cycles, i.e. cycles that only know the “Active” phase and individual changes. This makes it more suitable for a pure Detect2Correct process in which individual error corrections are carried out without potential side effects. This is because, in the case of a pre-import, the shipment is finally imported into the production system and any inconsistencies cannot be consolidated later by the cycle import, as is the case with phase cycles.

Bundled productive imports

A regular go-live event in the maintenance environment (e.g. every second Thursday at 10:00 UTC) has the great advantage that these dates become known to all those involved over time, especially the users in the specialist departments, and everyone automatically adheres to them.

This regularity is achieved voluntarily, so to speak, by using the phase cycles of the standard ChaRM. However, the strict planning of go-live dates by release management forces this regularity.

Both release and phase cycles support the quality of the tests by locking the test system against normal changes in the Test phase.

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