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

 

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.

 

Related Information

See Software Component Lifecycle Management