Release Management for Hybrid SAP Landscapes with Solution Manager ChaRM or Focused Build
This blog is an adaptation of the week 5 of openSAP course ‘Agile Project Delivery with Focused Build for SAP Solution Manager’, reviewed previously here. openSAP slides for week 5 are available here.
We will review the concepts from the course, then try to understand how those concepts can be applied or adapted on an hybrid landscape with ChaRM or Focused Build.
Best Practices for Change Logistics
Manage ABAP and non-ABAP technologies via CTS+.
Create and release transports in direct context of work items.
Control technical deployment via workflow.
Remove the option to create transports directly on backend systems
Use transport of copies
Transport of copies is a mecanism that allows iterative testing: it is possible to test work items in the QAS without releasing the original transports.
Release original transports when the release enters the test ohase : When ready for preproduction environment.
Use CSOL and downgrade protection to receive warnings before creating a real downgrade.
Create a blacklist of critical objects - with additional approvals for change to these objects.
By default, Solution Manager create an import sequence in the order of release from the DEV environment. You can however use preliminary import to decouple from the release/accelerate the deployment of specific changes.
Software Deployment
© 2021 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC
Imports
Transports of copies (ToCs) are automatically deployed in the QAS system: no bacth job
A batch job is needed in QAS for defect correction transports, or released transports. A good frequency is between 15 to 60mn.
During the final integration and regression test phase, a batch job is needed for the Pre-production environment. A daily import job is a good frequency.
Transports checks
You can use the program /SDF/CMO_TR_CHECK in SE38 to execute transport checks before import, and identify:
Sequence violations
Referenced objects that will not be imported causing an import error
How long the import will take
Batch jobs
You can use the program /SALM/BATCH_IMPORT_TRIGGER in SE38 to execute the batch imports
You can use specific variants for specific environments (QAS, PRE, Production)
You can schedule reccuring jobs
You can enable downgrade checks and if needed skip downgraded transports
You can simulate the import and identify errors before the actual execution
© 2021 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC
Release Management
© 2021 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC
If you have multiple projects running in parallel, it is recommended to try to synchronize deployments
The testing effort is reduced because tests are executed once instead of several times.
The risk of system destabilization is reduced because cross-project functions are bundled before they are deployed on the production system.
Activities by phases & Status of work packages/Change Documents
Prepare Phase
Work package/Change documents are Created
Build Phase
In Development: tasks are released
To be tested: import of copies in QAS
Sucessfully tested: release of transports and import in QAS
ChaRM workflow can be enhanced to behave like Focused Build: A special status can be added to identify items handed over to Release: only those should be released/imported in Pre-production. This means ‘Sucessfully tested’ should not release the transport anymore… A trick to easily make this enhancement is to :
Change the name of the status ‘Sucessfully tested’ to ‘Hand Over to Release’, thus keeping all the specific customizing for transport release.
Create a very simple intermediate status between ‘To be tested’ and the renamed ‘Hand Over…’. This status, without any specific attributes, will be the new ‘Sucessfully tested’.
Perform all the additional customizing (actions, conditions, security…)
Test Phase
Handed over to Release: import in PRE
Deployment Preparation phase
Execute the technical steps to perform the cutover into the production system
Use check report /SDF/CMO_TR_CHECK to prepare production import
Deployment Phase
Import in Production and set productive status to work packages/Change documents
Defect Correction
Here is how the overall defect correction process looks like with Focused build:
Actions
The tester is assigned to a test package. He creates a defect in case of error
The support team performs a root cause analysis
The architect is involved if the correction is complex or necessitate a change in the solution
The Development Team is involved if necessary, to process the correction
The tester retests
If we look at the involved roles:
This defect correction logic applies during hypercare or maintenance phase:
An end user create an incident ticket
The support team processes the ticket. If the correction is known or if there is no change to the solution needed, the team handles it. Otherwise:
It is confirmed this is an incident: the architect, functional consultant and/or Development team is involved to find a solution
It is estimated this is an enhancement: the project team or PCOE is assigned to find a solution, with the involvment of the business if needed.
This is what the process flow looks like with Focused Build
The tester creates a defect from a test case
The developper creates a defect correction from the defect
The work package is automatically updated to the status ‘In Repair’ to show there is a correction ongoing
Once the developper has corrected the defect, he updates the defect correction ticket, which will automatically update the defect to ‘Solution Proposal’
If the correction is confirmed on the defect, the defect correction is set to ‘Confirmed’, and the work package is set to ‘To be tested’
Focused Build automatically synchronizes the status between the defect and the defect correction
The tester needs to work only on the defect
The developer needs to work only on defect correction
Optionnaly, lets say you are using ChaRM without defects tickets.
Work Packages are replaced by Change Documents (Normal, Urgent…)
In that situation, when there is a defect during testing, the Change Document is set back to the status ‘In Development’, which would allow the creation of a new task (in case of Normal Change - Transport of Copies) or a new transports (in case of Urgent Changes - No transport of Copy)
Another situation would be to use an agile tool (Jira, Azure DevOps) to manage your defects. Then, we can imagine an integration with either Focused Build or ChaRM, to manage the creation of either Defects or Change Documents).
When the Work Item is set to ‘In Development’ in ADO, it triggers the creation of a Change Document in ChaRM
When the Change Document is set to ‘To be tested’, the ADO item is updated
Defects created in ADO automatically set the status of the Work Item to ‘In Repair’, and the Change Document is sent back to ‘In Development’
When the correction is done, the Change Document goes back to ‘To be tested’. The defect is updated, retested, and if okay, the ADO Work Item updated.
Release Dashboard / Release checks
Focused Build provides a dashboard with ratings that can be used by the Release Manager for better decision making:
Status Compliance Rating – Checks that a WP or WI is in the right status compared to the Release Status
Test Rating – Checks that a Work Package is part of a Testplan/Testpackage
Document Rating – Checks for every WP/WI to see if a required document in the required status exists
Transport Rating – Checks that a transport is successfully imported in the right system according to the status of the work item or release
Retrofit Rating – Checks if a transport created in the maintenance landscape has been retrofitted to the project landscape
If you are using ChaRM, you can still find those information using different transactions and tools (ChaRM web interface, Administration cockpit, etc).
Handover to Operations
To manage transports post go-live, you can either use Focused build (variants 1 or 2), ChaRM (Variant 3), a combination of both (Variant 3), with or without an external agile tool added in the mix.
Each option has its advantages and inconvenients, summarized in the table below.
On large SAP programs (multi-projects, years, releases), there is a preference to go with variant 3, as it allows to work independently on innovations and production support, at the same time.
This specific setup (innovation and maintenance in parallel) calls for a ‘dual landscape’. This means having two different landscapes (two Development systems, two QAS), leading to the the same production environment.
Checklist for change request management implementation
✓ Change processes defined?
✓ Roles and responsibilities defined?
✓ Release management defined?
✓ Responsibilities for dual-landscape-synchronization defined?
✓ Cutover strategy from innovation to maintenance landscape defined?
✓ Training concept and training material created?
✓ Suitable ChaRM Go-Live defined?
✓ Internal resources enabled for ChaRM-support?
Below is a summary of activities per role:
Conclusion
Release Management with either Focused Build, ChaRM or both, is critical for Agile SAP Projects delivery. In some cases, another tool enters the mix (Jira, Azure DevOps, Octane), and there is a need for integration and synchronization. But the benefits (Dual landscape, Retrofit, Downgrade Protection, transparency of changes) far outweight the costs.
