Der Weg zu einer Git-basierten ABAP-Entwicklung: Teil 3

"Kein Plan überlebt die erste Feindberührung."

Warum wir bei Basis Technologies gerade jetzt mit der Git-basierten Entwicklung beginnen, liegt vor allem daran, dass wir im Begriff sind, ein Langzeitprojekt zu starten, das einen Großteil unserer Codebasis betreffen wird, und wir die Welt leider nicht anhalten können, bis dieses Projekt über die Bühne ist. Wir rechnen mit hunderten von Konflikte erzeugenden „Dateien“ (von circa 10.000) und gehen davon aus, dass dieser Prozess dank Git zwar nicht komplikationsfrei, aber zumindest beherrschbar sein wird.

Entscheidend ist: Wir möchten unsere Codebasis zuvor so gut wie möglich bereinigen.

Der Plan

Er wird sich im Laufe der Zeit wahrscheinlich ändern, sieht aber momentan in etwa so aus:

• Bereinigung der Codebasis:
  • Abschluss von so vielen laufenden Änderungen wie möglich
  • Konsolidierung unserer Codebasis – wir möchten so produktionsnah wie möglich, aber einschließlich einiger Beta-Versionen und icht freigegebener Ergänzungen, beginnen
  • Standardisierung der Code-Formatierung
  • Ausrichtung des Hauptentwicklungssystems am resultierenden Code
• Entwicklung zweier unabhängiger Branches:
  • 1. Das Langzeitprojekt mit abapGit Verwendung
  • 2. Alles übrige mit einem traditionellen TMS-Workflow, wobei jedoch jede Änderung an Git übergeben wird, sobald die Qualitätssicherung abgeschlossen ist
• Zusammenführen der zwei Branches
• Durchführung eines umfangreichen Regressionstests

Code-Formatierung

Ich bin ein großer Fan von Pretty Print und führe es vor dem Speichern fast immer aus. Ich finde es mühsam, Einrückungen und Großschreibung manuell zu verwalten. Und wenn jeder die gleichen Einstellungen verwendet, lässt sich der Code einheitlicher gestalten. Leider ist das nicht unser Ausgangspunkt.

Bei einheitlicher Formatierung sieht eine kleine Änderung wie folgt aus:

Andernfalls sieht es folgendermaßen aus:

Die Beispielbilder stammen aus JavaScript-Dateien; das Prinzip ist jedoch auch auf ABAP übertragbar. Ja, in der SAP-GUI können Groß-/Kleinschreibung und Leerzeichen ignoriert werden. In unserem Szenario erfolgt jedoch ein Merge, und die meisten Merge Tools verstehen die ABAP-Syntax nicht. Es wäre zwar möglich, dies zu umgehen, dennoch halte ich es für eine gute Idee, die Code-Formatierung zu standardisieren.

Ich habe ein kleines Befehlszeilen-Dienstprogramm geschrieben, um diese Aufgabe zu automatisieren.

Integration von TMS und Git

Wir haben vor, die komplette Entwicklungsarbeit in Git, sowohl mit als auch ohne TMS, in Git nachzuverfolgen. Änderungen, die im Hauptentwicklungssystem vorgenommen wurden, wandern in einen Branch, der nur für die Nachverfolgung der dort vorgenommenen Änderungen verwendet wird – ob getestet oder nicht. Dies dient lediglich Revisionszwecken.

Änderungen, die es in die Vorproduktion schaffen, werden im Hauptzweig nachverfolgt. Wir werden die ABAP-Funktion „Get Background“ verwenden und wahrscheinlich unseren eigenen Hintergrundmodus erstellen, um Querverweise auf Commits mit unserer Issue-Tracking-Software (Jira) zu ermöglichen.

Für den von Git verwalteten Projektbranch verfügt jeder Entwickler über ein eigenes Repository und sendet Pull-Anforderungen an das zentrale Repository.

Merges werden auf Benutzer-Laptops durchgeführt und gelangen bis zum Ende des Projekts über Pull-Anfragen in das Haupt-Repository. Dann wird ein Transport mit dem Delta zwischen dem zusammengeführten Projektbranch und dem Hauptbranch erzeugt und zum Hauptentwicklungssystem geschickt.

Jeder Konflikt mit Änderungen, die in die Vorproduktionsversion importiert wurden, wird ignoriert, weil sie bereits in der Hauptversion enthalten sind. Für die anderen finden wir noch eine Lösung.

Mergestrategien

Folgende Optionen bieten sich an:

Zusammenführen, sobald das Projekt abgeschlossen ist.
Das hat einen großen Vorteil:

• Das Zusammenführen ist ein aufwändiger Vorgang, den Sie nur einmal ausführen können.

... aber auch einige Nachteile:

• Es ist eine große, komplexe Aufgabe, die sich nur schwer auf mehrere Entwickler aufteilen lässt.
• Wenn etwas schief geht, werden wir es erst am Ende des Projekts merken.
• Nicht sehr agil oder DevOps

Die von uns favorisierte Option ist das häufige Zusammenführen kleiner geänderten Einheiten.

Wahrscheinlich werden wir dasselbe Stück Code mehrmals zusammenführen müssen, aber es bietet viele Vorteile:

• Einzelne Zusammenführungen sind klein und für einen einzelnen Entwickler problemlos handhabbar.
• Wenn der Workflow Probleme macht, merken wir es sofort.
• Dieser Ansatz ist agil und DevOps.

Fazit

Einige vorbereitende Maßnahmen haben bereits begonnen, aber das Gros der eigentlichen Arbeiten wird im Juni beginnen. Wahrscheinlich werden wir einige Anpassungen vornehmen, und ich werde diesen Ansatz definitiv erst in kleinerem Maßstab ausprobieren, bevor ich mich darauf festlege. 

Aber das ist der Plan für den Moment. Wenn es gut läuft, könnten wir sogar eine Version davon in unseren regulären Prozess einbinden. Vielleicht bereuen wir aber auch, dass wir es jemals versucht haben. Die Zeit wird es zeigen.