Skip to content

Integrate SAP Cloud Transport Management Into Your CI/CD Pipeline

Extend your CI/CD pipeline with SAP Cloud Transport Management service to add an enterprise-ready change and release management process and enable the transport of cloud-based applications on SAP Business Technology Platform (BTP) between several stages.


This procedure explains how to upload a multitarget application (MTA) from a CI/CD pipeline to Cloud Transport Management and then import it into its target environment.

Cloud Transport Management allows you to manage the transport of development artifacts and application-specific content between different SAP BTP accounts. It adds transparency to the audit trail of changes so that you get information about who performed which changes in your production accounts and when they did it. At the same time, Cloud Transport Management enables a separation of concerns: For example, a developer of an application or of SAP Cloud content artifacts can trigger the propagation of changes, while the resulting transport is handled by a central operations team. For more information, see SAP Cloud Transport Management.

The following graphic provides an overview about the interplay between continuous integration and Cloud Transport Management:

Interplay of CI and Cloud Transport Management



You can use this scenario to extend any CI process that meets the prerequisites, for example, the one described in Build and Deploy SAPUI5 or SAP Fiori Applications on SAP BTP with Jenkins.

The following graphic shows an example of the detailed procedure when combining continuous integration and Cloud Transport Management:

Detailed Procedure When Combining CI and Cloud Transport Management

The process flow contains the following steps:

  1. The CI server builds a MTA archive.
  2. The MTA is uploaded into the import queue of the target node, which is specified in the CI pipeline (in this example, PRE-PROD).
  3. Optionally, for transports in Cloud Foundry environment, MTA extension descriptors can be uploaded to the nodes in the transport landscape to provide node-specific import configurations. The MTA extension descriptor file must either be part of the repository, or be the result of the build process.
  4. The release manager manually triggers the import, or schedules it, which results in the physical deployment of the MTA archive into the corresponding subaccount (in this example, PRE-PROD). If an MTA extension descriptor was uploaded for this node, it will be used for the import.
  5. As soon as the import is executed, a transport is triggered along the defined transport route so that the MTA archive reaches the import queue of the next node (in this example, PROD).
  6. There, the physical import into the corresponding subaccount can be either triggered manually by the release manager or automatically by using the scheduling mechanisms of Cloud Transport Management.



If you use the pipeline of the following code snippet, you only have to configure it in the .pipeline/config.yml.

Following the convention for pipeline definitions, use a Jenkinsfile, which resides in the root directory of your development sources.

@Library('piper-lib-os') _

piperPipeline script:this

Configuration (.pipeline/config.yml)

This is a basic configuration example, which is also located in the sources of the project.

    credentialsId: tms-secret-key
    nodeName: PRE-PROD
    mtaPath: com.piper.example.tms.mtar
    customDescription: Custom-Transport-Description

# uploading MTA extension descriptors, optional step
    mtaVersion: 1.0.0
      PRE-PROD: 'scv_x_preprod.mtaext'
      PROD: 'scv_x_prod.mtaext'

    tmsUpload: true

Configuration for the Upload to Cloud Transport Management

Parameter Description
credentialsId Credentials that are used for the file and node uploads to Cloud Transport Management.
nodeName Defines the name of the node to which the *.mtar file is uploaded.
mtaPath Defines the path to the *.mtar file for the upload to Cloud Transport Management.
customDescription Optional: Description of a transport request. Overwrites the default (Default: Corresponding Git Commit-ID).
nodeExtDescriptorMapping Optional: Defines the mapping between a transport node and the MTA extension descriptor file that is used for the transport node. You specify the node name and the relative path to the MTA extension descriptor file using the syntax which is shown in the configuration example.
mtaVersion Optional: Defines the version of the MTA for which the MTA extension descriptor is used. You can use an asterisk (*) to accept any MTA version, or use a specific version compliant with SemVer 2.0, e.g. 1.0.0 (see If the parameter is not configured, an asterisk is used.


For a detailed description of the relevant parameters, see tmsUpload.