## 4. Configure Jenkins Instance
As a Jenkins administrator, you need to add technical Git user credentials and platform user credentials to the integrated secure store. Make sure that a shared library piper-lib-os is configured pointing to the project "Piper" library. See Piper Library .
For more information on how to configure the ABAP environment steps and stages, see Configuration .
## Transport from DEV to TST System via gCTS
<!-- image -->
Development system DEV and test system TST stay on the same main branch. To make the latest implementations available in the test system, the developed software components can be imported on a regular basis to test system TST and tested using the ABAP Test Cockpit by scheduling a planned execution of the ABAP environment pipeline. See Continuous Testing on SAP BTP ABAP Environment and Running ATC Checks and ABAP Unit Tests on a Static ABAP Environment System .
The ABAP environment pipeline is executed in a Jenkins server that is connected to subaccount 02 Test in the global account for development by authenticating via a technical Cloud Foundry platform user. The permanent test system TST is used to import software components and run ABAP Test Cockpit checks.
## Build Add-On Version
The ABAP environment pipeline can automate the build and assembly process of ABAP add-ons. From creating the delivery packages in the assembly system to publishing the add-on release, all steps are part of this pipeline.
This scenario can be run in the Landscape Portal using the Build Product Version app, or it can be configured manually and run on a local Jenkins server. In both cases, the same pipeline stages will be executed.
See Build and Publish Add-on Products on SAP BTP ABAP Environment .
<!-- image -->
- https:/ /www.project-piper.io/pipelines/abapEnvironment/stages/initialChecks/ [https:/ /www.projectpiper.io/pipelines/abapEnvironment/stages/initialChecks/]
- https:/ /www.project-piper.io/pipelines/abapEnvironment/stages/prepareSystem/ [https:/ / www.project-piper.io/pipelines/abapEnvironment/stages/prepareSystem/]
- https:/ /www.project-piper.io/pipelines/abapEnvironment/stages/cloneRepositories/ [https:/ / www.project-piper.io/pipelines/abapEnvironment/stages/cloneRepositories/]
- https:/ /www.project-piper.io/pipelines/abapEnvironment/stages/ATC/ [https:/ /www.project-piper.io/ pipelines/abapEnvironment/stages/ATC/]
- https:/ /www.project-piper.io/pipelines/abapEnvironment/stages/build/ [https:/ /www.project-piper.io/ pipelines/abapEnvironment/stages/build/]
- https:/ /www.project-piper.io/pipelines/abapEnvironment/stages/integrationTest/ [https:/ / www.project-piper.io/pipelines/abapEnvironment/stages/integrationTest/]
- https:/ /www.project-piper.io/pipelines/abapEnvironment/stages/confirm/ [https:/ /www.projectpiper.io/pipelines/abapEnvironment/stages/confirm/]
- https:/ /www.project-piper.io/pipelines/abapEnvironment/stages/publish/ [https:/ /www.projectpiper.io/pipelines/abapEnvironment/stages/publish/]
The ABAP environment pipeline is executed in a Jenkins server that is connected to subaccount 03 Build/ Assemble and 04 Build/Test in the global account for development by authenticating via a technical Cloud Foundry platform user. Transient systems are then provisioned for add-on assembly (BLD) and installation tests (ATI).
## Add-On Assembly System
Add-on assembly system BLD includes an instance of communication scenario SAP\_COM\_0948 and an instance of communication scenario SAP\_COM\_0582 . See SAP\_COM\_0948 and Software Assembly Integration (SAP\_COM\_0582) [page 846]. Service keys with parameters referring to the communication scenarios are created in the BLD system, which leads to the creation of communication arrangements that can be used by the pipeline for inbound communication.
In the Prepare System pipeline stage, a new transient system BLD is provisioned for the add-on assembly. See Prepare System . ABAP Test Cockpit checks, software component imports, and the local build of deliveries are performed in this stage. By default, the system is deleted again in the Post pipeline stage. See Post .
The communication with remote components is enabled via communication scenario SAP\_COM\_0948 and communication scenario Software Assembly Integration (SAP COM 0582).
By default, the system is created from scratch for each new add-on version. You can choose to reuse a permanent BLD system instead of provisioning a new one each time. This has the advantage of reducing the pipeline execution time, as system provisioning is one of the most time-consuming tasks. See Build Add-Ons on a Permanent ABAP Environment System .
To reduce costs, it is recommended that you shut down the permanent system when no builds are scheduled. See Manage System Hibernation. Please note that hibernated systems still incur costs.
You can decide in detail whether to use a permanent or transient assembly system based on following criteria:
|         | Transient Assembly System                                                                                                                                                                                                                                                                                                                                                                                                                                   | Permanent Assembly System                                                                                                                                                                                                                                                                                                                                                              |
|---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Pros    | • API Snapshots are automatically created locally and remain in the system for continuous API com- patibility checks • If additional dependencies to ob- jects outside the modeled product exist, they will be transparent as import errors                                                                                                                                                                                                                 | • API Snapshots are automatically created locally and remain in the system for continuous API com- patibility checks • Reduced time consumed for add- on build as no new assembly sys- tem needs to be provisioned • Local history of ABAP objects, transport piece lists, deliveries, transport logs etc. remains availa- ble in the system for trouble shoot- ing and error analysis |
| Contras | • API Snapshots are only created lo- cally and thus are deleted once a system is deprovisioned → API compatibility checks cannot be used • A new assembly system needs to be provisioned for each new add- on build, software components need to be cloned from scratch - resulting in longer runtime • Local history of ABAP objects, transport piece lists, deliveries, transport logs etc. is not available after the assembly system is de- provisioned | • Import errors during gCTS opera- tions must be resolved to always guarantee the software component state in the system to be consis- tent with the remote repository • Dependencies to objects outside the modeled product might exist, so there is no guarantee to reveal unwanted dependencies                                                                                     |
##  Note
In case of dependencies between software components that are facilitated trough the creation of released APIs, it is recommended to use a permanent assembly system. Only then the API compatibility checks can function properly based on the API snapshots that are required to remain in the system. See Released APIs and API Snapshots.
##  Tip
You may reuse existing permanent test systems like TST or quality assurance system QAS as alternative for the assembly system BLD. If you choose to do so, make sure that there are no ongoing activities like software component lifecycle actions. See System Landscape/Account Model.
In such a case also the manual creation of API snapshots in those systems becomes obsolete as the add-on build pipeline will automatically create such snapshots and set them as check-relevant. See Released APIs and API Snapshots.
## Add-on Installation Test System
To verify that the delivery packages included in the add-on product version are installable, a target vector is published in "test" scope during the Build stage.
In the Integration Tests pipeline stage, a new transient system ATI is then provisioned for an add-on deployment test that installs the add-on product version. See Integration Tests . After the successful add-on installation is confirmed, the system is deleted, unless otherwise specified.
For generation and syntax check, please take a look at communication scenario Software Assembly Integration (SAP\_COM 0582).
By default the ATI system is not created from scratch for each new add-on version. If you configure your pipeline manually, you can choose not to dismantle the ATI system automatically after the import test. This is intended to be able to analyze issues in this system in case they cannot be solved by the pipeline log output. Do not forget to delete the system manually prior to the next implementation of the pipeline. Otherwise it is reused. Reusing the system would save runtime as no new system would need to be provisioned but not all issues which should be detected by this installation test would be detectable anymore.
## Add-on Assembly Kit as a Service
The Add-on Assembly Kit as a Service (AAKaaS) is used for registering and publishing the software product.
The service is offered in the SAP Service and Support systems, which means that access is granted via a technical communication user that packs the delivery into an importable package format. It is similar to the Software Delivery Assembler (SDA, transaction SSDA) as a part of the SAP Add-On Assembly Kit. See SAP Add-On Assembly Kit and Add-On Assembly Kit as a Service .
## Add-on Consumption
For the consumption of the add-on as a SaaS solution, software components are installed via add-on delivery packages into multitenancy-enabled production systems (AMT) provisioned via the ABAP Solution service. This is orchestrated via a multi-tenant application deployed to the Cloud Foundry environment on SAP BTP. See Multitenant Application and Deploy.
##  Note
If you need support or experience issues during the add-on build, see Troubleshooting .