UI5-App-Deployments mit GitHub Actions automatisieren

Entwicklerinnen und Entwickler sind von der schieren Menge verfügbarer Werkzeuge manchmal überfordert und greifen deshalb zu denen, die für sie am besten funktionieren. Wenn es Ihnen wie unserem Team geht, bevorzugen Sie vielleicht VSCode gegenüber der WebIDE (für sprachübergreifende Entwicklung funktioniert es schlicht besser). Und vielleicht möchten Sie auch für Ihre UI5-Entwicklung bei GitHub bleiben, genau wie Sie es für ReactJS, NodeJS oder andere Frameworks tun.

Was machen Sie dann mit den Deployments? Wie bauen, deployen und testen Sie Ihre UI5-Anwendungen (OpenUI5/SAPUI5) unkompliziert ohne die eingebauten WebIDE-Funktionen?

Dieser Beitrag baut auf den Erkenntnissen aus unserer UI5Con2021-Session "Automate UI5 App Deployments with GitHub" auf und liefert eine Schritt-für-Schritt-Anleitung, wie Sie mit GitHub Actions eine effiziente CI/CD-Pipeline für Ihre UI5-Apps aufsetzen und nutzen.

TLDR: Wir verwenden eine eigene GitHub Action namens ui5-deploy, um unser Setup für das automatische Bauen und Deployen von Code in die SAP BTP Neo Umgebung zu vereinfachen und zu beschleunigen. Die offizielle Referenzdokumentation finden Sie unter https://github.com/marketplace/actions/ui5-deploy

UI5Con-Session:

Ansehen: UI5-App-Deployments mit GitHub automatisieren

"Build" und "Deploy" bei UI5-Apps

Damit ein Deployment einer Anwendung überhaupt stattfinden kann, ist der build notwendig. Der Build ist der Prozess, in dem Software kompiliert und in eine Form gepackt wird, die für Deployment, Installation oder Release ideal ist. Sehen wir uns Build und Deployment etwas genauer an.

Build der Anwendung

Der Build ist einer der ganz wesentlichen Schritte bei der Entwicklung jeder produktiven Anwendung. In UI5-Anwendungen wird während der Entwicklung üblicherweise der Ordner webapp verwendet, während für das Laden im Browser im produktiven Einsatz der Ordner dist genutzt wird. Der Prozess, der aus dem Ordner webapp den Ordner dist erzeugt, heißt Build.

Ein Build-Prozess kann mehrere Schritte umfassen, zum Beispiel:

• Minimieren des Codes für bessere Performance (component-preload.js)
• Transpilieren von modernem JS nach Vanilla JS
• Erzeugen von CSS-Dateien aus LESS- und SASS-Dateien
• Bündeln von Ressourcendateien und vieles mehr

Deployment der Anwendung

Sobald aus dem Build-Prozess ein produktiver dist-Ordner vorliegt, besteht der nächste Schritt darin, diese Änderungen in der Cloud zu deployen, damit Endanwender Ihre Anwendung über eine URL erreichen können.

Für jemanden mit Hintergrund in anderen JS-Frameworks mögen diese Konzepte sehr grundlegend klingen. Wer allerdings lange Zeit ausschließlich mit UI5 gearbeitet hat, findet sie möglicherweise verwirrend und überflüssig. Der Grund: In der Praxis müssen sich Entwickler darum nicht kümmern. Meist handelt es sich um einmalige Einrichtungen durch erfahrene Entwickler oder Architekten. Außerdem bietet SAP mit WebIDE und Business Application Studio einen einfacheren Weg an.

Warum überhaupt automatisierte Deployments?

Wie beschrieben stellt SAP mehrere GUI-basierte Lösungen bereit, um UI5-Anwendungen zu deployen. Wozu also das Deployment automatisieren? Wie hilft das der Produktivität? Hier einige Vorteile aus unserer Erfahrung:

1. Zentrales Deployment

Das Deployment ist einer der letzten Schritte, bevor eine Anwendung für Endanwender verfügbar wird. Ein zentrales Deployment hilft nicht nur dabei, alle Deployments besser nachzuvollziehen, es verringert auch die Wahrscheinlichkeit, dass ein Entwickler einen fehlerhaften Build deployt.

2. Regelmäßige Deployments

Ein automatisiertes Setup ohne Deployment-Overhead für neue Builds ermutigt das Entwicklungsteam zu häufigen Deployments, besonders in der DEV-Umgebung. Dieses feature- oder Git-Commit-bezogene Deployment hilft anderen Teammitgliedern dabei, mögliche Probleme früh zu erkennen, und hält alle auf dem aktuellen Stand.

3. Automatisierte Qualitätsprüfungen | Integrierte statische Codeanalyse

Statische Codeprüfungen wie ESLint verhindern, dass die Anwendung an typischen JS-Fehlern scheitert. Indem diese Prüfungen automatisch vor jedem Build laufen, kombiniert mit weiteren nützlichen GitHub Actions, können wir sicher sein, dass der Code vor jedem Deploy zwingend unser Quality Gate passiert hat.

4. GitHub Secrets für zentralen Zugriff

Da die Deployments zentral über unsere CI/CD-Pipeline laufen, entstehen keine Engpässe durch SAP-BTP-Berechtigungen oder die Notwendigkeit, Zugangsdaten mit einzelnen Entwicklern zu teilen. Mit GitHub Secrets lässt sich ein zentraler Benutzer einmalig sicher hinterlegen und anschließend automatisch für alle Deployment-Läufe verwenden.

Wie automatisiert man das Deployment aus GitHub heraus?

Wir nutzen dafür GitHub Actions, um unser Setup zu vereinfachen. Mit GitHub Actions erstellen Sie eigene Software-Lifecycle-Workflows direkt in Ihrem GitHub-Repository. Diese Workflows bestehen aus einzelnen Aufgaben, den sogenannten Actions, die bei bestimmten Ereignissen automatisch ausgeführt werden können. Mehr dazu finden Sie in der offiziellen GitHub-Dokumentation.

Das sind schöne Ergänzungen zum ohnehin umfangreichen Funktionsumfang von GitHub.

1. GitHub dient als Code-Repository für die UI5-Anwendung.
2. Ein SAP-BTP-Subaccount wird für das Deployment angebunden.
3. Die Verbindung wird über unsere eigene GitHub Action hergestellt.

---

Schritt-für-Schritt-Anleitung:

Eine Annahme für die nächsten Schritte ist, dass Sie bereits wissen, wie ein Deployment einer Anwendung nach SAP BTP Neo abläuft. Es ist wichtig zu verstehen, welche Schritte wir hier automatisieren. Falls nicht, finden Sie hier↗️ eine Anleitung.

Alle Inhalte rund um GitHub Actions liegen im Ordner .github/workflows des Projekts. Falls Ihr Projekt diesen Ordner nicht hat, legen Sie ihn an.

In diesem Ordner benötigen wir eine .yaml-Datei, die sämtliche Konfigurationen enthält. Der Dateiname kann frei gewählt werden. Der Einfachheit halber verwenden wir hier deployment.yaml. Am Ende sollte Ihre Ordnerstruktur in etwa wie im folgenden Ausschnitt aussehen.

root
|__ .github
    |__ workflows
	|__ deployment.yaml

deployment.yaml

name: SAP BTP Deployment

on:
  # deployment will take place on GitHub PUSH action, whenever there is a push to the 'master' branch (we can change it to any action, Ex: COMMIT)
  push:
    branches:
      - master
  # for manual deployement
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning'

jobs:
  deploy:
    name: Deployment
    runs-on: ubuntu-latest
    # the jobs which will run on this event
    steps:
      - name: Checkout to repository
        uses: actions/checkout@v1
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - name: Load NPM dependencies
        run: yarn
      - name: Build UI5 Project
        run: yarn build-all
      - name: Deploying Project
        uses: integrtr/ui5-deploy@master
        with:
          type: 'neo'
          user: ${{ secrets.NEO_USER }}
          password: ${{ secrets.NEO_PASSWORD }}
          host: ${{ secrets.NEO_HOST }}
          sub-account-id: ${{ secrets.NEO_ACCOUNT }}

Da wir mehrere GitHub Secrets verwenden, die für die Verbindung zu SAP BTP notwendig sind, können wir diese im Secrets-Bereich von GitHub pflegen: GitHub repository → Go to settings tab → Secrets

Hinweis: Zum Pflegen von Secrets benötigen Sie Administrator- oder Owner-Rechte im GitHub-Repository.

SAP BTP verlangt für eine Anwendung einige zwingend notwendige Grunddaten. Diese lassen sich in der Datei mta.yaml im Wurzelverzeichnis Ihres Projekts pflegen.

root
|__ mta.yaml

mta.yaml

_schema-version: '2.0.0'
ID: 'ui5boilerplate'
version: 1.0.0

parameters:
  hcp-deployer-version: '1.0.0'

modules:
  - name: 'ui5boilerplate'
    type: com.sap.fiori.app
    path: ./dist
    parameters:
      html5-app-name: 'ui5boilerplate'
      html5-app-display-name: 'ui5boilerplate'
      minimum-sapui5-version: 1.44.10
      html5-app-version: 1.0.0-${timestamp}

Wir haben unser Projekt so konfiguriert, dass es eine GitHub Action nutzt und unsere Anwendung bei jedem neuen Commit auf dem master-Branch nach BTP deployt. Das ist das Standardverhalten, das Sie ab jetzt haben, und es lässt sich mithilfe der GitHub-Referenzdokumentation durch Anpassen der yaml-Dateien vollständig auf Ihre Bedürfnisse zuschneiden.

Jetzt können Sie Ihre neuen Änderungen nach GitHub pushen und werden im Tab "Actions" die GitHub Action sehen, sobald Ihr Code in den master-Branch gemergt ist. Nach Abschluss des Deployments sehen Sie den aktualisierten Code in Ihrem BTP-Subaccount.

Beispiel-Repository mit GitHub-Action-Setup: https://github.com/integrtr/ui5-boilerplate/tree/basic-deployment-setup

Nachdem Sie nun das Grundsetup für Ihre Deployments konfiguriert und automatisiert haben, experimentieren Sie ruhig weiter, um die Abläufe noch effizienter zu machen. Einiges, das Sie ausprobieren können:

• Eine einzelne Anwendung in mehrere Subaccounts deployen
• Entwicklungs-, Qualitäts- und Produktivumgebung mühelos pflegen
• Automatisiertes Deployment kombiniert mit manuellem Deployment in die Produktion für mehr Kontrolle
• Zusätzliche GitHub Actions aus dem Marketplace für Codequalitätsprüfungen und automatisierte Tests (etwa ESLint) nutzen
• Deployments über mehrere Systeme hinweg. Nutzen Sie die Action ui5-deploy, um Deployments für Ihre ABAP-Umgebungen zu konfigurieren

Viel Freude beim Automatisieren Ihrer Entwicklungs-Workflows!