Übertragung des DevOps-Frameworks auf SAP

Vom klassischen DevOps-Lifecycle zum 3-Stufen-Modell im SAP-Umfeld: Continuous Integration, Continuous Delivery und Continuous Deployment. Im dritten Teil unserer Artikelreihe zum Thema DevOps für SAP erfahren Sie, wie durchgängige, technische Automatisierung und Vernetzung der Teamstruktur entscheidend zu mehr Agilität im SAP Change Management beitragen.

Falls Sie den letzten Artikel zu diesem Thema verpasst haben, diesen finden Sie hier.

„DevOps für SAP heißt bewährte Vorgehensweisen und Methoden intelligent zu verändern und an heutige Erfordernisse anzupassen.“

DevOps vereint eine schnelle Auslieferung von Software und einen sicheren Systembetrieb

Der klassische DevOps-Lifecycle besteht aus einem Phasenmodell, welches kontinuierlich abläuft und eine Symbiose aus Entwicklungs- und Betriebsprozess bildet. Je nach Quelle bzw. Lösungsanbieter variiert das aufgezeigte Modell in der Anzahl der Phasen und deren Benennung, gibt aber stets die gleiche Kernphilosophie wieder.

 

 

Im Folgenden wird das DevOps-Framework der Firma Atlassian, einer der führenden Anbieter von DevOps-Tools in der Non-SAP-Welt. betrachtet:

Die erste Phase, Plan, beinhaltet Entwicklungsaktivitäten von der Anforderungsanalyse über die Erstellung eines Release-Plans und des Business Case. Das Feedback aus dem Betrieb fließt kontinuierlich in die nächste Plan-Phase mit ein. Über alle Phasen hinweg wird in interdisziplinären Teams zusammengearbeitet, sodass Kunde, QA, InfoSec und Basis von Anfang an in die Entwicklungstätigkeiten miteinbezogen und zeitraubende Prozessübergänge zwischen einzelnen Silos vermieden werden.

Auf die Phase Plan folgt Build, vereinzelt auch als Create bezeichnet. In dieser Phase wird ein Stück Software als Release Candidate erstellt. Dazu wird der Quellcode der Software geschrieben und paketiert. Kollaboratives Programmieren kann durch eine Multicode- bzw. Versionsmanagementlösung gestützt und teilweise automatisiert werden.

Die dritte Phase, Continuous Integration bzw. Verify, beinhaltet die Testaktivitäten der Software-Qualitätssicherung und anschließende Freigabe des Releases. Miteinbezogen wird die Konfiguration der Software auf der Infrastruktur. Zentraler Punkt ist die Automatisierung mittels Tools, sodass beispielsweise Informationen teamübergreifend geteilt werden und dadurch Übergänge der Verantwortlichkeit zwischen den Teams zügig und transparent stattfinden.

Daran anknüpfend wird das Software-Release in der Phase Deploy automatisiert in die Produktionsumgebung ausgerollt, also den Anwendern zur Verfügung gestellt. Dies beinhaltet auch die Sicherstellung einer möglichen, zeitnahen Wiederherstellung der produktiven Systeme auf einen vorherigen Zeitpunkt (Rollback).

Die ausgerollte Software wird in der Phase Operate unter Zuhilfenahme von Automatisierungstools des täglichen Betriebs, wie einfachen Reboots, Backup- und Recovery-Vorgängen, oder der massenhaften Anlage von Usern betrieben. Ebenso ist ein detailliertes Monitoring notwendig, das neben System- auch Prozessdaten sammelt, um eine Echtzeitevaluation des Betriebs zu gewährleisten.

In der — vermeintlich — letzten Phase, Continuous Feedback bzw. Reporting, werden Metriken und Statistiken zur Verfügung gestellt, auf deren Grundlage Performance und Enduser-Experience beurteilt werden. Das daraus resultierende Feedback wird wieder in die erste Phase, Plan, gegeben. Auf diese Weise stellen DevOps durch stetige Verbesserungen und schnelle Releasezyklen die Wettbewerbsfähigkeit des Unternehmens sicher.

Die Übertragung des DevOps-Frameworks auf SAP

SAP ERP On-premise-Architekturen liefern im Umfeld von DevOps grundlegende Funktionalitäten, die aber zur Umsetzung des Gesamtkonzepts nicht ausreichen. In diesem Kapitel werden diese grundlegenden Funktionalitäten dargestellt und es wird beschrieben, welche weiteren Funktionalitäten darüber hinaus notwendig sind.

Im Detail lässt sich die DevOps-Philosophie auf den bestehenden technischen Releaseprozess in SAP wie folgt übertragen: Die Phase Plan kann beispielweise im SAP Solution Manager durch das Anforderungsmanagement abgedeckt werden. Die Build-Phase spielt sich im ABAP-Editor des jeweiligen Entwicklungssystems ab. Die anschließende Phase, Continuous Integration, wird rudimentär durch das ABAP Test Cockpit, den Code Inspector und den Package Builder unterstützt. Das Deployment erfolgt in der Phase Deploy über den Transport Organizer bzw. das SAP Transport Management System (S T MS). In der Phase Operate kann beispielsweise über das Landscape Virtualization Management (LVM) eine produktive Umgebung automatisiert bereitgestellt und konfiguriert werden. Der Kreis schließt sich wieder in der Phase Continuous Feedback. Das notwendige Feedback aus dem Betrieb kann ebenfalls im SAP Solution Manager dokumentiert und Entwicklern bereitgestellt werden. Damit bietet die SAP schon grundlegende Funktionalitäten an, die jedoch im Rahmen der notwendigen Toolchain bisher nicht integrativ zusammenarbeiten und somit nicht in Gänze das DevOps-Framework unterstützen. Um dies zu erlangen, werden beispielsweise parallelisierbare Prozessfunktionalitäten, integrierte automatisierte Testverfahren und Möglichkeiten zum Aufbau von Testumgebungen inklusive Rollback und Schnittstellen zu Fremdsystemen benötigt.

Technische Architektur: Standardmäßig vorhandene Entwicklungs- und Test-Systeme

Standardmäßig sind meist dreistufige SAP-Umgebungen für Entwicklung (D), Test (Q) und Produktion (P) verfügbar. D- und Q-Systeme werden in SAP-Landschaften, im Gegensatz zu anderen Softwarearchitekturen, nicht auf Adhoc-Anforderung hin provisioniert, sondern in der initialen Installation mitausgeliefert. Das entschärft die Komplexität der Infrastruktur im DevOps-für-SAP-Ansatz, da virtuelle Server nicht als Infrastructure-as-a-Code provisioniert und SAP als Applikation nicht extra installiert werden müssen, sondern bereits verfügbar sind. Deployment, Integration und Konfiguration einer Softwarekomponente werden über das STMS abgebildet. Auf Basis dieser Verteilungslogik zwischen D-, Q- und P-Systemen, ergänzt durch zusätzliche intelligente Automatisierung, lassen sich so agile Entwicklungs- und Betriebsabläufe bereits heute in SAP abbilden.

Transport Management: Automatisiertes Release and Deploy von SAP-Entwicklungen

Eine fertige SAP-Entwicklung ist stets zu testen und anschließend freizugeben, bevor sie dem Produktivbetrieb zur Verfügung gestellt werden kann. Dem Import der Entwicklung in das Q-System folgt ein fachlicher Test und — im Erfolgsfall — die Freigabe zur Produktivsetzung. Dabei liegt der bisherige Prozessfokus auf einem Einhalten der komplexen Genehmigungslogik zum Wohle eines sichereren Betriebs. Jede Produktivsetzung erfordert derzeit eine mehrfache Freigabe.
Innerhalb eines DevOps-für-SAP-Frameworks sollen diese nun einfach, schnell, möglichst ohne Risiko und vermeidbare Genehmigungsschritte von den Entwicklungs- in die Zielsysteme transportiert werden. So ergeben sich drei Ausbaustufen von agilen SAP Development Pipelines. Im Folgenden wird — aus Gründen der Übersichtlichkeit — von einem Transportprozess innerhalb einer einfachen, dreigliedrigen DQP-Landschaft inklusive technischem Test vor Q-lmport und funktionalem Test vor Produktivsetzung ausgegangen. Wünschenswert wäre es, im Falle von Changes mit unkritischen Objekten vollautomatisiert Releases einzuspielen, beispielsweise beim Implementieren von SAP Notes, die auf Objekte zugreifen, die keine unternehmenskritischen Geschäftsprozesse beeinflussen.

Die Ausprägungen der SAP Development Pipelines werden nachfolgend näher beschrieben:

 

 

Die Grundstufe, Continuous Integration, bezeichnet eine Transportautomatisierung zwischen D- und Q- System. Nach Fertigstellung der Entwicklung werden Transportaufträge automatisch in einen vordefinierten Genehmigungsworkflow aufgenommen und in das Q-System importiert. Technische Tests innerhalb der Entwicklung realisieren Qualitätschecks, eine Prüfung auf kritische Objekte, Kollisionen, Versionsüberholer, Objektabhängigkeiten sowie Transportvollständigkeit. Durch zusätzliche Systembenachrichtigungen ist ein direktes Feedback bzw. eine Vorhersage innerhalb des SAP-Systems an die Entwickler über den korrekten Import ihrer Entwicklung in das Q-System abbildbar.

 

 

Die erste Ausbaustufe, Continuous Delivery, beinhaltet einen automatisierten Import des Transportauftrags in das Q-System nach erfolgreich durchlaufenen technischen Tests. Der anschließende Import in die Produktionsumgebung erfolgt nach erfolgreicher Abnahme der funktionalen Tests. Sind alle Testfälle der Testfall-Bibliothek im Test-Management-System erfolgreich durchlaufen und liegt eine Abnahme durch den Testmanager vor, steht einer Produktivsetzung der getesteten SAP-Entwicklung nichts mehr im Weg. Eine weitere Integration in Service Portal und ITSM-Prozesse ermöglichen einen zentral gesteuerten, halb-automatisierten Test basierend auf ITIL. Auf diese Weise ist der gesamte Software-Lebenszyklus abgebildet – von der Anforderung über die Entwicklung und die Tests bis hin zur Produktivsetzung der SAP-Entwicklung.

 

 

Die vollständig automatisierte Lösung aller organisatorischen Genehmigungen inklusive vollautomatisierter Prozessübergänge wird als Continuous Deployment bezeichnet. Die finale Ausbaustufe der SAP Development Pipeline synchronisiert alle Datenquellen der SAP-Entwicklung und nutzt sie zu einer weitestgehenden Automatisierung des STMS. An dieser Stelle werden neben technischen Tests vor Q-Import ebenso fachliche Tests unter Zuhilfenahme des SAP Solution Manager (beispielsweise) und dessen Teststeuerungsfunktionen zur Automatisierung des Transportkonzepts durchgeführt. Dazu kommt eine umfassende Integration bestehender Technologien und Prozesse. Änderungen werden an allen relevanten Datenquellen der SAP-Entwicklung synchron gehalten. Redundanz im Ablauf wird reduziert und das tatsächliche Potenzial der SAP-Landschaft besser ausgeschöpft.

Wünschenswert wäre in diesem Zusammenhang ein Enterprise Layer, das die Integration der SAP-Systemlinie mit unterschiedlichsten Change-Management-Tools ermöglicht.

System Monitoring: Bindeglied zwischen Entwicklung und Betrieb

Der Gedanke eines kontinuierlichen Feedbacks sieht vor, dass Entwickler nach dem Transport ihrer Entwicklungen in das Produktivsystem in Echtzeit Feedback über deren Performance und Einfluss auf den Systembetrieb erhalten.

In SAP-Systemen liegen diese Informationen bereits vor und werden gesammelt, wurden aber in der Vergangenheit nicht automatisch für die Entwickler aufbereitet, sondern der Basis bereitgestellt. In Zukunft müssen performancerelevante KPls im Anschluss an den Import ins Produktivsystem automatisch wieder zum Entwickler gelangen, denn letztendlich wird eben dieser Entwickler seinen Quellcode performancetechnisch optimieren — und dafür benötigt er jene Informationen darüber, wie sich beispielsweise die Antwortzeit einer Eigenentwicklung zusammensetzt, ob eine schlechte Antwortzeit daraus resultiert, dass die sequenziellen Lesezugriffe auf der Datenbank lange dauern, und seit welchem Release die Performance sich verbessert oder auch verschlechtert hat. Ziel ist, die Entwickler zu befähigen, selbständig die Qualität der Entwicklung durch dieses zeitnahe Systemfeedback zu optimieren und die Barriere zwischen Entwicklung und SAP Basis aufzulösen. Dadurch wird nicht nur die Qualität, sondern auch die Geschwindigkeit der Releasezyklen erhöht.

Alle bestehenden implementierten Lösungen von SAP basieren auf dem klassischen Ansatz der getrennten Teams und der daraus resultierenden Arbeitsweise in Silos. Keine Lösung ist durchgängig integriert, sodass dieses DevOps-Framework nicht über alle Phasen hinweg unterstützt wird. So bietet SAP mehrere Möglichkeiten, die beschriebenen Daten hinsichtlich Performance und Qualität der Entwicklungen zu analysieren. Beispielsweise kann die Feedbackphase bereits über das Monitoring und Incident Management des SAP Solution Manager unterstützt werden. Darauf aufbauend ist eine automatisierte Performancemessung möglich und Tickets können an die zuständigen Mitarbeiter weitergeleitet werden. Doch auch dieses Konzept setzt wiederum auf dem klassischen Ansatz auf, dass Entwicklung und SAP Basis getrennt voneinander agieren und dass das SAP Basis-Team die Performance im laufenden Betrieb überwacht und die Entwicklung erst im Problemfall informiert. Nach wie vor ist es erforderlich, dass die Basis den Betrieb der produktiven Systeme sicherstellt. Dazu zählen das kontinuierliche Monitoring der Systeme über SAP-Programme wie die klassischen Transaktionen im System selbst, eine zentrale Monitoring-Lösung über den SAP Solution Manager, die aber auch oftmals durch Lösungen von Drittanbietern unterstützt wird.

Eine weitere zu betrachtende Möglichkeit im SAP Solution Manager ist das sog. Custom Code Management. SAP hat hiermit die Analysen über die Qualität der Eigenentwicklungen auf eine neue Stufe gehoben. Es können verschiedenste Analysen der Eigenentwicklungen vorgenommen und über- sichtlich in einem frei konfigurierbaren Dashboard angezeigt werden. SAP verfolgt damit das Ziel der Annäherung der Kunden zurück an den SAP-Standard, sodass diese wiederum einfacher auf neue innovative SAP-Lösungen migrieren können. SAP-Kunden wird damit eine Möglichkeit zur Verbesserung der Qualität ihrer Eigenentwicklungen in Aussicht gestellt. Dies ist durchaus eine — wenn auch nicht direkt in den Releasezyklus eingebettete — Möglichkeit, dem Entwickler automatisch generiertes Feedback zur Verfügung zu stellen.

Es muss eine landschaftsspezifische Lösung geschaffen werden, die nach dem DevOps-Prinzip die Feedbackphase bestmöglich mit Metriken über die Performance und Qualität in SAP-Landschaften unterstützt und die es dadurch den Kunden ermöglicht, agil zu entwickeln, schnell zu deployen und sofort ein Feedback über die Auswirkungen der Änderung zu erhalten. Das Ziel ist, bei immer kürzeren Releasezyklen die Stabilität des Systems nicht zu beeinträchtigen, darüber hinaus dem Entwickler durch ein nahtlos in den Releasezyklus integriertes Dashboard unmittelbar Feedback zu geben und folglich die Stabilität durch eine höhere Qualität der Eigenentwicklungen zu steigern. Genau auf diese nahtlose Integration über alle Phasen des DevOps-Framework hinweg warten SAP-Kunden bis heute. Stattdessen unterstützt SAP mit guten Lösungen aber nur punktuell im Entwicklunqs- oder Betriebsprozess.

Soziale und technische Integration: Mehrwert durch Vernetzung

Im Rahmen eines DevOps-für-SAP-Frameworks soll eine intensive und offene Feedbackkultur im Unternehmen eingeführt und diese durch die intelligente Vernetzung der bestehenden Tools getragen werden.

Die Automatisierung des STMS im Allgemeinen sowie der Aufbau einer automatisierten Development Pipeline im Speziellen bedeuten implizit auch den Abbau von Genehmigungsworkflows. Ein Teil der bestehenden Kontrollmechanismen innerhalb des SAP-Betriebskonzepts fällt weg. Aufgefangen wird dies durch den Aufbau von interdisziplinären Teams und agilen Kommunikationsstrukturen. De facto erfordert dies beispielsweise einen Einbezug der Basis, QA und InfoSec ab der Grobkonzeption einer Idee für ein Software-Inkrement. Durch die Unterstützung mit einer passenden Toolchain soll der Aufbau eines kollektiven Bewusstseins unter allen SAP-Experten im Unternehmen gefördert werden.

Gemeinsame Kollaborations- und Planungssysteme, wie Jira, SharePoint, Microsoft Teams oder Project, stehen bei der Integration in den SAP-Betriebsablauf im Mittelpunkt. Über deren Anbindung an das hiesige, für SAP Change Requests verantwortliche Ticketsystem bzw. Service Portal lassen sich genehmigte Change Requests in den jeweiligen Tools automatisch in abhängige Aufgaben herunterbrechen und logisch verknüpfen. Sind alle Aufgaben im Planungssystem dann abgeschlossen — und damit auch alle Coding-Tätigkeiten — lässt sich neben dem Transport und damit der Freigabe für QA-Tests auch eine Rückspiegelung in das Service Portal realisieren. So wird sichergestellt, dass nach der Implementierung der benötigten Schnittstellen auch das jeweilige Ticket im Service Portal auf einen neuen Status gesetzt und in Abhängigkeit davon weiter prozessiert wird.

Eine mögliche Verknüpfung zwischen Transportauftrag in SAP und Change Request im Service Portal stellt sicher, dass kein undokumentierter, organisatorisch unerwünschter oder schlicht nicht zuordenbarer Auftrag verarbeitet wird. Durch diese Ende-zu-Ende-lnventarisierung und Synchronisierung aller Datenquellen des Change-Managements, der Scrum-Sprintplanung, der Softwareentwicklung und schließlich des STMS wird der komplette Prozess einer Idee bis zur produktiven Inbetriebnahme abgebildet. Eine kundenspezifische Automatisierung der Prozessübergänge zwischen den einzelnen Systemen verschafft Unternehmen eine höhere Wertschöpfung durch zentrale IT-Systeme und befähigt zum weiteren Wandel von Prozessen und Strukturen.

Der abschließenden Teil der Blog Artikelreihe behandelt das Thema „Start in die DevOps-fähige und integrierte SAP-Landschaft“.

Autoren: Tom Schneider, Technischer Architekt, REALTECH AG | Sören Keuntje, Business Consultant, REALTECH AG

Schreibe einen Kommentar

Your email address will not be published. Required fields are marked *