Bei Basis Technologies basieren die Tools auf ABAP. Daher ist abapGit schon seit langem auf unserem Radar, und wir beschäftigen uns schon seit einiger Zeit damit (wenn Sie nicht wissen, was abapGit ist, können Sie hier oder hier mehr darüber erfahren). Bisher bestand die einzige „produktive“ Nutzung darin, regelmäßig einen Commit der Änderungen auszuführen. Dies hat einen gewissen Wert für das Auditing (wir können sehen, wer was wann geändert hat bzw. die Entwicklung mit der Produktion vergleichen, bis hin zur einzelnen Codezeile). Mit Branches und CI-Pipelines sind wir aber noch weit entfernt vom heiligen Gral der Entwicklung – so wie der Rest der Welt.

Vor kurzem haben wir jedoch begonnen, abapGit für die eigentliche Produktentwicklung einzusetzen. Seit geraumer Zeit sehen wir viel Potenzial in einem Git-basierten Ansatz. Da die erfolgreiche Überführung in den Produktivbetrieb aber immer mit viel Arbeit verbunden ist, brauchten wir einen wichtigen Grund, um tatsächlich damit loszulegen. Vor kurzem haben wir mit der Planung eines großen Entwicklungsprojekts begonnen, das den größten Teil unserer Codebasis betrifft. Wir glauben, mit abapGit viel effizienter arbeiten zu können, befinden uns hier aber noch in einem frühen Stadium. Wir haben schon viel gelernt, sind aber auch auf ein paar Hindernisse gestoßen.

Unser Ziel ist es, für ABAP im eigenen Haus einen Workflow einzuführen, der dem entspricht, was SAP hier für MTA-Anwendungen (Multi-Target Anwendungen) auf der Cloud-Plattform empfiehlt.

Der erste Schritt bestand darin, SAP-Instanzen in Containern auszuführen. Das ist zwar nicht unbedingt nötig, aber da geplant ist, jedem Entwickler eine eigene Entwicklungsumgebung zu bieten, können Container die Kosten effektiv senken und das Onboarding vereinfachen: Unser System kann mit etwa einer Minute Arbeit und 30 Minuten Wartezeit eine brandneue Instanz erzeugen. Zurzeit bieten die Container einfach eine bequeme Möglichkeit, identische Systeme schnell aufzubauen und wieder loszuwerden.

Dies wird zwar nicht von SAP unterstützt, funktioniert aber recht gut und unterscheidet sich erheblich von der allgemein üblichen Verwendung von Containern:

• Die Datenbank-Images haben größere Layer, als von den meisten Registries akzeptiert wird (etwa 50 GB verglichen mit 10 GB für Amazon ECR). Sie können zwar Ihre eigene ausführen, um diese Einschränkung zu umgehen. Dazu muss jedoch noch ein weiterer Server verwaltet werden. Wir haben uns dafür entschieden, die Datenbank in einem Volume zu belassen. Das hat zwar Vorteile, macht allerdings das Erstellen neuer Instanzen etwas komplizierter.
• Der Hostname muss erzwungen werden.
• Jeder Dienst benötigt eine eigene IP, da die Zuordnung verschiedener Instanzen zu verschiedenen Portnummern nicht funktioniert.

Bei der Ausführung auf dem eigenen Computer gibt es aber keine Probleme. Amazon ECS und ähnliche Tools genauer unter die Lupe zu nehmen, steht auf meiner To-Do-Liste. Was wir jetzt schon haben, reicht aber für den Anfang.

Unser Plan sieht so aus:

• Entwicklung in privaten Boxen, für die die Entwickler zuständig sind 
• Commit in einem Git-Repository über Feature-Branches
• Nach abgeschlossener Entwicklung
  • Durchführen so vieler automatisierter Tests wie möglich; 
    Wenn Fehler auftreten, wieder zurückgehen
  • Merge auf einem PC
  • Importieren auf den Laptop des Entwicklers, um die Aktivierung zu überprüfen und bei Bedarf Probleme zu beheben
  • Merge in ein Entwicklungssystem ziehen, wo ein Transport generiert wird
  • Durchführen weiterer Tests/Konsistenzprüfungen
• Downstream-Bereitstellung mit transportbasierten Tools

Die manuelle QS kann nachgelagert oder nach den automatisierten Tests erfolgen.

Letztes Jahr haben wir einen Prototyp vorgestellt, bei dem dieser Merge-Vorgang über eine Jenkins-Pipeline automatisiert wurde. Und das wollen wir auf lange Sicht definitiv auch in der Produktion tun. Der erste Schritt besteht jedoch darin, das Ganze manuell zum Laufen zu bringen. 

Also haben wir unsere Codebasis in eine Box importiert und abapGit in ungefähr 13.000 Dateien serialisiert. Dann haben wir den gleichen Code in eine andere, identische Box importiert. Wir werden eine Box als privates und eine als zentrales Entwicklungssystem verwenden, das in die Produktion einspeist.

Erste Überraschung: abapGit stellte Unterschiede zwischen den beiden fest, weil der Importprozess die Tabellen, auf die sich abapGit stützt, nicht vollständig gefüllt hat. Daher wurden einige Includes nicht erfasst. In den ABAP-Repository-Tabellen waren sie nicht aufgelistet. Sie wurden erst dann in SE80 angezeigt, als wir das Objekt reaktiviert haben. Deshalb haben wir das Ganze auf beiden Seiten reaktiviert, erneut committet und es schließlich geschafft, die beiden Systeme zu synchronisieren.

Wir haben den Code in die zweite Box importiert, weil es nicht funktioniert, abapGit von Null an herüberzuziehen. Es gab zu viele Aktivierungsprobleme, viele mit zirkulären Abhängigkeiten. Ich denke, im Moment sind wir für den Kick-Start auf Transporte und Massenaktivierung angewiesen. Das Wechseln zwischen den Branches funktioniert normalerweise einwandfrei, daher werden wir unsere Reise in Richtung CI (kontinuierliches Integrieren) fortsetzen.

Wir werden weiter experimentieren, um herauszufinden, ob abapGit so hilfreich ist, wie wir es uns für das große, gerade in Planung befindliche Entwicklungsprojekt erhoffen. Der nächste Schritt besteht darin, in der ersten Box etwas zu entwickeln und dann einen Transport zur zweiten Box zu generieren. Dies wird dann auf dem Hauptentwicklungstrack zusammengeführt (wir haben bereits ein System zur Erkennung von Konflikten mit lokalen Entwicklungen).

In künftigen Blogbeiträgen werde ich über unsere Fortschritte berichten. Freuen Sie sich also in den nächsten Wochen auf weitere Informationen zu der Frage, ob abapGit tatsächlich das erhoffte Potenzial bietet.

Ideen für weitere Beiträge:

• Wie richtet man Container ein? (Werkzeuge und technische Details)
• Merge-Strategie (Details zu dem, was wir heute planen und wie ein automatisierter Prozess aussehen könnte)
• Details zu unserem speziellen Anwendungsfall und wie abapGit dabei helfen kann
• Kundenbericht P&G (Kunde muss Patch testen, hat aber kein geeignetes Produktionssystem)