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.

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.

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:

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.

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.

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

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

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

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