gCTS – Das Transportsystem 2.0
In den letzten zehn Jahren hat sich bei den SAP-Kernthemen einiges getan. HANA-Datenbanken verändern Grundprinzipien der bisherigen Datenhaltung durch zeilenbasiertes Speichern und Core Data Services. Fiori ersetzt Reports und Dynpros durch eine nutzerfreundliche, moderne und mobil nutzbare Oberfläche. Auch ABAP entwickelt sich immer weiter und unterstützt jetzt Inline-Deklarationen von Variablen und Tabellen. Nun erhält der Entwicklungsprozess ein Upgrade: Das Git-enabled Change and Transport System, kurz gCTS.
Warum, wofür: Versionierung
Versionierung hat vor allem zwei große Vorteile: Protokollierung und Wiederherstellung. Protokollierung dient dazu, später Veränderungen nachvollziehen und nachweisen zu können. Das ist besonders interessant, wenn etwas nicht mehr funktioniert. Dann gilt es, herauszufinden, wann und von wem zuletzt daran gearbeitet wurde. Im besten Falle ist auch protokolliert, wer die Änderung vollzogen hat und wieso diese notwendig war.
Wiederherstellung ist eng damit verknüpft. Wenn mit dem letzten Update ein Fehler eingespielt wurde, ist es oft schneller, den vorherigen Stand wieder herzustellen, als den Fehler zu beheben und als neues Update einzuspielen.
Git ist eine moderne Versionsverwaltung
Git hat sich über die letzten 15 Jahre zum de facto Standard in der Softwareentwicklung entwickelt. Branches und dezentralisierte Versionierung werden oft als Gründe von Git’s Erfolg und Popularität dargestellt. Unter anderem, weil sie einen neuartig flüssigen und schnellen Entwicklungsablauf erlauben. Für die Entwicklung in einem SAP-System sind diese Merkmale aber nur bedingt relevant. Schließlich greift der Hauptvorteil von Branches erst bei mehreren Entwicklungssystemen. Auch wenn jeder Entwickler sein eigenes System hat, bremst das SAP-System selbst die Geschwindigkeitsvorteile von dezentraler Versionierung aus.
Der Unterschied: Dateien vs. Systeme
Vor Git wurden Versionen meist auf Dateiebene verfolgt. Das ergibt Sinn, solange jede Datei eine in sich geschlossene Einheit bildet oder sichergestellt ist, dass sich eine Anpassung nicht auf die Schnittstellen und globalen Daten auswirkt. Problematisch wird dieser Ansatz aber, wenn diese Grenzen überschritten werden und eine Anpassung über mehrere Dateien hinweg geschieht. Das Zurückrollen einer Datei auf einen vorherigen Stand bedingt damit das Zurückrollen anderer Dateien. Das macht das tatsächliche Nutzen der Versionierung aufwendig und komplex.
Git hingegen sieht jeden Commit als den Stand des gesamten Projektes zu dem Zeitpunkt und ist damit immer, von dem Stand der Entwicklung abgesehen, lauffähig. Das erlaubt ein vergleichsweise einfaches Hin und Herspringen zwischen Versionen und ein schnelles Zurückrollen im Falle von problematischen Änderungen in einem Commit. Hinzu kommt eine detaillierte Übersicht aller Änderungen bis auf die Zeile genau, ein Kommentar an jedem Commit, das die Änderungen begründet und das Erstellen und Mergen von Branches.
abapGit verdient als größtes Open Source non-SAP-SAP-Projekt seinen eigenen Artikel. Diesen finden sie hier: Wie abapGit Ihre SAP-Entwicklung retten kann
ABAP ist anders – und das ist kein Vorteil
Softwareentwicklung in SAP ist anders als in vielen anderen Bereichen der Softwareindustrie. Nigel James beschreibt das genauer in seinem SAP Blogartikel. Kurz gesagt: Code und Entwicklung in SAP sind zentralisiert, ein anderweitig unübliches Vorgehen. In einer verbundenen und interagierenden Welt ist ABAP für Außenstehende kaum erreichbar. Open Source und generische Lösungen sind oft nicht kompatibel mit dem System. Das zeigt sich auch beim Einbinden von Git in den existierenden Ablauf.
AbapGit erlaubt zwar Entwicklung mit Git, integriert sich aber nicht fließend mit dem bisherigen System. Aktuell sind Projekte in Git auf ein Paket in SAP limitiert. Die bisherige Lösung ist es, mit verschachtelten Paketen hier drumherum zu arbeiten. Ähnlich ist es mit Transporten, die weiterhin als Versionskontrolle dienen. Git verhält sich also entweder als reines Versionskontrollsystem für die Entwicklung oder umgeht das Transportsystem. Beide Lösungen koexistieren und es liegt am Nutzer, zu entscheiden, wo welches Werkzeug angebracht oder notwendig ist.
Was gCTS möglich macht
Das Git-enabled Change and Transport System springt hier ein und verknüpft Git mit dem Transportsystem. Entwicklung in SAP verhält sich auf den ersten Blick wie gewohnt. Der entscheidende Unterschied geschieht beim Freigeben eines Transportes. Bisher werden die Änderungen auf das nächste SAP-System geschoben. gCTS hingegen transportiert auf eine virtuelle Transportschicht und erstellt einen Commit auf dem externen Git Repository. Der relevante Unterschied zu abapGit ist hierbei, dass das Projekt eine Transportschicht umfasst und damit nicht mehr auf Pakete angewiesen ist.
Mit gCTS fügt sich git nahtlos in das Transportsystem ein
Das nächste System zieht nun den aktuellen Stand von dem Repository und importiert diesen als eingehenden Transport. Da dies auf Commits basiert, ist es nicht viel Aufwand, einen Import rückgängig zu machen. Hierzu wird der vorhergehende Commit gezogen und importiert. Im Falle eines Fehlers im Coding kann das System einfach auf einen funktionierenden Commit zurückgerollt werden. Das eignet sich besonders dafür, Testsysteme sauber zu halten, ist aber auch eine gute Versicherung für das Produktivsystem.
Automatisierung als neuer Standard – einfacher durch gCTS
Dies ermöglicht eine kontinuierliche Integration (continuous integration – CI) der freigegebenen Transporte in das Testsystem. Eine CI-Pipeline kann den Transport automatisch einspielen, testen (beispielsweise per ABAP Unit Tests) und im Falle von Fehlern zurückrollen und dem Entwickler Bescheid geben. Eine automatische Auslieferung (continuous deployment – CD) ist der letzte Schritt, bei dem nach erfolgreichen automatischen Tests der Transport automatisch für User Tests freigegeben wird.
Ein CI/CD Workflow nutzt die einfach Rückrollbarkeit von gCTS Transporten
gCTS ist die Zukunft der ABAP-Entwicklung
Langfristig wird es möglich sein, zwischen Entwickler- und Produktivsystem nur noch dann auf menschliches Feedback zu warten, wo es unabdingbar ist. Ansonsten soll das System selbstständig Anpassungen testen und transportieren, wobei die Option zum einfachen Rückgängig machen immer erhalten bleibt. Das entlastet die Entwickler, die sich nun vor allem mit dem Programmieren auseinandersetzen können. Genauso profitieren die Tester und der Fachbereich davon, da die automatischen Tests die funktionalen Fehler abfangen und der Fokus nun auf Qualität der Nutzerinteraktion und Umsetzung der Anforderungen liegen kann.
In meinen Augen ist gCTS die Zukunft der ABAP-Entwicklung. Es erlaubt eine moderne Arbeitsweise und beweist, dass SAP nicht eisern an etablierten, aber veralteten Entwicklungsprinzipien festhält. Ich freue mich darauf, die Anfänge der Softwareentwicklung 4.0 in SAP zu sehen und zu unterstützen.
Was denken Sie über die gCTS? Nehmen Sie gerne Kontakt zu mir auf oder tauschen Sie sich über die Kommentare aus. Ich freue mich auf Ihren Input!
