Fiori für ABAP - Git
Die Git Anbindung ist für die Sicherung der Ressourcen aus der Fiori Generierung ein wichtiger Bestandteil, da dadurch Anpassungen in der späteren Wartung möglich sind.
Inhaltsverzeichnis
In diesem Artikel schauen wir uns die Anbindung von Git (HitHub, GitLab oder ähnlich) an das Business Application Studio an und wie du damit dein Projekt sicherst.
Einleitung
Beim letzten Mal haben wir erste Anpassungen an unserer Sales App vorgenommen. Dabei wird dir sicherlich aufgefallen sein, dass wir nun Änderungen haben, die wir bisher nur lokal vorhalten und keinem anderen Entwickler zur Verfügung stellen können. Daher sollten wir uns im nächsten Schritt näher mit Git und der Versionsverwaltung vertraut machen. Dies ist das Standardwerkzeug, um Ressourcen zentral zu speichern und sie im Team zu teilen.
Git
Bei Git handelt es sich um eine zentrale Versionsverwaltung auf Dateibasis. Dies ist der aktuelle Standard für die Softwareentwicklung außerhalb des SAP-Ökosystems. Im Bereich ABAP werden alle unsere Versionen und Änderungen, die wir an Objekten durchführen, lokal im System gespeichert. Daher ist eine dezentrale Ablage über Git systemintern oft nicht zwingend nötig. Git kommt allerdings schon heute zum Einsatz, wenn wir mit Open-Source-Projekten arbeiten, da diese über abapGit zur Verfügung gestellt werden. Dabei werden die verschiedenen Artefakte ebenfalls als Dateien ausgelagert und in einem Git-Repository bereitgestellt. Das Git-Repository verfolgt eine gewisse Struktur, je nachdem, um welches Projekt oder um welche Programmiersprache es sich handelt.
Projekt synchronisieren
Beginnen wir also in diesem Kapitel damit, unser bestehendes Projekt in einem Git-Repository zu sichern.
GitHub Projekt
Bevor wir mit dem eigentlichen Speichern des Projektes beginnen können, müssen wir zuerst ein Git-Repository anlegen. In diesem Fall verwenden wir GitHub zur Speicherung der Daten und legen ein neues Repository an. Hierbei erstellen wir zunächst ein leeres Repository und führen keine Initialisierung durch, das heißt, wir legen weder eine README-Datei noch eine .gitignore-Datei an. Am Ende dieses Prozesses erhalten wir ein leeres Git-Repository, welches wir anschließend über die URL (https://github.com/Xexer/fiori-global-sales.git) ansprechen können. Ob du das Repository Public oder Private anlegst, bleibt dir überlassen. Soll kein anderer Zugriff auf die Daten und das Projekt haben, solltest du es Private anlegen.
Nach der Erstellung des Repositories erhalten wir die folgende Übersicht. Hier ist zu erkennen, dass noch keine Daten hochgeladen wurden und somit auch noch kein Branch verfügbar ist. Im unteren, blau markierten Bereich findest du die Repository-URL. Diese benötigen wir im nächsten Schritt, um im Business Application Studio mit der Speicherung fortzufahren.
Verzeichnis wechseln
Da wir im nächsten Schritt eine manuelle Initialisierung durchführen, müssen wir zunächst in das vorgesehene Arbeitsverzeichnis wechseln. Navigiere hierzu über das Hamburger-Menü im oberen Bereich zum Pfad "File -> Open Folder...", um den Projektordner auszuwählen. Nach der Auswahl sollte unser Projekt auf der obersten Ebene der Explorer-Leiste sichtbar sein. Standardmäßig werden Fiori-Projekte im Verzeichnis "/home/user/projects/" abgelegt.
Hinweis: Ist deine Fiori App nicht das oberste Verzeichnis, wird Git im nächsten Schritt alle deine Dateien speichern. Damit können unter anderem mehrere Fiori Apps gesichert werden.
Synronisierung
Als Nächstes wechseln wir in das Source Control Tool. In der Seitenleiste findest du nun den Button "Initialize Repository", den wir als Erstes betätigen.
Das lokale Repository wird nun initial aufgebaut. In der Übersicht findest du jetzt alle Änderungen bzw. Dateien, die mit dem Repository verknüpft werden. Falls du beispielsweise nicht möchtest, dass eine bestimmte Datei später im öffentlichen Repository zur Verfügung steht, solltest du die Datei oder den entsprechenden Dateipfad in die .gitignore-Datei aufnehmen. Dies ist vor allem dann sinnvoll, wenn du lokale Passwortdateien oder andere Einstellungen nutzt, die nicht öffentlich sichtbar sein sollen.
Im nächsten Schritt gibst du in das Feld für die Message eine initiale Nachricht ein, um den ersten Commit durchzuführen, zum Beispiel "Initial Commit", und drückst im Anschluss auf den blauen Commit-Button. Damit wird ein erster Stand in deiner Versionsverwaltung gespeichert. Da du die Dateien zuvor wahrscheinlich noch nicht manuell zum Staging-Bereich hinzugefügt hast, wird dich das System fragen, ob du alle Änderungen direkt für den Commit übernehmen möchtest, dies bestätigst du mit "Yes". Damit ist der erste Commit in deinem lokalen Repository erfolgreich durchgeführt. Die Änderungen befinden sich zu diesem Zeitpunkt jedoch noch nicht auf GitHub. Daher verbinden wir nun im nächsten Schritt das GitHub-Repository mit diesem lokalen Repository. Über das Drei-Punkte-Menü findest du den entsprechenden Befehl unter "Remote -> Add Remote".
Im nächsten Schritt hinterlegst du das GitHub-Repository. Hierzu fügst du den Link ein, den du zuvor von GitHub kopiert hast. Danach fragt dich das System nach einem Namen für das Remote, standardmäßig wird hierfür oft „origin“ verwendet. Anschließend wirst du nach der Authentifizierung gefragt. Hierbei handelt es sich um das Standardverfahren gegenüber GitHub. Du erhältst einen Verifizierungscode, meldest dich bei GitHub an, bestätigst den Code und autorisierst damit die Verlinkung. Zum Abschluss erscheint eine Aufforderung, ob die Anmeldedaten dauerhaft in einer lokalen Datei gespeichert oder nur für die aktuelle Session verwendet werden sollen. Wir empfehlen hier die Option "Session". Dies ist sicherer und beugt Problemen vor, falls beispielsweise dein Authentifizierungstoken abläuft. Eine frische Anmeldung pro Sitzung stellt sicher, dass die Verbindung zum Repository jederzeit stabil und aktuell ist.
Als letzten Schritt klicken wir auf den blauen Button "Publish Branch", um den eigentlichen Push in das Remote-Repository durchzuführen. Hierbei erscheint eine Sicherheitsabfrage, ob wir die Aktion wirklich ausführen möchten, was wir mit "Yes" bestätigen. Die Ressourcen werden nun in unser GitHub-Repository übertragen, womit der aktuelle Entwicklungsstand sicher gespeichert ist.
.gitignore
Schaust du dir die Dateistruktur im Explorer einmal genauer an, wirst du feststellen, dass der node_modules-Ordner und die ui5-deploy.yaml ausgegraut und hervorgehoben sind. Das liegt daran, dass wir diese Dateien in die .gitignore Datei aufgenommen haben, damit werden sie nicht automatisch mit dem Git-Repository synchronisiert. In der Deployment-Konfiguration stehen zum Beispiel Informationen zum Zielsystem, die wir dort nicht veröffentlichen möchten. Der node_modules-Ordner hingegen wird beim Bauen der Anwendung automatisch erstellt und die darin enthaltenen Pakete heruntergeladen, um auf dem aktuellsten Stand zu sein. Daher macht es keinen Sinn, diesen Ordner zu synchronisieren, da sich die Artefakte beim Build-Prozess ohnehin ändern können und diese automatisch über die npm-Registry zur Verfügung gestellt werden.
Manuell
Das Arbeiten über die grafische Oberfläche ist nicht für jeden Entwickler ideal, da viele die volle Kontrolle über die einzelnen Git-Befehle bevorzugen. Dieser Weg steht dir im Business Application Studio selbstverständlich ebenso offen. Du kannst über das integrierte Terminal sämtliche Git-Kommandos manuell aufrufen, um das Repository zu verbinden und den Push durchzuführen. In diesem Artikel haben wir uns jedoch bewusst auf den geführten Weg über die Benutzeroberfläche konzentriert, um den Einstieg so einfach wie möglich zu gestalten.
Git (On-Prem)
Möchtest du ein On-Premise-Git verwenden, musst du hierfür den Weg über den Cloud Connector wählen. Eine direkte Verbindung ist nicht möglich, da es sich beim Business Application Studio um ein Cloud-Produkt handelt, welches keinen direkten Zugriff auf dein lokales Netzwerk hat. Daher müssen wir mit einer Destination im BTP Subaccount arbeiten. Diese Destination verweist auf den Cloud Connector, welcher wiederum die Anfrage sicher an das interne Git-System (z. B. GitLab) weiterleitet. Im folgenden Beispiel verwenden wir ein On-Premise gehostetes GitLab. Die folgende Abbildung zeigt die entsprechende Destination und wie die technische Konfiguration im Detail aussieht.
Dabei kannst du im Anschluss ganz normal arbeiten, als würde es sich um eine öffentliche Adresse handeln. Allerdings musst du hierbei den Pfad abändern, damit die Verbindung über die Destination hergestellt werden kann. Hierzu ersetzt du den Hauptpfad (Host) durch die Referenz auf die Destination mit ".dest" am Ende. Damit weiß das System, dass es eine konfigurierte Destination verwenden soll und welche spezifische Verbindung gemeint ist. Um dies zu verdeutlichen, findest du im Folgenden ein kleines Beispiel für einen Originalpfad und im Vergleich dazu den abgeänderten Pfad:
" Original path
https://gitlab.intranet.local/MyUserId/fiori-global-sales.git
" Adjusted path
https://gitlab.dest/MyUserId/fiori-global-sales.git
Vollständiges Beispiel
Die gespeicherten Ressourcen zu unserer Anwendung findest du in unserem GitHub Repository. Damit kannst du in Zukunft alle Anpassungen an der Fiori App mit nachvollziehen oder die Ressourcen für ein Deployment nutzen.
Fazit
Die Arbeit mit Git ist ein wichtiger Bestandteil zur Sicherung der aktuellen Konfiguration einer Fiori-Anwendung. Ohne die Sicherung der Daten und der entsprechenden Anpassungen ist es nachfolgenden Entwicklern nicht möglich, die App sauber zu verwalten, zu warten oder zu aktualisieren.
