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 system. Software component branches are provided remotely in a Git repository branch and checked out locally in such systems. In case of released APIs in the involved software components, API Snapshots are generated locally after release decisions in the quality assurance system and dowloaded for use in the development system..
Starting situation for Go Live
The Go Live process is characterized by creating different systems only when needed for the first time, however, you can provision the 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 Go Live
-
Development system DEV is based on the main branch
-
Quality Assurance system QAS and production 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
-
Software component relations are defined for dependencies between leading- and reuse software components in the YYYY-<nn> release
-
In case of released APIs: In the quality assurance system QAS, a check-relevant API snapshot named YYYY-<nn> was generated manually with all released APIs extracted as per the current release. Furthermore, the generated snapshot was downloaded from system QAS and uploaded to development system DEV. Finally the API snapshot was set to check-relevant in system DEV.
System QAS has always the same software state as the PRD system, unless a new change is tested and released. This means, transport requests are released in development ABAP systems only if development is completed and it is planned to import the changes to the production 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 |
At Go Live only: Create the software component and clone it initially |
Manage Software Components app |
|
If required, create a customizing transport request and tasks for the relevant business configuration expert(s). |
Export Customizing Transports app |
|||
|
1a |
DEV |
Developer |
Develop new functionality or a deferrable correction. All changes are collected in workbench transport requests. During development ATC checks are running and exemptions requested for false-positive findings (Requesting ATC Exemptions). Make sure to maintain new dependencies between software components in software component relations (Editing Software Component Relations). |
ABAP Development Tools for Eclipse |
|
1b |
DEV |
Business Configuration Expert |
Maintain business configuration. All changes are collected in customizing transport requests |
Maintain Business Configurations app |
|
2 |
DEV |
Quality Manager |
ABAP development tools for Eclipse: ATC Exemptions |
|
|
3 |
DEV |
Release Manager |
Release the transport request(s). During transport release ATC checks are running (Working with ATC During Transport Release). The changes are now in the main branch. |
ABAP Development Tools for Eclipse: Transport Organizer |
|
4 |
QAS |
Release Manager |
At Go Live: Pull software component(s) into system QAS. After Go Live: Check out main branch of software component(s) |
Manage Software Components app |
|
5 |
QAS |
Tester |
Test the change and report test result. During testing ATC checks are running, see Working with ATC During Development. |
ABAP development tools for Eclipse and custom SAP Fiori apps as well as external test tools, see Automate the Software Lifecycle Process External documentation tool |
|
|
|
|
If changes are required, repeat steps 1-4 |
|
|
6 |
QAS |
Release Manager |
Release decision: the changes are successfully tested and approved |
External documentation tool |
|
7 |
QAS |
Tester |
Test the change and report the test result. During testing ATC checks are running, see Working with ATC During Transport Release. |
ABAP development tools for Eclipse and custom SAP Fiori apps as well as external test tools. For more information, see Automate the Software Lifecycle Management Process External documentation tool |
|
8 |
QAS |
Release Manager |
Check out the new release branch YYYY-<nn+1> |
Manage Software Components app |
|
9 |
QAS/DEV |
Release Manager |
In case of Released APIs: Create and generate a new API snapshot YYYY-<nn+1> for the new release in system QAS. Set the new API snapshot as check-relevant so that it will be used as reference for API compatibility checks. Afterwards download the generated snapshot from system QAS and upload it to system DEV. Finally, set the snapshot as check-relevant in system DEV as well. |
|
|
10 |
DEV |
Release Manager |
Check out the new release branch YYYY<nn+1> for each software component (at Go Live: YYYY-01) into system PRD |
Manage Software Components |
- Development system DEV is based on the main branch
- Quality assurance system QAS and production 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
- In case of released APIs: In the quality assurance system QAS and development system DEV, a check-relevant API snapshot named YYYY-<nn> is generated with all released APIs extracted
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 system needs to check out the latest release branch instead of the main branch. That means all open transports in DEV need to be released first to save the work in progress to the main branch, so that feature development can be resumed later after the correction.
|
Step |
System |
Role |
Task |
Tool |
|---|---|---|---|---|
|
1 |
DEV |
Release Manager |
Check out the release branch YYYY-<nn> for each software component |
Manage Software Components app |
|
If required, create a customizing transport request and tasks for the relevant business configuration expert(s) |
Export Customizing Transports app |
|||
|
2 |
DEV |
Release Manager |
In case of Released APIs: Set API Snapshot created for the release YYYY-<nn> as check-relevant. For release YYYY-01 all API snapshots will be set to not check-relevant as no API snapshot is available for comparison. |
|
|
3a |
DEV |
Developer |
Fix existing functionality. All changes are collected in workbench transport requests. During Development ATC checks are running and exemptions requested for false-positive findings, see Requesting ATC Exemptions. |
|
|
3b |
DEV |
Business Configuration Expert |
Maintain business configuration. All changes are collected in customizing transport requests |
Custom Business Configurations app |
|
4 |
DEV |
Quality Manager |
ABAP Development Tools for Eclipse: ATC Exemptions |
|
|
5 |
DEV |
Release Manager |
Releases the transport requests. During transport release ATC checks) are running. |
ABAP Development Tools for Eclipse: Transport Organizer or Export Customizing Transports app |
|
6 |
QAS |
Release Manager |
Pull the software component(s) to get the correction into the already checked out release branch YYYY-<nn> |
Manage Software Components app |
|
7 |
QAS |
Tester |
Test the change and report the test result. During Testing ATC checks are running, see Working with ATC During Transport Release |
ABAP Development Tools for Eclipse and custom SAP Fiori apps as well as external test tools, see Automate the Software Lifecycle Management Process. External documentation tool |
|
|
|
|
If changes are required, repeat steps 2-7 |
|
|
8 |
QAS |
Release Manager |
Fix is successfully tested and approved |
External documentation tool |
|
9 |
PRD |
Release Manager |
Pull the software component(s) to get the correction into the already checked out release branch YYYY-<nn> |
Manage Software Components app |
|
10 |
DEV |
Release Manager |
Check out the main branch in system DEV for each software component |
Manage Software Components app |
|
11 |
DEV |
Release Manager |
In case of Released APIs: Set API Snapshot created for the latest release as check relevant. For release YYYY-01 all API snapshots shall be set to not check-relevant as no API snapshot is available for comparison. |
|
|
12 |
DEV |
Developer, Business Configuration Expert |
Perform the same changes as for the correction in the main branch and release them |
ABAP Development Tools for Eclipse Maintain Business Configurations app Export Customizing Transports app |