Technical Articles
SAP Business Technology ABAP environment – Lifecycle Management – sample scenarios
Introduction
In the first blog post SAP Business Technology ABAP environment – Lifecycle Management – Introduction, the focus was on the basics of software component lifecycle management. In this blog I will discuss the three setups to handle the lifecylcle management when developing in the ABAP Environment.
The three scenarios that will be discussed adress the different needs one has depending on the complexity of development project.
- Use Case 1: One Codeline in a 3-ABAP-System Landscape
- Use Case 2: One Codeline in a 5-ABAP-System Landscape
- Use Case 3: One Codeline in a “1-System Landscape”
In addition it will be discussed how to handle Double Maintenance using the ABAP Development Tools in Eclipse.
Use Case 1: One Codeline in a 3-ABAP-System Landscape
You can apply this setup if you have occasional development activities for larger applications where testing needs to run in parallel to development or should take place in a non-development system to ensure the solution also runs in a non-development system. In this setup, you either need to be able to pause development for a fix that has to be delivered before the next release or you have to deliver fixes as part of the next possible release.
This landscape consists of a development, quality assurance, and production ABAP system.
For Go Live/ Development after Go Live (including deferrable corrections)
Starting situation for the Go Live:
- Recently created development ABAP system DEV and other already existing ABAP systems cannot be based on some branch yet, as the software component does not exist yet.
The Go Live process is characterized by creating different systems only when needed for the first time, however, you can provision the ABAP systems already beforehand. Furthermore, the software component of a planned solution does not exist from the beginning. The resulting release branch is YYYY-01. Apart from this, the Go Live process does not differ from the release development processes afterwards.
Starting situation after the Go Live:
- Development ABAP system DEV is based on the master branch
- Quality Assurance ABAP system QAS and production ABAP system PRD are based on the latest release branch YYYY-<nn>. In case of a first release after the Go Live, YYYY-<nn> is YYYY-01
The QAS ABAP system has always the same software state as the PRD ABAP system, unless a new change is tested and released. This means transport requests are released in DEV ABAP systems only if development is completed and it is planned to import the changes to the production ABAP system.
This process can also be used for deferrable corrections, which do not need to reach production before the next development release. These corrections are handled like regular development.
Step | System | Role | Task | Tool |
0 | DEV | Release manager | @Go Live only: Create the software component and pull it initially | Manage Software Components app |
1 | DEV | Developer | Develop new functionality or a deferrable correction. All changes are collected in transport requests | Eclipse with ADT |
2 | DEV | Release manager | Release the transport request. The changes are now in the master branch | ADT: Transport Organizer |
3 | QAS | Release manager | Check out master branch/ @Go Live: pull software component into QAS | Manage Software Components app |
4 | QAS | Tester | Test the change and report test result |
Eclipse with ADT & Custom SAP Fiori apps & external test tools external documentation tool |
If changes are required, repeat steps 1-4 | ||||
5 | QAS | Release manager | Release decision: the changes are successfully tested and approved. | External documentation tool |
6 | QAS | Release manager | Create a release branch YYYY-<nn+1> (@Go Live: YYYY-01) | Manage Software Components app |
7 | QAS | Release manager | Check out the new release branch YYYY-<nn+1> (@Go Live: YYYY-01) into QAS | Manage Software Components app |
8 | PRD | Release manager | Check out the new release branch YYYY-<nn+1> (@Go Live: YYYY-01) into PRD | Manage Software Components app |
Urgent Corrections
Starting situation:
- Development ABAP system DEV is based on the master branch
- Quality assurance ABAP system QAS and production ABAP system PRD are based on the latest release branch YYYY-<nn>. In case of a correction after the Go Live before the second release, YYYY-<nn> is YYYY-01
This process differs from the previous one in the branch it is developed in. As the correction is too urgent to release it with the next development release only, it is done in the release branch. To achieve this separation, all current development activities need to be paused because the DEV ABAP system needs to check out the latest release branch instead of the master branch.
Step | System | Role | Task | Tool |
1 | DEV | Release Manager | Check out the release branch YYYY-<nn> | Manage Software Components app |
2 | DEV | Developer | Fix existing functionality. All changes are collected in transport requests | Eclipse with ADT |
3 | DEV | Release manager | Release the transport request. The changes are now in the release branch YYYY-<nn> |
ADT: Transport Organizer
|
4 | QAS | Release manager | Pull the software component to get correction into already checked out release branch YYYY-<nn> | Manage Software Components app |
5 | QAS | Tester | Test the change and report the test result |
Eclipse with ADT & custom SAP Fiori apps & external test tools external documentation tool |
If changes are required, repeat steps 2-5 | ||||
6 | QAS | Release manager | Fix is successfully tested and approved | External documentation tool |
7 | PRD | Release manager | Pull the software component to get correction into already checked out release branch YYYY-<nn> | Manage Software Components app |
8 | DEV | Release manager | Check out the master branch in DEV | Manage Software Components app |
9 | DEV | Developer | Perform the same changes as for the correction in the master branch and release them, see chapter “Double Maintenance of Corrections into Development” | Eclipse with ADT |
Use Case 2: One Codeline in a 5-ABAP-System Landscape
In this section, we will take a closer look at the following scenario: one development and correction codeline in a 5-ABAP-System landscape.
You can apply this setup if you have permanent/infinite development activities for large applications with many developers, where development cannot be paused to implement an urgent correction. Corrections need to run in parallel to development and on a released state. You need to separate testing from development to ensure the solutions also runs in a non-development ABAP system before being delivered to production.
General considerations
- ABAP systems COR and QAS have the same software state as the production ABAP system PRD, unless a new change is tested and released. This means transport requests are released in the DEV ABAP system only, if development is completed and it is planned to import the changes to the production ABAP system.
- Releases are planned and communicated to development in advance:
- Upon cutoff date, development is finished. All developments that are released at this time, must be tested and be of good quality. From then on, you have to fix defects in the COR system and maintain them in parallel in the DEV system, see Double Maintenance.
- Upon release date, all defects must be fixed. If you make the decision during testing in the QAS system that a complete functionality is not delivered, developers must delete, revert, or disable the functionality in the COR system and release the corresponding transport requests. You cannot remove objects from the release branch, e.g. by de-selecting transport requests. For reverting objects to an older transported state, use the compare editor of the Eclipse “History” view. If the withdrawal of the functionality shall be performed in the DEV system as well it is considered as a correction and you have to perform Double Maintenance.
- The released software state from the COR system is imported into the production ABAP system(s) PRD.
- ABAP system COR is usually locked for development. First, this means developers cannot do changes by default and there are two approaches how to handle this:
User Locking | Read-Only + Write Developer Role | |
How-to Details | Unlock user on demand | Assign write role on demand |
Pros | No additional role needed |
· No generic read user needed · No logon with different user for read access needed · User-specific auditing |
Cons | Generic read user needed if you want to provide read access | additional role needed |
Second, developers are also not allowed to create transport requests and tasks on their own, but it’s the release manager who creates them for all developers. This separation is achieved by assigning business catalog SAP_A4C_BC_TRN_MNG_PC (Development – Transport Management) to the release manager instead of the developer role in the correction ABAP system COR.
For Go Live/ Development after Go Live (including deferrable corrections)
Starting situation for Go Live:
- Just created development ABAP system DEV and other already existing ABAP system cannot be based on some branch yet, as the software component does not exist yet
The Go Live process is characterized by creating different systems only when needed for the first time, however, you can provision the ABAP systems already beforehand. Furthermore, the future solution’s software component does not exist yet at the beginning. The resulting release branch will be YYYY-01. Apart from this, the Go Live process does not differ from the release development processes afterwards.
Starting situation after Go Live:
- Development ABAP system DEV and test ABAP system TST are on the master branch
- Correction ABAP system COR, quality assurance ABAP system QAS, and production ABAP system PRD are on release branch YYYY-<nn>
This process can also be used for deferrable corrections, which do not need to reach production before the next development release. These corrections are handled like normal development.
Step | System | Role | Task | Tool |
0 | DEV | Release Manager | @Go Live only: Create a software component and pull it initially | Manage Software Components app |
1 | DEV | Developer | Develop a new functionality or a deferrable correction. All changes are collected in transport requests | Eclipse with ADT |
2 | DEV | Developer | Once development is finished, release the transport request. The changes are now in the master branch |
Eclipse with ADT: Transport Organizer view
|
3 | TST | Release manager | Pull the software component into system TST | Manage Software Components app |
4 | TST | Tester | Test the change and report the test result |
Eclipse with ADT & custom SAP Fiori apps & external test tools External documentation tool |
If changes are required, repeat steps 1-4 | ||||
6 | QAS or any other | Release manager | Cutoff: at cutoff date, create a release branch YYYY-<nn+1> (@Go Live: YYYY-01) (“release candidate”) | Manage Software Components app |
7 | QAS | Release manager | Check out the release branch YYYY-<nn+1> (@Go Live: YYYY-01) into system QAS | Manage Software Components app |
8 | QAS | Tester | Test the release candidate and report the test result |
Eclipse with ADT & custom SAP Fiori apps & external test tools External documentation tool |
9 | COR | Release manager | Check out the branch YYYY-<nn+1> (@Go Live: YYYY-01) into system COR | Manage Software Components app |
10 | COR | Release manager | Enable the respective development users for development in system COR, depending on the process you decided for, either by unlocking or assigning a different role | Manage Business Users app |
11 | COR | Developer | Implement the correction | Eclipse with ADT |
12 | COR | Release manager | Release the transport request. The changes are now in the release candidate. | Eclipse with ADT: Transport Organizer |
13 | QAS | Release manager | Pull the software component to get the correction into the already checked out release branch YYYY-<nn+1> (@Go Live: YYYY-01) | Manage Software Components app |
14 | QAS | Tester | Test the change and report the test result |
Eclipse with ADT & custom SAP Fiori apps & external test tools External documentation tool |
If changes are required, repeat steps 11-14 | ||||
15 | QAS | Release manager | Release decision: the changes are successfully tested and approved | External documentation tool |
16 | PRD | Release manager | Check out the release branch YYYY-<nn+1> (@GoLive: YYYY-01) into system PRD | Manage Software Components app |
17 | COR | Release Manager | Disable the respective development users for development in system COR | Manage Business Users app |
18 | DEV | Developer | Perform the same changes as for the correction in the master branch (Double Maintenance) and release them | Eclipse with ADT |
19 | TST | Release Manager | Pull the software component to get the correction into the already checked out master branch | Manage Software Components app |
Skipping a release
If issues during the test phase of YYYY-<nn+1> cannot be fixed in a reasonable time frame until the next release date, you can skip that release, especially if you have a tight release schedule (“continuous delivery” model). In that case, you have to perform double maintenance for the unfinished corrections from YYYY-<nn+1> in the master branch of the development ABAP system, release them, and create the new release branch YYYY-<nn+2> derived from that master. That way, branch YYYY-<nn+2> contains finished new development as well as the unfinished corrections from branch YYYY-<nn+1>. Afterwards, you can bring system COR and QAS to branch YYYY-<nn+2> and continue with that.
Note that branches cannot be deleted or marked as obsolete. Therefore, it’s important to use other tools to inform consumers about not using branch YYYY-<nn+1>.
Urgent Corrections
The starting situation:
- Development ABAP system DEV and test ABAP system TST are on the master branch
- Correction ABAP system COR, quality assurance ABAP system QAS, and production ABAP system PRD are on release branch YYYY-<nn>
This process is a subset of the previous development process and can be applied to corrections that are too urgent to release with the next development release.
Step | System | Role | Task | Tool |
1 | COR | Release manager |
Enable the respective development users for development in system COR, depending on the process you decided for, either by unlocking or assigning a different role. Create a transport request. |
Manage Business Users app |
2 | COR | Developer | Implement the correction | Eclipse with ADT |
3 | COR | Release manager | Release the transport request. The changes are now in the release candidate | Eclipse with ADT: Transport Organizer |
4 | QAS | Release manager | Pull the already checked out branch YYYY-<nn+1> into QAS | Manage Software Components app or external tool calling the “pull” service of communication scenario “Test Integration” |
5 | QAS | Tester | Test the change and report the test result |
Eclipse with ADT & custom SAP Fiori apps & external test tools External documentation tool |
If changes are required, repeat steps 2-5 | ||||
6 | QAS | Release manager | As the correction was successfully tested before it gets approved now. | External documentation tool |
7 | PRD | Release manager | Check out the release branch YYYY-<nn+1> into system PRD | Manage Software Components app |
8 | COR | Release Manager | Disable the respective development users for development in system COR | Manage Business Users app |
9 | DEV | Developer | Perform the same changes as for the correction in the master branch and release them (see Double Maintenance). | Eclipse with ADT |
10 | TST | Release Manager | Pull the software component to get correction into already checked out master branch | Manage Software Components app |
Use Case 3: One Codeline with On-Demand Development ABAP systems
In this section, we will talk about having one codeline with on-demand ABAP systems.
You can apply this setup if you have:
- Small development projects (e.g. one SAP Fiori application, one developer)
- Occasional development activities (e.g. after an initial development phase, it is expected to only implement new features on a yearly basis)
The ABAP system landscape consists of a permanent production ABAP system and an on-demand development ABAP system.
The advantage of this setup is that you have to administer few ABAP systems and only pay for the development ABAP system during the development periods. The payment model according to the lifetime of a system requires an SAP Cloud Platform enterprise agreement contract.
The disadvantages of this setup are that de-commissioning the development ABAP system means losing the change history as well as the configuration and application data.
The user base and authorizations have to be set up each time the development system is provisioned.
Not testing with a transported version of the solution always takes the risk of forgetting to transport an object. This risk might be minimized a little by testing in the development system on the release branch.
A much more production-like test can only be ensured in a non-development system, where the objects of the solution are initially created and changed by pulls, and where there is no authorization automatism for testing, see tester role in “blog post 1 Required Business Roles”.
We thus strongly recommend developing with use case 1 instead of 3. The quality assurance ABAP system might be de-/commissioned on demand then.
For Go Live
Starting situation:
- A (temporary) development ABAP system is set up
- The production ABAP system is set up
- Both ABAP systems are based on the master branch
Step | System(s) | Role | Task | Tool |
1 | DEV, PRD | System Administrator | Provision a development and a production ABAP system | SAP Cloud Platform Cockpit |
2 | DEV, PRD | User Administrator | Create users and maintain roles | Apps: Manage Business Users/Roles |
3 | DEV | Release manager | Create a software component | Manage Software Components app |
4 | PRD | Release manager | Pull (empty) software component | Manage Software Component app |
5 | DEV | Developer | Develop new functional requirements or correct existing functionalities. All required changes are collected in transport requests | Eclipse with ADT |
6 | DEV | Tester | Test the change and report the test results |
Eclipse with ADT & custom SAP Fiori apps & external test tools External documentation tool |
If changes are required, repeat steps 5-6 | ||||
7 | DEV | Release manager | Release decision: the changes are successfully tested and approved. | External documentation tool |
8 | DEV | Release manager | Release the transport request | Eclipse with ADT: Transport Organizer view |
9 | DEV | Release manager | Create a release branch YYYY-<nn> | Manage Software Components app |
10 | PRD | Release manager | Check out the release branch YYYY-<nn> of the software component | Manage Software Components app |
11 | DEV | System Administrator | De-provision ABAP system DEV | SAP Cloud Platform Cockpit |
Productive usage
- The production ABAP system is based on the master branch
- Since no development can be performed in the production ABAP system, a temporary development ABAP system must be set up if occasional development is required
Occasional development
- The production ABAP system is based on the master branch
- A temporary development ABAP system is set up
- All software components are imported
Step | System | Role | Task | Tool |
1 | DEV | Release manager | Provision a new development ABAP system | SAP Cloud Platform Cockpit |
2 | DEV | Release Manager | Create users, maintain and assign roles | Apps: manage musiness users/roles |
3 | DEV | Release manager | Import master branch of software component | Manage Software Component app |
4 | DEV | Developer | Develop features | Eclipse with ADT |
5 | DEV | Developer | Release all transport requests | Eclipse with ADT |
6 | DEV | Tester | Test new developments / fixes | Eclipse with ADT & custom SAP Fiori apps & external test tools Eclipse with ADT |
7 | If changes are required, repeat steps 3-5 | |||
8 | PRD | Release Manager | Pull the master branch into the PRD ABAP system | Manage Software Component app |
9 | DEV | Release Manager | Delete the development ABAP system | SAP Cloud Platform Cockpit |
Double Maintenance of Corrections into Development
For corrections, double maintenance is necessary so that everything that had to be fixed during release testing or usage can be retrofitted into the development ABAP system.
As there is no selective picking of transport requests to merge corrections back into the master branch, this is manual effort.
You can use the Compare Editor in ADT to merge corrections back to the master branch as shown in the following screen shot where the source code of a class is compared in two systems ITD and IHF.
The process would be as follows:
You can compare the latest version of an object in your ADT project in a hotfix ABAP system with the latest version of the same object in the development ABAP system. If there are new created objects, you have to create an object manually in the development ABAP system.
To make a comparison, from the context menu of the object in the Project Explorer or in the source code editor, choose Compare With à ABAP project, where ABAP project is one of the ABAP projects defined in your ADT.
Merging changes in the compare editor
Step | System(s) | Role | Task | Tool |
1 | COR | Developer |
Select the corrected objects in the transport request and open them. This can be done selectively object by object. |
Eclipse with ADT – Transport Organizer View |
2 | COR, DEV | Developer |
1. Select the resources in the Project Explorer in the correction ABAP system COR 2. From the resource’s pop-up menu, select Compare With 3. Select the ABAP project that points to your development ABAP system DEV |
Eclipse with ADT – Project Explorer |
3 | DEV | Developer | Merge the changes into the ABAP system DEV | Eclipse with ADT |
Information for Audit
The following information is relevant for the audit:
- Git repository: The creation of a Git repository branch creates a clone of the parent branch (including all development objects in the branch).
- During pull or checkout, the complete content of the Git repository is imported into the ABAP system. Transport requests cannot be imported selectively into subsequent ABAP systems. Together with the information which branch and commit ID was pulled into an ABAP system, you can reproduce which version of an object was in an ABAP system at which point in time.
- The content of the Git repository, with all its commits and objects, is not directly accessible to users of an ABAP system. Only SAP employees have access to it for support purposes because the information is typically not required for an audit. In exceptional cases, the content of the Git repository can be requested via a service request.
- In the Manage Software Component app and in ABAP development tools (ADT), the following information is available for a regular audit.
- Manage Software Component app:
- Action history of imports (pulls and branch checkouts), which also contains an execution log and a transport log per import. As these two logs are only saved temporarily in the ABAP system, it is recommended to save them to an excel if they are needed for error analysis or audit.
- Per branch, the information on the last commit (commit ID, commit message consisting of the transport request number and description, commit author and last commit timestamp)
- ADT
- In the Transport Organizer, you can find the transport requests together with the piece list
- In the Revision History, you can find the history of an object
- Manage Software Component app:
Automate the Software Lifecycle Management Process
To facilitate your software lifecycle management process, you can automate it by using communication scenario SAP_COM_0510. See Pulling Git Repositories to an SAP Business Technology ABAP environment.
Hi André,
thank you very much for this detailed Blog.
I think there is a little a error at the table under Use Case 1, Urgent Corrections. At step 3 you say 'Release the transport request. The changes are now in the master branch'. Should it not be 'Release the transport request. The changes are now in release branch YYYY-<nn>''?
Regards
André
Thanks for the hint. I fixed the typo.
Hi André,
thanks, this helps a lot.
Best regards, Thomas
Thanks for the detailed info Andre. I will take some time to consume it 🙂
Regarding the naming of the Software Component, we indent to set naming standards for these and it would be useful to validate the name and description fields. Is it possible to extend this app and build in this validation?
Regards
Ian