Aus dem Blickwinkel einer eher traditionellen Softwareentwicklung wirkt die Welt der (On Premise-)ABAP-Entwicklung oft unglaublich archaisch. Ihre Best Practices gelten in der Branche seit Jahren oder gar Jahrzehnten als obsolet. Zwar arbeitet SAP mit neuen Tools eifrig daran, die ABAP-Entwicklung für das 21. Jahrhundert fit zu machen, aber diese neueren Tools werden bisher nur zögerlich angenommen.

Mit diesem Blog sollen die für eine moderne ABAP-Entwicklungsumgebung und Deployment-Pipeline erforderlichen Praktiken etwas näher beleuchtet werden.

Eclipse

SAP hat klar zum Ausdruck gebracht, dass die zentrale integrierte Entwicklungsumgebung (IDE) für die ABAP-Entwicklung nunmehr Eclipse ist und in SE80 und ABAP Workbench nicht mehr investiert wird.

Einerseits wird der Funktionsumfang in Eclipse ständig erweitert (bessere Code-Vervollständigung, bessere Refactoring-Unterstützung usw.); und andererseits werden Features bereitgestellt, die der SAP-GUI einfach fehlen, wie beispielsweise die Möglichkeit, mit CDS-Ansichten oder dem neuen ABAP-RESTful-Programmiermodell zu arbeiten.

Ein weiterer Vorteil von Eclipse besteht darin, dass es neben den ABAP-Funktionen auch die UI5-Entwicklung unterstützt. Dadurch sind sowohl die Frontend- als auch die Backend-Entwicklung über dieselbe IDE zugänglich.

Nach vielen Jahren mit der ABAP Workbench kann es etwas dauern, sich auf Eclipse umzustellen. Trotzdem ist man relativ schnell damit vertraut – und mit den zusätzlichen Tools und Funktionen können Entwickler ihre Produktivität erheblich steigern.

Automatisierte Komponententests

Obwohl es ABAP Unit inzwischen seit rund 15 Jahren gibt, wurde es anfangs nur sehr wenig genutzt. Fairerweise muss man den ABAP-Entwicklern allerdings zugutehalten, dass die verfügbaren Tools zunächst sehr zu wünschen übrig ließen. Eine xUnit-Implementierung ohne die entsprechenden benutzerfreundlichen Mocking-Bibliotheken ist schließlich nur von sehr begrenztem Nutzen.

In den vergangenen Jahren erweiterte SAP das Toolset jedoch um das ABAP Test Double Framework für das Mocking von Klassenschnittstellen und später dann das CDS- und Open SQL Test Double Framework für das Mocking von CDS-Ansichten und Datenbank-Artefakte – und verbesserte es damit erheblich. Sicher gibt es noch immer Optimierungspotenzial – und diese Frameworks sind auch nicht so leistungsfähig wie ihre Pendants in anderen Sprachen. Trotzdem ist es ein Unterschied wie Tag und Nacht. Und das Schreiben von Komponententests ist inzwischen viel einfacher und effizienter geworden.

Das richtige Schreiben von Komponententests zu erlernen und nach dem Konzept der testgetriebenen Entwicklung (TDD) zu arbeiten, erfordert durchaus ein Umdenken und einigen Lernaufwand, erhöht jedoch die Softwarequalität und macht sich damit langfristig bezahlt.

Automatisierte statische Code-Überprüfung

Viele Programmierfehler lassen sich durch eine statische Code-Überprüfung, wie sie oft in fortlaufenden Integrationsszenarien genutzt wird, frühzeitig erkennen. Bei ABAP werden dazu am häufigsten der Code Inspector und das ABAP Test Cockpit verwendet.

Es ist ratsam, beide mit angepassten Varianten und Regeln einzurichten und automatisch auszuführen, damit Entwickler und Prüfer bei Fehlern und Warnungen so früh wie möglich benachrichtigt werden.

Automatisierte Änderungsverwaltung und Bereitstellung

Eines der größten Probleme bei der ABAP-Entwicklung ist das Transportsystem. Während die übrige Softwarewelt bereits vor langer Zeit auf verteilte Versionskontrollsysteme wie Git und Mercurial umgestiegen ist, basieren ABAP-Änderungen nach wie vor auf Transporten (mehr dazu im nächsten Punkt), sind von Natur aus zentralisiert und arbeiten mit Objektsperren. Für die Produktivität, das Entwicklungstempo und die sichere Verwaltung von Änderungen kann das ein großes Hemmnis sein.

Für die sichere und richtige Bereitstellung von Änderungen zwischen Umgebungen mit automatisierten Konfliktprüfungen, die CI/CD-Pipelines ähneln, sind daher zusätzliche Tools unerlässlich. Die Zeit der manuellen Bereitstellung per STMS auf Basis von Excel-Tabellen ist definitiv vorbei.

Ein Blick in die Zukunft: ABAPGit

Der folgende Punkt ist wohl der spekulativste in diesem Artikel. Dennoch soll er nicht unerwähnt bleiben, weil sich die Zeichen für seine künftige Relevanz verdichten. ABAPGit wird von SAP inzwischen offiziell befürwortet. Es kann ABAP-Entwicklungsobjekte in Git-Repositorys verwalten und diese in einem NetWeaver-Backend bereitstellen.

Ursprünglich wurde ABAPGit für das Code-Sharing in Open-Source-ABAP-Projekten entwickelt. Theoretisch ist es jedoch durchaus möglich, einen Git-basierten ABAP-Entwicklungsworkflow für die On-Premises-Entwicklung einzurichten.

In diesem Szenario würden alle ABAP-Entwicklungsobjekte von einem Git-Repository nachverfolgt werden. Jeder ABAP-Entwickler hätte sein eigenes Entwicklungssystem (eventuell gebündelt mit Docker) und würde seine eigenen lokalen Arbeitskopien entwickeln.

Best Practices müssen sich in diesem Bereich erst noch etablieren, die Möglichkeiten sind jedoch unbegrenzt. Es liegt auf der Hand, dass die Implementierung eines verteilten Versionskontrollmodells für die ABAP-Entwicklung ein großes Potenzial bietet und die Produktivität mit Sicherheit enorm steigern würde.

Ein Schritt nach dem anderen

Der Versuch, zu viele Änderungen auf einmal einzuführen, kann natürlich eine Herausforderung darstellen und sogar in einer Katastrophe münden, wenn er nicht von allen Mitgliedern des Teams mitgetragen wird. Daher empfiehlt sich ein schrittweises Vorgehen.

Wenn Sie gegenwärtig keine der in diesem Artikel genannten Tools und Techniken nutzen, dürfte es als Einstieg sinnvoll sein, mit automatisierten Code-Überprüfungen zu beginnen und dann langsam zur automatisierten Bereitstellung überzugehen. Das erfordert keine großen Anfangsinvestitionen und/oder kulturellen Anpassungen und trägt schnell Früchte.

Jüngste Entwicklungen bei SAP lassen darauf schließen, dass uns ABAP noch eine ganze Weile erhalten bleiben wird. Das Ökosystem von SAP entwickelt sich rasant weiter. Angesichts dessen ist es wichtiger denn je, eine Entwicklungskultur zu etablieren, in der ständig neue Tools und Empfehlungen sondiert und evaluiert werden.

Weil es auf das „Dev“ in „DevOps“ ankommt

Die bei Basis Technologies entwickelten DevOps-Automatisierungstools sind zwar nicht ausschließlich für Entwickler gedacht, bieten aber gerade diesen vielfältige Vorteile (schließlich ist „Dev“ ein ganz wichtiger Teil von „DevOps“). So ermöglichen sie beispielsweise die automatische Überprüfung von Konflikten und Abhängigkeiten sowie den Einsatz von Tools wie Code Inspector zur Validierung des Codes vor dessen Freigabe für die Qualitätssicherung. Unser Testtool gibt Ihnen sogar die Möglichkeit, das Testen vorzuziehen und regelmäßige Regressionstests an neuem Code durchzuführen, ohne sich um Skripte, Testdatenverwaltung, externe Schnittstellen und all das kümmern zu müssen, was Sie normalerweise aufhalten würde. Wenn Sie mehr darüber wissen möchten, wie unsere Kunden ihre SAP-Entwicklung mit unseren Tools optimieren, fordern Sie hier eine Produktpräsentation an.