This is part 4 of my ongoing blog series about setting up our central ATC system. For the overall journey, please see the long, long winding road edition.
Part 1: Setting the stage and Part 2: Preparing the systems and Part 3: Tweaking the settings to our liking
As mentioned at the end of Part 3, I had planned some sessions with our developers (inhouse and external) to get them up to speed with the coming changes to a) the ATC-checks and b) the transport-release process.
I created both a German and an English version of the presentation as we have a rather heterogenous setup as far as development activities go:
Obviously, doing presentations was easier for some of these groups than for others! For our internal and external inhouse developers I offered two meetings in German with the added option to join virtually for those working from home. I also did a WebEx-session in English for the developer leads in Brazil and the U.S.
For everybody - including the contracted developers - the presentations have been made available as PDF-files included in our Developement Guidelines which in turn are already available and accessible to everybody via a Confluence space.
Based on the presentations and on what I learned while setting up the ATC, I also prepared an FAQ-page and made it readily available via our guidelines-space.
Collecting feedback
When planning the sessions, I had allowed enough time to discuss any questions which might come up. One of those was how to best deal with findings preventing the release of a transport. Comments ranged from "developers will simply use the pseudo-comment if one is available" or "they'll just request an exemption with the expectation that it'll be granted quickly" to "findings should be detected and fixed before even releasing the transport". These discussions most definitely helped to shape the FAQ-page!
After the second workshop, the new check-variant from the central system was activated in the development systems but without yet turning on blocking on transport release in case of priority 1 and 2 findings. The developers were invited to take a close look at the check-results they get in the normal course of their work and to collect feedback for things like findings where the priority might still need to be tweaked. The exemption process was also activated so that the developers could try it out without it having any real consequences yet.
In order to hopefully alleviate some "fears", my presentation contained a slide with some key take-aways:
While working on the presentations and grabbing detailed screenshots for them, I noticed a little and potentially confusing issue with the way exemptions were shown in the result list: all of them showed "Has Pragma" even though they were actually exempted by being included in the baseline. As I hadn't received any responses to my question about this, I had opened an OSS-message and was quite surprised when it was directly and without any delay or further questions forwarded to development support within a day. I don't remember that ever happening to me before!
This turned out to also be a good way to correct the support user's settings which needed some added authorizations and access in order to reproduce the issue in the development system and the central ATC-system - something which we hadn't yet had on our radar for this new setup. So, quite a good thing that we happened upon this before we ran into any issues later when the system was live!
As of this writing, the OSS message is on hold as it will require more than a quick bug fix to get corrected. Once we hear back, I'l update my question with the information about the provided solution.
Throughout the process of getting the central ATC-system setup we had to do a bit of tweaking to the various authorizations. The devil with those really lies in the details! In the end, we ended up with these settings:
Even though this project to set up our central ATC-system took longer than expected, it was still a fairly straightforward thing to do. What really helped a lot was the good documentation provided both within the ATC-system and here in the SAP Community where esp. Olga Dolinskaja's blog posts laid out the to-do's fairly clearly. It also obviously helped that we were doing it on a relaxed project time line as it didn't really much matter when it went live. Doing the first trial runs with sandbox systems proved to be a very valuable time investment and avoided "annoying" developers unneccesarily in the actual dev-systems.
Bottom line - and I hope actually working with the central checks from now on will prove me right on this! - investing the resources (money and time) to set up a central ATC-system is well worth it!
This will most likely be the final episode in this blog series as the only thing left to do is to enable blocking of transport release with priority 1 and 2 findings a couple of weeks from now. But that is just a simple "flip of a switch" so not really worth writing home about! This doesn't rule out that I may write a kind of epilogue once we've had this running for a couple of months - and if there's then anything interesting to report.
I hope you find this blog series helpful and I'd be interested to read about your experiences with central ATC-checks in the comments!
Here are the links to the other parts of the series for easy reference:
Part 1: Setting the stage
Part 2: Preparing the systems
Part 3: Tweaking the settings to our liking
Part 5: Keeping an eye on things (January 2019)
Part 6 – accumulated FAQs (March 2021)
For the overall journey, please see the long, long winding road edition.
Part 1: Setting the stage and Part 2: Preparing the systems and Part 3: Tweaking the settings to our liking
As mentioned at the end of Part 3, I had planned some sessions with our developers (inhouse and external) to get them up to speed with the coming changes to a) the ATC-checks and b) the transport-release process.
Getting the developers clued in
I created both a German and an English version of the presentation as we have a rather heterogenous setup as far as development activities go:
- A small inhouse developer team I'm a part of
- Colleagues within our process/functional teams who do some coding
- External developers in Germany who regularly work on site
- Fairly independent inhouse developer teams in some other locations where they have rather specific development needs (e.g. in Brazil)
- Temporarily contracted developers for specific tasks in some locations where we often don't have much if any direct contact with the developers
Obviously, doing presentations was easier for some of these groups than for others! For our internal and external inhouse developers I offered two meetings in German with the added option to join virtually for those working from home. I also did a WebEx-session in English for the developer leads in Brazil and the U.S.
For everybody - including the contracted developers - the presentations have been made available as PDF-files included in our Developement Guidelines which in turn are already available and accessible to everybody via a Confluence space.
Based on the presentations and on what I learned while setting up the ATC, I also prepared an FAQ-page and made it readily available via our guidelines-space.
Collecting feedback
When planning the sessions, I had allowed enough time to discuss any questions which might come up. One of those was how to best deal with findings preventing the release of a transport. Comments ranged from "developers will simply use the pseudo-comment if one is available" or "they'll just request an exemption with the expectation that it'll be granted quickly" to "findings should be detected and fixed before even releasing the transport". These discussions most definitely helped to shape the FAQ-page!
After the second workshop, the new check-variant from the central system was activated in the development systems but without yet turning on blocking on transport release in case of priority 1 and 2 findings. The developers were invited to take a close look at the check-results they get in the normal course of their work and to collect feedback for things like findings where the priority might still need to be tweaked. The exemption process was also activated so that the developers could try it out without it having any real consequences yet.
In order to hopefully alleviate some "fears", my presentation contained a slide with some key take-aways:
Ironing out some final kinks
While working on the presentations and grabbing detailed screenshots for them, I noticed a little and potentially confusing issue with the way exemptions were shown in the result list: all of them showed "Has Pragma" even though they were actually exempted by being included in the baseline. As I hadn't received any responses to my question about this, I had opened an OSS-message and was quite surprised when it was directly and without any delay or further questions forwarded to development support within a day. I don't remember that ever happening to me before!
This turned out to also be a good way to correct the support user's settings which needed some added authorizations and access in order to reproduce the issue in the development system and the central ATC-system - something which we hadn't yet had on our radar for this new setup. So, quite a good thing that we happened upon this before we ran into any issues later when the system was live!
As of this writing, the OSS message is on hold as it will require more than a quick bug fix to get corrected. Once we hear back, I'l update my question with the information about the provided solution.
Throughout the process of getting the central ATC-system setup we had to do a bit of tweaking to the various authorizations. The devil with those really lies in the details! In the end, we ended up with these settings:
Summary of our journey thus far
Even though this project to set up our central ATC-system took longer than expected, it was still a fairly straightforward thing to do. What really helped a lot was the good documentation provided both within the ATC-system and here in the SAP Community where esp. Olga Dolinskaja's blog posts laid out the to-do's fairly clearly. It also obviously helped that we were doing it on a relaxed project time line as it didn't really much matter when it went live. Doing the first trial runs with sandbox systems proved to be a very valuable time investment and avoided "annoying" developers unneccesarily in the actual dev-systems.
Bottom line - and I hope actually working with the central checks from now on will prove me right on this! - investing the resources (money and time) to set up a central ATC-system is well worth it!
This will most likely be the final episode in this blog series as the only thing left to do is to enable blocking of transport release with priority 1 and 2 findings a couple of weeks from now. But that is just a simple "flip of a switch" so not really worth writing home about! This doesn't rule out that I may write a kind of epilogue once we've had this running for a couple of months - and if there's then anything interesting to report.
I hope you find this blog series helpful and I'd be interested to read about your experiences with central ATC-checks in the comments!
Here are the links to the other parts of the series for easy reference:
Part 1: Setting the stage
Part 2: Preparing the systems
Part 3: Tweaking the settings to our liking
Part 5: Keeping an eye on things (January 2019)
Part 6 – accumulated FAQs (March 2021)
For the overall journey, please see the long, long winding road edition.
- SAP Managed Tags:
16 Comments
| User | Count |
|---|---|
| 6 | |
| 5 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
