Searching for „Best practice“: 5-system landscape for Release Management

[UweFetzer_se38]

For our release management (3 month cycles) we want to implement the recommended 5-system landscape:

I’m sure many of you are working in such a landscape, but I’m not finding a best practice guide how to handle this in real life.

My naïve understanding is the following:

At the beginning of the release cycle DEV and QAS (release n) are copied and service packs etc. are implemented if needed into the new systems. The developments for the release (incl. project works) are started in the DEV n+1 system.

Urgent developments (error corrections) are implemented and transported in the emergency lane and also have to be implemented in the release lane.

At the end of the release cycle, service packs are implemented into PRD, the PRD system is switched over to the release lane and the transports of the release lane are imported into PRD.

DEV and QAS of the emergency lane can be deleted, new copies of the DEV n+1 and QAS n+1 are created for the n+2 release. The cycle begins again.

Now my questions: Is my understanding reasonably correct?

• How do you make sure, that the emergency changes are also implemented into the release lane? Organizational or with tools?
• How will the PRD switch to the release lane take place (or should my basis team already know this?)?
• Any other real life tips what we have to consider?

I am grateful for every advice,
Uwe

[architectSAP · Accepted solution]

Hello Uwe,

Your understanding is pretty accurate. Concerning your questions:

• There are tools to help you keep your developments in sync like Change Request Management Enhanced Retrofit, but that will not necessarily guarantee 100% consistency, so that a well defined of process is still needed.
• As you describe, during the switch you have to bring your production system to the same release and patch level as your project landscape and then import the transports.
• Depending on the magnitude of the change, e.g. when there are large developments or even an upgrade or database migration involved, I like to test the switch in what I call a dry run to avoid any surprises as close as possible to the actual event. It is also a good idea to define the regression testing needed to give the green light for the switch to go live already during the user acceptance testing so that there is no ambiguity what needs to be tested and the users are already familiar with the tests as well.

Best regards

Frank

[UweFetzer_se38 · Accepted solution]

Thank you Frank, especially for the Retrofit-Link.

[SuhaSaha]

Hi Uwe,

We have exactly the same landscape as yours and i have exactly the same open questions as you 🙂

A few points about our "emergency" landscape:

• Refreshed after each release (same stand as PROD)
• Manual "merging" is done between emergency & release as-of-now

As i am using abapGit for a couple of months, i was wondering if i can use it to avoid having a separate "emergency" landscape. My idea is as follows:

• Create a branch for new release & work on it
• Upon go-live of the release merge the branch into the master
• Work on the master (= Production stand) for emergency release v/s create a branch for every fix & merge it to the master

Unfortunately the "merge" functionality in abapGit is not stable (see: https://github.com/larshp/abapGit/issues/917). Until then the merge functionality is sorted out, i have to park my idea & continue working with the existing landscape.

BR Suhas

[UweFetzer_se38]

Hi Suhas,

nice idea with abapGIT 🙂
but unfortunatelly I think - currently - I'm not able to explain this idea to the management board and leave abapGIT in my private environment (yet).

But you are right, in the long term SAP has to handle a GIT-like version management.

[UweFetzer_se38]

In the DSAG forum there's currently the same discussion: https://www.dsag.de/beitraege/sap-systemlandschaft-welche-anzahl-macht-noch-sinn (German, Login required).

For all non-DSAG useres out there: here's the linked "Best-Practice Document / Elements of a Software Change Management Strategy" by SAP

[alejiandro_sensejl]

Hi Uwe,

We also started with a similar landscape as you describe. Our business guys were quite unhappy with this since even small changes were delayed and always needed to wait for the next release deployment. Therefore we started doing minor changes always in emergency / production lane. Unfortunately this lead to very much effort to perform permanent retrofits from production lane to release lane that it just did not work out for us.

We are now using a 5-tier lane to production.

DEV -> TEST (Test by IT like Dev, Consultants, Project Leads, …) -> QAS (Test by Business/Customer) -> PRE PRD -> PRD

We have 2 sync points per year for system copy for PRE PRD => QAS and QAS => TEST using a TDA (test data anonymization) tool. PRE PRD is checked via Repository and Customizing Compare to stay identical and a Copy of PRD to PRE PRD is regularly considered.

With this our business is VERY happy with us. I also think now, they are right to expect a fast delivery of their change requests. The release lane was just for us IT guys to have less risk and a better feeling most of the time for preparing release packages. But that is nothing the business should need to worry about and we – as IT guys – just have to get our hands dirty instead of relying on such a fiddly think like a release lane.

Nevertheless, we are still using up to 2 additional lanes (with 2 tiers Dev + QA each) for LARGE implementation projects, e.g. upgrade of SAP components or implementations > 6 months. When merging the project QA into production lane we rely on ChaRM component of SAP Solution manager a lot. We are especially using DGP (Downgrade Protection) and CSOL (Cross-System Object Lock) tools.

You should really consider at least a PRE PRD. We have learnt the hard way that emergencies are more frequent than you may expect and “emergencies” are sometimes waiting for approval by business for more than one week in QAS. This means that QAS is not a 1:1 copy of PRD most of the time for us, even more then tests are delayed. Therefore we use PRE PRD system for (technical) validation (= completeness of custom developments) of release packages to production before applying patches to PROD. PRE PRD is sometimes also used for trainings by business.

Best regards,

Alej

[UweFetzer_se38]

Hi Alej,

I totally understand the "unhappyness" of the business, same here, especially because they used to get solutions by just calling the Devs and "can you please ...".

But I think the time for such hush-hush operations is over. You can't do this is in such large and linked landscapes anymore.

However, this decision was made a year (or so) ago and we are working with releases since January.