SAP DevOps Using gCTS, GitHub and Jenkins
As Everyone is talking about DevOps and SAP also come up with the DevOps with SAP, lets understand more about DevOps is SAP world.
In this Blog post I will explain about DevOps toolset used in SAP and what are the configuration requirements for this.
DevOps is not a methodology nor a framework. It is a culture, a movement, and a philosophy built on the CALMS principles of culture, automation, lean, measurement, and sharing. The willingness to break down silos, such as project planning, development, and operations, is key for the collaboration.
DevOps is built on the foundation of agile processes, continuous delivery, automation, and much more to help development and operations teams be more efficient, innovate faster, and deliver higher value to businesses and customers.
The basic idea is that source objects created in an ABAP development environment can be handled in Git.
It enables you to store ABAP source objects, to keep their versions in a Git repository, and thus to create one source of truth for any kind of sources. The idea is that objects can be transferred to a Git repository and taken back to an environment where they are needed. This could be (another) development environment but also a test or production environment.
The process of moving artifacts from one system to another will work like shown in the following figure:
Any type of ABAP objects shall be enabled to be stored in a Git repository. Whenever objects are changed in a development system, the standard CTS records them in so-called “tasks”. We will leverage these tasks to offer the possibility to transfer and commit these objects to a local repository. From there, these commits are pushed to a remote repository. The objects in the remote repository can then be transferred into the local repository on any target system and from there be imported into ABAP again. Internally the well-known transport tools are used to leverage fast import, automatic object activation and execution of after-import methods.
Which systems do I need, what to install on these systems?
- Git platform – To host your repositories
- Can be e.g. GitHub, GitLab, CodeBucket, AWS Code Commit
- ABAP systems – e.g. development, test, and production system
- SAP S/4HANA 1909 (2020 for customizing support)
- SapMachine Version 11 or comparable JRE
- Some SAP Notes (depending on SP)
- CI server – To host your pipelines (Optional)
- you can use pipeline steps provided in project ”Piper”
There are few prerequisites which explained below, please make sure it has been taken care before you start.
ABAP users who perform configuration tasks as well as developer users that use gCTS require the permissions from the following authorization objects for gCTS tasks.
The authorizations are part of the delivered role SAP_BC_GCTS_ADMIN. Note that you shouldn’t assign the role directly, but instead assign a copy of the role to the users
2.Operating System: –
- The Git client abap2vcs.jar is written in Java. In a standard ABAP system installation, it’s part of the standard SAP Kernel. To run the Git client, a Java runtime is required, which isn’t automatically installed with the standard SAP Kernel. You must install it manually. A Java runtime version of at least 1.8 is required.
- gCTS requires a working directory called gcts on the operation system. You must create this working directory, for example, in the following location: /usr/sap/<SID>/D00/gcts
Note:- The working directory serves as the local Git repository of your ABAP system. If you use multiple application server instances, the directory must be on a shared directory to avoid inconsistencies and data loss. To share directories between application server instances, you can use Network File System (NFS), or Server Message Block (SMB), for example. A separate share is required for every individual ABAP system in your landscape.
- You have opened ports 22 and 443 for outgoing communication.
- Port 22 is required for SSH communication between the Git client on the operating system of the ABAP server and the remote repository on the Git server.
- Port 443 is required for the secure communication (HTTPS) between the ABAP runtime and the remote repository on the Git server.
3.Prepare ABAP Systems for Repositories
gCTS requires a virtual non-ABAP system on each ABAP development system. If your ABAP development system isn’t a domain controller, you must prepare your ABAP systems for usage with gCTS by manually creating the non-ABAP system, and a transport layer as well as a transport route to the non-ABAP system.
- Go to the transport domain controller of the system in which you want to use gCTS, and start transaction STMS.
- Choose System Overview, and create a non-ABAP system.
- Enter a three-character system ID (SID) for the non-ABAP system, which doesn’t yet exist in the TMS configuration and Enter a description. You can leave the default entry unchanged.
- In the TMS Configuration for this non-ABAP system that you just created, on the Transport Tool tab, set the parameter NON_ABAP_SYSTEM to the value VCS.
By setting this parameter, you classify the system as a non-ABAP system of type VCS (version control system).
Create a transport layer
- In transaction STMS, choose Transport Routes.
- In the Transport Routes Editor, go to change mode and choose Edit Transport Layer Create.
- Enter a four-character transport layer ID, and a short description.
- For the transport layer, you can use any four-character ID starting with Z. We recommend that you use the following naming convention: Z<SID of the non-ABAP system>
After APP IMPLEMENTATION, you will be able to see gCTS app in SAP Fiori Launchpad.
- Open the URL and select Git- Enable CTS app.
- Go to Configuration tab add below parameters by clicking on + icon
VCS_PATH à gCTS requires a working directory to store files in local repositories in the file system of the application server. Enter The Path to the working directory of gCTS. The path Must end with gCTS. Example: /usr/sap/<SID>/D00/gcts
A2G_RUNTIMEà The Git client (Java executable: abap2vcs.jar) is delivered as part of the SAP Kernel and is available in the executable directory on the file system of the application server. Enter the path to the Git client. The path must exist and end with abap2vcs.jar Example: /usr/sap/<SID>/SYS/exe/run/abap2vcs.jar
JAVA_RUNTIMEà gCTS requires a Java runtime on the file system of the application server to run the Git client. Enter the path to the Java executable of the Java runtime. For ABAP systems on Unix platforms, the path must end with java. For ABAP systems on Windows platforms, the path must end with java.exe. Example: /usr/sap/<SID>/SYS/exe/run/jre/bin/java
- After adding parameters, go to repositories tab and create a repository for gCTS.
- Repository IDà Give Repository ID, Here I use HCL-DevOps-V1
- Name à give a Name to Repository, you can give same as repository id.
- Role à Role of the repository Possible values: Development | Provided Development is the default value.Use Development for repositories for source (development) systems. These are repositories into which you want to transfer ABAP development objects (push commits). Use Provided for repositories for target systems. These are repositories from where you want to retrieve ABAP objects (pull commits).
- Type à Type of the repository, Possible values: Git | GitHub , Github is the default value.
- URL à URL to the remote Git repository on the Git server.
- vSID à Three-character system ID of a virtual non-ABAP system required for gCTS.
- Visibility à Specifies the visibility of the repository on the ABAP system, Possible values: Public | Private
After providing all details save it.
Now Repository is created but it is not cloned yet, we need to click on clone Repository option in right hand side and clone new created repository.
By cloning the remote repository to the ABAP system, you make the content of the remote repository accessible for your ABAP system by importing the content of the repository to the ABAP system.
If the cloning is successful, the system displays a success message.
- The status of the repository changes from CREATED to READY.
- The value of the current commit is updated to the newest commit of the remote repository.
- The Clone Repository button is inactive.
- A new directory with the repository name is created under the gcts working directory on the file system of the application server.
Once repository is cloned, the status will change from created to READY. Now we are ready to use Git-Enabled- CTS for Development system.
create a repository on github with README.md file and then add Jenkinsfile for Jenkins pipeline.
We have used project piper for CD/CI scenario. For the connectivity with Jenkins, we must have Jenkinsfile created in github repository, you can use config.yml in github to define values of step parameter.
Steps for gCTS in project “Piper”
Jenkins integration with gCTS
Cx Server is a life-cycle management tool to bootstrap a pre-configured Jenkins instance within minutes. All required plugins and shared libraries are included automatically. It is based on Docker images provided by project “Piper”.
Once your Jenkins server is ready to use, follow below steps.
- To create a pipeline, Click on New Item in left hand side
- Select Pipeline, we are using single pipeline for our use case that’s why we use pipeline, if you want multiple branch then use multibranch pipeline, as per your requirement.
- Select Pipeline script from SCM in Definition and SCM select Git and give repository URL which is connected to gCTS.
- Mention branch in Pipeline tab as per your requirement. We are using single branch as Master.
- Pipeline is ready to use now, for auto build we need to enable GitHub hook trigger in General tab of pipeline.
- Now go to github repository in github portal which you are using in jenkins pipeline.
Repository >>settings >>webhooks
- Enter URL of Jenkins with ‘github-webhook’ and content type, select Just the push event in trigger.
The basic flow for continuous integration could look like this
- The developer writes code.
- You will use the known editors.
- The developer pushes the code changes into a repository.
- By transferring objects in (open) tasks to Git.
- CI server monitors the repository.
- CI server creates a new build:
- gCTS determines changed objects since last deployment and creates a R3trans data file.
- This can be done for an existing target system, a new clean one or, a special system that has been set up for developing a certain feature. The build result depends on current state of the target system.
- CI server deploys the build to the runtime system:
- The previously created R3trans data file is now deployed into the target system.
- CI server tests build on the runtime system.
- CI server sends feedback to the developer.
Use Case for successful ABAPUnitTest scenario
Below is the program which will be pushed through gCTS and pipeline will be auto trigger once change is received in git repository.
Go to Git-Enabled CTS, In Object tab, select + icon and enter package name as shown in below screenshot.
Select Push and Click on OK, changes will be pushed and shown in Commits tab.
Once Changes will be there in Commits tab, pipeline will be auto trigger in Jenkins.
Use Case for Failed ABAPUnitTest scenario and Rollback
In Below Use case Unit Test will be failed for the changes moved form Dev to QA then changes will be rolled back from QA.
After Deploy the changes in QA, Unit test is failed, and we can see Logs below.
Rollback script is being triggered after unit test failed, it is rolling back all changes to previous active commit.
So here, Pipeline finished with Failure status.
What you have learned from this blog post.
- What is SAP DevOps and how it works.
- What tools sets you required for setup.
- How to configure gCTS
- How to push data from gCTS
- How to integrate jenkins and github with gCTS.
Thanks for reading this blog post , I hope you find it useful.!!
Referred Links:- how to create pipeline with project-piper.