Does gCTS allow Zero Downtime deployments/transports to your PROD S/4 HANA on-prem?

[NabiZamani]

Using gCTS in combination with Jenkins etc allows you to deploy/transport changes easily to your PROD S/4 HANA "automagically" using your CI/CD pipelines. In the "old" world (= without gCTS), releasing changes to a PROD ABAP means you may get some really ugly problems when using a zero downtime approach:

ABAP has a so called code buffer (not sure if that's the real name). This code buffer does not get updated under certain circumstances. This can lead to some really ugly problems. The side effects can be avoided with some effort, none of the options is considered as "cool" outside the ABAP world. In the worst case, you can have real bugs/errors suddenly in your PROD system. Such errors can be really hard to analyze. Here a some more details (simplified):

• "code frequently used" at runtime is kept in a buffer by your ABAP AS (keep in mind you may have multiple ABAP AS)
• If an import changes such code then the buffer "usually" gets updated in the best case
• However, if such buffered code is currently in use (i.e. people are calling your OData services frequently during your imports...), then the buffered code won't get updated (even though your import result shows all "green")
• The buffer won't even get updated automatically later
• All this may happen for web services in general, but I think also for reports, dynpros,... everything that is used often/frequently is a good candidate for issues
• This may even lead to inconsistent code in your different Application Servers - good luck debugging I can tell you...

Solutions so far have been:

• Always have a controlled restart of all your ABAP Application Servers after your last import has finished (developers can't usually simply do that, also leads to downtime)
• Use some special TAs and tools - not easy, you must exactly know what you're doing. See for example https://launchpad.support.sap.com/#/notes/102069/D and https://wiki.scn.sap.com/wiki/display/Basis/How+to+Reset+different+SAP+buffers
• Make sure that nobody is really using the code under deployment/import. Example: if OData Services are affected, then deactivate the SICF nodes before the import and re-activate them when the import is done. Works fine, but means downtime from user perspective
• Setup a mirrored PROD environment and switch back and forth. Expensive from both costs and effort perspective (on different layers), needs discipline (also across all your developers).
• Anything I forgot...?

As you can see, all of the cases above are either hard to achieve or cannot be carried our without a "downtime" from end user perspective. In agile and DevOps environments this feels like stone age.

Questions

1. How does gCTS or S/4 HANA treat such issues we had in the past?
2. Has anything been improved?
3. Can I trust that importing into PROD won't lead to any of the above mentioned issues when using gCTS?
4. How do you achieve "cheap", DevOps like releases to PROD without downtimes from user perspective? (cheap means without mirrored prod environment, etc...)

Looking forward for your responses!

Thanks, Nabi

[Karin]

Hi Nabi,

gCTS is based on the same tools as CTS. Transport requests are created when you decide to activate a commit. The transport request contains the objects that are different between the commit that was previously active and the commit that you chose. The request is then imported via R3trans and tp. So the basic import process is still the same.

gCTS helps e.g. with the amount of requests that need to be imported into your production system. You don't need to go through the complete list of commit (and therewith create a transport request for each and every commit that might only contain few corrections). Importing just the latest commit is sufficient. Every object needs to imported only once.

So gCTS itself does not improve the online import functionality with respect to required restarts or options to use the coding. It can help reducing the import times.

Kind regards
Karin

[NabiZamani]

Thanks, Karin. I hoped there was maybe some improvement with S/4 HANA 2020...