cTMS Adaptor Enables Focused Build Transport Request Deployment via GitLab

[laszlo_kajan2]

tl;dr

• Custom implementation of cTMS API for GitLab


• Under the control of SolMan Focused Build, performs GitLab actions to execute release and deployment to QAS and PRD

Problem statement

Focused Build provides satisfactory management of the application lifecycle in terms of auditability. To that end, its technical coupling with the cloud Transport Management Service (cTMS) allows it to conduct and monitor transport requests.

Commonly, a multi-target application resides in a git mono-repo. Assuming a 4-tier landscape - DEV, TST, QAS, PRD - pre-release development is performed by DEV-TST-DEV-TST cycles aided by a DevOps lifecycle tool such as GitLab.

Pre-release development is not captured in SolMan Focused Build. QAS and PRD deployment is not captured in the DevOps lifecycle tool. While auditors don't generally care about pre-release development, developers want to be able to tell what is deployed to QAS and PRD using their DevOps lifecycle tool instead of Focused Build. They may also want to exercise precise control over the deployment process, instead of using the relatively limited features of the cTMS.

Background

Abbreviations

cTMS	cloud Transport Management Service
LCG	Logical Component Group

Branch model

Branch Model

 

In this post we focus on the 'Quality' and 'Production' environments.

We release to 'Quality' (QAS) by creating a 'quality-x.y.z' branch, which triggers a GitLab build pipeline that deploys to 'Quality'. We deploy the resulting release to 'Production' (PRD) by merging the 'quality-x.y.z' branch to 'production' (see .gitlab-ci-btp-flow.yml).

Cloud Transport Management API

SolMan Focused Build communicates with the cTMS via the public Cloud Transport Management API.

Solution

API

Since SolMan Focused Build controls the cTMS via its API,  respective API actions can be mapped to GitLab actions by a suitable adaptor. This allows SolMan to control the release and deployment process via GitLab, much as it would via the cTMS. At the same time, complete control over the steps of the deployment may be exercised by controlling the GitLab pipeline that performs the actual deployment (for example .gitlab-ci-btp-flow.yml).

The following elements of the cTMS API need to be implemented by the adaptor:

• GET /versions


• GET /v2/actions/:jobId(\d+)


• GET /v2/nodes


• GET /v2/nodes/:nodeId(\d+)/transportRequests


• POST /v2/nodes/:nodeId(\d+)/transportRequests/import


• GET /v2/nodes/:nodeId(\d+)/transportRequests/:trId(\d+)/logs


• GET /v2/routes

In the following we show how the adaptor can be implemented.

Connectivity

SolMan reaches the cTMS adaptor via two RFCs that are configured for each external service of the components of the respective logical component group (LCG):

• 'Cloud TMS Authentication RFC' attribute: 'SCP_TMS_Authentication' RFC
  
  
  
  • Configure it like for the cTMS
  
  
  
  


• 'Cloud TMS REST API RFC' attribute: 'SCP_TMS_REST_API' RFC
  
  
  
  • Point it at cTMS adaptor host
  
  
  
  

Limitations

For the sake of simplicity, in this proof-of-concept we allow for only one transport request per import action. This limitation, along with the need to search through a set of GitLab projects (as seen in the code of the implementation), can easily be lifted by adding persistence to the adaptor.

This implementation does not authenticate API requests. This can be added by examining the access token of the incoming HTTP request.

Application

Source code

You can find the source code of the GitLab cTMS adaptor in GitHub repository laszloKajan / devops-gitlab-tms.

The application consists of one MTA module of type 'nodejs'.

Environment variables

The following environment variables are expected by the application:

• GITLAB_ACCESS_API
  
  
  
  • GitLab API access token, used to request information from GitLab
  
  
  
  


• GITLAB_HOST
  
  
  
  • E.g. 'code.acme.com'
  
  
  
  


• GITLAB_PROJECTS
  
  
  
  • JSON array of GitLab projects that are handled by the adaptor, e.g. '[4396]'
  
  
  
  

How to use?

1. Take a commit in GitLab that is ready to be released to QAS and PRD.


2. Tag the commit as a 'release candidate' using the semantic versioning pattern 'x.y.z-rc.n'.
   
   
   
   • This causes the tag to show up as a transport request in the list of transports that can be assigned to a Work Item.
   
   
   
   


3. In Focused Build, assign the transport request that represents the tagged commit to the corresponding Work Item.


4. Advance the Work Item to 'Handed Over to Release' status.


5. Advance the 'Release' to 'Deploy' status.


6. Use the 'Schedule Import Job for Transport Requests' in the QAS section of the Task List to import to QAS.


7. Use the 'Schedule Import Job for Transport Requests' in the PRD section of the Task List to import to PRD.

Discussion

By the time the 'release candidate' is tagged, it has already been deployed to the DEV and TST environments. Therefore the adaptor does not implement any action for Work Item status changes involving these environments. It simply reports an immediate success to SolMan.

Author and motivation

Laszlo Kajan is a full stack Fiori/SAPUI5 expert, present on the SAPUI5 field since 2015, diversifying into the area of BTP (formerly SCP) development.

The motivation behind this blog post is to provide an example of a solution for using GitLab to deploy MTA build artefacts, in the context of SolMan Focused Build-managed cloud application development.

References

• GitHub
  
  
  
  • .gitlab-ci-btp-flow.yml
  
  
  • devops-gitlab-tms
  
  
  
  


• SCN
  
  
  
  • GitLab MTA Build Pipeline with Focused Build and SCP TMS Integration
  
  
  
  

Credits

• I would like to thank all my colleagues, and especially Vijaya Kumar Natra, Christian Daenner and Przemyslaw Lewkowicz, for the part they played in making this implementation possible.