Skip to Content
Technical Articles

SAP Cloud Platform, ABAP Environment – Lifecycle Management – sample scenarios

Introduction

In the first blog post SAP Cloud Platform, 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 of SAP Cloud Platform.

The three scenarios that will be discussed adress the different needs one has depending on the complexity of development project.

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

 

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 Cloud Platform ABAP Environment System.

 

Related Information

See Software Component Lifecycle Management

3 Comments
You must be Logged on to comment or reply to a post.
  • 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é