How best to define check-variants to be eventually used during transport-release?

[BaerbelWinkler]

I'm currently configuring our new central system for ATC-checks (for some background, please see here and here) and before I get lost in the details, I'd appreciate feedback on my current thinking of how to actually define the check-variants. The system is on NW 7.52 with all the required OSS-Notes applied. The satellite-systems are on NW 7.50 and also have the needed OSS-Notes.

My starting point was the check-variant currently used during transport-release (without blocking it) which in turn is an adapted version of SAP's DEFAULT variant with some checks from FUNCTIONAL_DB and PERFORMANCE_DB. So I re-created the variant in the central system picking and chosing most of the checks I already had - if they showed up as RFC-enabled. I also picked some of the S/4HANA readiness checks.

Here are some of them:

I then did a trial run with one package in a sandbox system and after about 2 hours got the results with quite a "few" findings - well make that a couple of thousend priority 1 findings!

I plan to take this hopefully fairly representative result to now define the checks used in the variant to create the baseline. My thinking is, that I'll start with a copy of the variant I now have and uncheck some of the checks which I'd eventually like to still show during transport release - like e.g. direct updates on SAP-tables even if they've been in the program for ages. As this will then be a priority 1 finding (it's a 3 right now), requiring either getting fixed or asking for an exemption, we'll at least become more aware of where this type of processing is used in programs requiring changes i.e. actively used.

The other thing I need to do - and the one I'm looking forward to the least! - is to tweak the priorities for many of the checks. Most of the ones currently defined as 1 or 2 will become a 3 in order to still get flagged but to not prevent the release of a transport. But there are also some priority 3 findings (like the one mentioned above regarding hard updates on SAP-tables) will become a priority 1 finding.

I will of course offer some sessions / workshops for our developers before we role this out in earnest. I already gave them some fair warning that "something" is coming but that was before we actually had the central system up, so I then couldn't show them much about the baseline or the exemption process.

At the moment I have these questions:

1. Is this the right approach?
2. Does it make sense to include S/4HANA checks (eventually set to priority 3 to just give a heads-up) in the variant used during transport-release or should this be tackled separately?
3. Am I going about this in the right sequence?
4. Do you have any recommendations of what I should and shouldn't do?

Looking forward to your thoughts and comments!

Cheers

Baerbel

[BaerbelWinkler]

Here is an update (not just but to also "bump" this question as I'm really interested to get some answers):

After doing some initial trials with sandbox systems, we also "attached" our two main development systems (NW 7.50, EHP 😎 to our central ATC system.

I then defined check variants in the satellite systems utilising the centrally defined variant tentatively planned to eventually being used during transport release. To get a better idea of how actual development will later be affected and to also tweak the variant definition if and as needed early on, I'm using this new check variant in a daily batch-job to run ATC-checks on objects contained in modifiable transport requests in the dev-systems. I receive a daily email from this and can tell by the summary of the ATC-results if it's worthwhile to check them directly in the system. In case that you are interested in how this gets done, please see my earlier blog post where I describe the functionality.

Dependend on the results, I'll either decide to exclude certain checks and/or to tweak their message priorities. There are two things I'd like to avoid:

1. Making the lists of check results too long for the developers to properly work through before releasing a transport
2. Making the lists of checks too "forgiving" by either setting almost everything to priority 3 or eliminating too many checks completely which would then lead to a lot of unwanted stuff slipping through unnoticed

Bottom line: I'm trying to find the right the balance

Can anybody help me do that?

Cheers

Baerbel

[BaerbelWinkler]

Since posting the earlier update, I put my thoughts and what I did thus far into the 3rd part of my blog series about setting up ATC-checks:

Setting up a central ATC-system – Part 3: Tweaking the settings to our liking

Bottom line is that I have a hunch, that this will work out fairly well. But only time will really tell!

As nobody else povided a response, I'll just "accept" my own answer but will leave the thread open in case somebody would like to chime in.

[pokrakam]

My response would still be the same as I posted in your very early question on this topic - make it very forgiving, maybe just one or two blocking checks. Let it run for a week or two to get a feel for the volume of change and number of errors, then start upping the priorities on other checks.

Also consider running ATC as a regular (nightly) job - possibly with different checks. This way you can chart the change over time.

[BaerbelWinkler]

Thanks, Mike!

Yes, that's along the lines of what I plan to do.

I already have a daily job running utilising the new central checks on currently still modifiable transports and check the results each day to then tweak e.g. the message priorities (mostly from "error" to "information")

Over the next two weeks I'll do workshops with the developers to clue them in and we'll then start using the new central check variant during transport release - but the release will not yet be prevented. After about 3 weeks of that I'll gather feedback from the developers to find out if any more tweaks are necessary. Only then will we switch to preventing the release of tasks/transorts in case of prio 1 & 2 errors are encountered. But, an exemption process will also be made available in parallel.