Skip to Content
Technical Articles
Author's profile photo Taranamjit Kaur Dhindsa

Step towards CI and CD Set up in S/4HANA System

In my previous blog posts, I covered gCTS Set up for Source and Target System  and we laid the stepping stones for our CI and CD Set up. In this blog post I will be covering our journey while trying out CI and CD Set Up as a PoC for customer using SAP predelivered pipelines in Project Piper. For fast deployment, we went ahead with SAP preconfigured pipelines whereas you can create your own Pipelines too but that will require writing logic yourself.

Prerequisites

  1. Git Platform
  2. S/4HANA 2020 Systems Dev->Q->Pre prod->Prod
  3. Linux system; install docker and pull docker image of cx-server. Execute cx-server command  ./cx-server start. This will install Jenkins and configures Piper OS Libraries

For our PoC, we tried Windows 16 server before falling back to Linux as we landed into issues in installing Docker on Windows 16 server and then there is not much of documentation around it. SAP documentation also states that you may land into issues with Windows 16 server.

Once the installations were done ;we followed the configurations listed here; for configuring the pipelines . As of today, only 5 below listed Pipelines are provided by SAP for On Premise system

 Once the Pipelines were configured; you can automate them to trigger as and when Commit happens. All these pipelines are triggered after the change has been committed to Git from the Development system.

We only faced one issue with gctsDeploy pipeline; we were getting dump in S/4HANA system as we didn’t pass the parameters rightly in config.yaml as per Piper . We were passing commit and scope  with the values as given in link

commit: ‘commit’

scope   : ‘scope’

And we were getting below dump :

We removed both the above-mentioned parameters from our config.yaml file and the pipeline worked as expected. Commit and Scope if required to be passed should have :

commit – The commit to which the repository must be set after the creation and clone of the repository. Its value and should be a commit id already existing in the remote repository. This can be left empty if no change of commit is required.
scope – Scope of the deploy. The default is the entire commit would be imported into the system. Leaving the scope empty would follow the default behavior.

Below listed limitations are observed while using SAP preconfigured Pipelines for :

  1. Merge: Currently we don’t have any pipeline for Merge; so Merge need to be done manually for pushing the changes to Prod.
  2. Commit: By default, Commit to Git Repository is performed when Transport request is released in Dev system; but you can also create a commit in Git when task is released. Refer here
  3. ATC: ATC is not supported for On Premise currently in SAP predelivered pipelines. Although you can use ABAP CI Plugin for executing ATC but that executes ATC over packages and not Transport request .

Good start to CI and CD framework in S/4HANA where customers are now evaluating its benefits wrt their landscape ; looking forward to more features in CI and CD framework in coming days. I will share the use cases that we implemented and the challenges we faced in upcoming Blog posts.

 

Regards
Taranam

Assigned Tags

      3 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Lars Hvam
      Lars Hvam

      Hi,

      In a CI setup, the developer commits often to trigger the pipeline(?), and the code might not be finished.

      As a consequence of this, I assume there will be no manual testing in the Q system?

      Also if the unit tests fail in Q, the code will be rolled back? Ie. the developer cannot investigate the root cause.

      Author's profile photo Taranamjit Kaur Dhindsa
      Taranamjit Kaur Dhindsa
      Blog Post Author

      Hi Lars

      Yes if unit test fails in Q the rollback happens if my pipeline is having ABAPUnit running in Q . But it all depends on the landscape of customer and where you fit in GitHub and pipelines . We cannot apply one rule to all Customers as landscape varies .
      If I am having Test data in DEV environment - I can run ABAP Unit pipeline in DEV and then perform deploy in Q .

      At end every process implemented will have its own Pros and cons and as a customer
      we need to weigh the  requirement and take decision ... Like Obviously if I have
      simple 3 tier landscape using CTS I will not change it to bring in gCTS . But I am evaluating where i
      have 2 Dev boxes currently and 2 QA if I can simplify it .

      Author's profile photo dinesh k
      dinesh k

      Good one