Continous Integration / Continous Delivery (CI / CD) in der SAP Cloud Plattform

Was versteht man unter CI / CD und wozu ist dies nützlich?

Quelle: https://blog.itil.org/

Umsetzung von CI/CD für SAPUI5-Apps mit GitLab & GitLab Runner

Unsere Wahl für eine Versionsverwaltung für die SAP Cloud Platform ist hierbei auf GitLab gefallen, da bei diesem VCS (Version Control System) ein CI / CD-Tool in der Form des GitLab Runners nativ unterstützt wird. Damit wird die Einrichtung und Wartung vereinfacht. Die Serverinstanz für dieses Projekt (Cent OS 7 VM), den GitLab-Runner sowie einige weitere Tools, die für den Deployment- und Buildprozess notwendig sind, hostet GitLab. Dazu gehören unter anderem: NodeJS, NPM, Java, MTA Build Tool (SAP npm-Package), sowie die SAP Java Web SDK CLI-Tools.

Des Weiteren ist auf dem Server eine config-Datei hinterlegt, in der die Zugangsdaten für einen SAP Cloud Plattform P-User hinterlegt sind. Dadurch muss für den gesamten Deployment-Prozess nur ein einzelner User in einem Cloudaccount hinterlegt werden.

Der nötige Aufwand zur Nutzung der CI / CD-Tools für Entwickler begrenzt sich bei unserer Umsetzung lediglich auf die Funktionalitäten von Git. Die Buildpipeline wird automatisch durch ein commit & push ausgelöst. Dieser führt alle in dem Buildscript aufgeführten Befehle aus, wozu unter anderem das Deployment auf die SAP Cloud Plattform zählt. Der Workflow für Entwickler mit Git-Erfahrung ändert sich kaum, da die SAP WebIDE auch die Möglichkeit bietet, externe Git-Server zu nutzen. Dadurch entsteht maximale Flexibilität für Onlineentwicklung (Cloud WebIDE) sowie für lokale Entwicklungen.

Hinzukommend empfiehlt sich  die Arbeit mit Featurebranches, sowie mit „Systembranches“. Hierbei stellt ein Systembranch die Verbindung zu einem von drei Cloudaccounts dar, welche sich aus Entwicklungs-, Test- und Produktivaccount zusammensetzen.

Der Aufbau der Pipeline ist relativ simpel gestaltet. Im Optimalfall besitzt ein Projektrepository somit drei Systembranches, welche untereinander gemerged werden können. Dadurch ermöglicht man den „Transport“ von Entwicklungssystem in das Testsystem und letztendlich in das Produktivsystem.

Der Deployment-Prozess setzt sich zunächst aus fünf Schritten zusammen, wovon der Entwickler selbst nur einen Schritt vornehmen muss – das pushen auf einen Branch im Projektrepository, der Rest läuft automatisch im Hintergrund ab. Dadurch werden ihm viele vorher notwendige Schritte abgenommen.

Continous Integration / Continous Delivery (CI / CD) Deployement Prozess

Der gesamte Ablauf der Pipeline findet sich bei GitLab CI in einer einzigen Datei des Repositories wieder, der .gitlab-ci.yml .

Beispiel eines Buildscripts:

image: node:latest

stages:

  – init

  – build

before_script:

  – echo $env:CI_BUILD_REPO

  – echo $env:CI_BUILD_NAME

  – echo $env:CI_PIPELINE_ID

  – echo $env:CI_PIPELINE_IID

  – echo $env:CI_COMMIT_REF_SLUG

  – echo $env:CI_PROJECT_PATH

  – echo $env:CI_PROJECT_DIR

init-ci:

  stage: init

  script:

    – npm install –production

  artifacts:

    paths:

    – node_modules/

build-app:

   stage: build

   script:

    – date=“$(echo -e „$(date „+%H:%M:%S   %d-%m-%y“)“ | tr -d ‚[:space:]‘)“

    – echo $date

    – workspace=“$PWD“

    – echo $workspace

    – cd „$workspace“

    – mtaName=“build“-$date

    – echo $mtaName

    – ls

    – sed -ie „s/${timestamp}/`date +%d%m%y-%H%M%S`/g“ mta.yaml

    – mkdir dist

    – cp -v neo-app.json $workspace/dist

    – cp -v -r $workspace/webapp $workspace/dist/webapp

    – mbt build -p=neo –mtar=${mtaName}.mtar -t=${workspace}

    – cd /home/gitlab-runner/config

    – cred=$(cat clouduser.in)

    – IFS=‘;‘ read -ra cred_a <<< „$cred“

    – userName=${cred_a[0]}

    – userPass=${cred_a[1]}

    – cd „$workspace“

    – /home/gitlab-runner/tools/neotools/tools/neo.sh deploy-mta –user „$userName“ –host „hana.ondemand.com“ –source ${mtaName}.mtar –account „<technischer Accountname>“ –password „$userPass“ –synchronous

   artifacts:

    paths:

    – build/

Die einzelnen Schritte

• Zunächst werden die Stages des Scripts definiert. In diesem Fall sind es zwei Stages: init & build. Die init-Stage ist sehr simpel gehalten und installiert hierbei lediglich die benötigten nodeJS Module, falls diese im Projekt vorhanden sind. Damit dieser Schritt fehlerfrei funktioniert, ist das Vorhandensein einer package.json notwendig.

• Des Weiteren werden sogenannte MTA-Descriptoren benötigt (mta.yaml & ui5.yaml). Diese werden von dem SAP MTA-Build Tool benutzt, um Metainformationen in die erstellte .mtar zu schreiben, die später auf die SAP Cloud Plattform deployt wird. Der Aufruf des MTA-Build Tools findet sich unter dem Abschnitt build-app in dem Buildscript. Diesem wird ebenfalls ein Buildtarget mitgegeben, welches in diesem Fall „NEO“ ist.
• Der letzte Schritt des Scripts ruft die SAP Neo CLI Tools auf, um das erstellte MTA-Archiv in die SAP Cloud Plattform zu deployen.

Zusammenfassung CI / CD in der SAP Cloud Plattform

Abschließend lässt sich sagen, dass eine Buidlpipeline mit GitLab und dem GitLab Runner einfach zu konfigurieren ist und mit minimalem Aufwand den Entwicklungsalltag in der SAP Cloud Platform immens beschleunigt. Hinzukommend lassen sich Unit- und Integrationtests in das Buildscript einbinden, um fehlerfreie Software zu gewährleisten.
Als ein weiterer großer Vorteil lässt sich anmerken, dass nur noch ein einziger Deploymentuser in den SAP Cloud Accounts von Kunden benötigt wird. Somit wird weiterer administrativer Aufwand gespart.

Continous Integration / Continous Delivery (CI / CD) in der SAP Cloud Plattform