Releasemanagement in Integrationsprojekten für den OSB Sven Bernhardt OPITZ CONSULTING Deutschland GmbH Gummersbach Schlüsselworte Integration, Middleware, Service Bus, Releasemanagement Einleitung In komplexen Systemlandschaften ist ein konsistentes Releasemanagement notwendig, um die Robustheit des Systems sicherzustellen und auch auf lange Sicht agil auf sich verändernde Anforderungen reagieren zu können. Automatisiertes Testen, Builden und Deployen sind in diesem Zusammenhang schon lange State-of-the-Art. In lose gekoppelten Integrationsarchitekturen ist dies gleichermaßen wichtig und aufgrund des hohen Verteilungsgrades der entsprechenden Systeme und Komponenten entsprechend komplex. Wie die in diesem Zusammenhang auftretenden Herausforderungen gemeistert werden in einem realen Projekt, in dem es um die Modernisierung der zentralen Integrationsplattform des Kunden ging, gemeistert werden können, soll in diesem Vortrag gezeigt werden. Bedeutung von Integrationsarchitekturen Das Thema Integration ist nichts Neues. Angefangen bei dem häufig vorzufinden Anti-Pattern der direkten Point-to-Point Integrationen, über das Thema Enterprise Application Integration (EAI) bis hin zu Service-orientierten Architekturen (SOA) oder gar Event-getriebenen Architekturen (EDA); Integration war stets ein Thema das IT Organisationen beschäftigt hat. Was sich bezüglich des Themas über die Jahre allerdings verändert hat, sind Priorität und Nutzen für Unternehmen. Wurde Integration bis vor nicht allzu langer Zeit noch als ein notwendiges Übel gesehen, das Kosten verursacht und nicht wertschöpfend für das Unternehmen ist, wendet sich das Blatt zusehends. Integration ist heute ein Wegbereiter für verschiedene Themen und erlaubt es den entsprechenden Anwenderunternehmen neue Konzepte und Technologien schnell zu adaptieren und zu implementieren, was bezogen auf ein nachhaltiges Wachstum eine Notwendigkeit ist, um sich langfristig im Wettbewerb behaupten zu können. Themen wie Operational Excellence oder Cost Leadership werden dabei immer bedeutsamer für die Unternehmen. Referenzarchitektur mit zentralem Integrationsplattform Eine zentrale Integrationsplattform ist notwendig, um die Flexibilität sowie die Agilität einer IT Systemlandschaft sicherstellen zu können. Abbildung 1 zeigt ein entsprechendes Beispiel, wie eine solche Referenzarchitektur aussehen kann. Wie der Abbildung zu entnehmen ist, ist die Erweiterung und Verbindung unterschiedlichster Applikationen über eine zentrale Buskomponente möglich. Neue Konzepte wie beispielsweise Cloud, Mobile oder Internet of Things (IoT) können hierdurch problemlos und wertschöpfend in eine existierende Anwendungslandschaft integriert werden. Neben den im vorherigen Abschnitt genannten Hypethemen bildet eine zentrale Integrationsplattform ebenfalls eine wichtige Grundlage für weitere und bereits länger am Markt existierende Themen wie das Business Process Management (BPM), deren tatsächlicher Nutzen sich erst dann entfalten kann, wenn die entsprechenden Voraussetzungen dafür existieren. Diese sind zum Beispiel in Services
gekapselte, wiederverwendbare Businessfunktionalitäten, welche über die Integrationsplattform virtualisiert werden und so für verschiedene Konsumenten bereitgestellt werden können. In der Integrationsplattform können dann Querschnittsfunktionalitäten, wie Security, Message Throtteling, SLA Management, etc. an zentraler Stelle durchgeführt werden. Abbildung 1: Referenzarchitektur mit einer zentralen Integrationsplattform Die Quintessenz: Integration ist nicht länger notwendiges Übel, sondern Innovationstreiber! Unternehmen, die keine langfristige Integrationsstrategie haben, werden über kurz oder lang in arge Nöte kommen, mit der technologischen Evolution Schritt halten zu können und somit wichtige Differenzierungsmerkmale gegenüber dem Wettbewerb einbüßen. Besondere Herausforderungen an Test- und Releasemanagement Test- und Releasemanagement sind wichtige Teildisziplinen innerhalb des Application Lifecycle Management. In klassischen Entwicklungsprojekten, in welchen zum Beispiel Enterprise Applikationen auf Basis von JEE entwickelt werden haben sich diverse Ansätze entwickelt, wie Test und Release kontinuierlich und vor allem auch nahezu auf Knopfdruck automatisiert erfolgen können (Stichwort: Continous Integration und Contoinous Delivery). In Integrationsprojekten sind diese Ansätze nicht 1:1 und einfach adaptierbar. Gründe hierfür sind unter Anderem: Höhere Komplexität durch loose Kopplung o Verteilung beteiligter Komponenten o Abhängigkeiten von Services durch Wiederverwendung Komplexe Laufzeitumgebungen Isolierte Komponententests schwierig umsetzbar Simulieren/Einbeziehung beteiligter Systeme o Herstellen benötigter Systemzustände vs. Mocking o Komplexe Schnittstellen o Proprietäre Protokolle
Die Liste lässt sich sicher noch erweitern, jedoch wird klar, welche Herausforderungen sich in Integrationsprojekten im Bezug auf das Test- und Releasemanagement ergeben. Real World Integrationsszenario Grundsätzlich ging es um die Ablösung der bestehenden Integrationsplattform, welche in die Jahre gekommen war und die Umsetzung neuester Standards sowie Konzepte nicht mehr erlaubte. Durch die Modernisierung der Integrationsplattform erreicht der Kunde die Senkung von Betriebs- sowie Entwicklungskosten und ist so hinsichtlich neuer Anforderungen zukunftssicher aufgestellt. Die entwickelte Lösung dient unter anderem der Anbindung von Kunden und Dienstleistern zur Unterstützung der Ticketing Prozesse. Aktuell werden mehr als 70 Millionen Nachrichten pro Jahr prozessiert Tendenz steigend. Durch die modernisierte Integrationsplattform wird die Skalierbarkeit und Erweiterbarkeit für die Zukunft gewährleistet. Die veraltete Technologiebasis wurde abgelöst und die durchschnittliche time to market massiv verkürzt. Im Folgenden soll anhand dieses Szenarios gezeigt werden wie ein konsistenter Ansatz für ein Buildund Releasemanagement in einem komplexeren Integrationsszenario aussehen kann. Technologische Grundlage für das Projekt ist der Oracle Service Bus 11g (OSB), welcher als zentrale Integrationsplattform zum Einsatz kommt. Systemarchitektur Die unten stehende Abbildung zeigt die Architektur der neuen Integrationsplattform aus einer Highlevel Perspektive. Abbildung 2: Architektur Integrationsplattform Die Plattform besteht aus zwei hochverfügbaren OSB Domänen, einer internen und einer externen, welche Nachrichten in verschiedensten Formaten, über unterschiedliche Protokolle empfangen und verarbeiten kann. Da die externe Domäne über das Internet von außen erreichbar ist, ist die
Integrationslogik rein in der internen Domäne implementiert. Da die Integrationsplattform grundsätzlich den Anspruch hat zustandslos zu sein, ein Nachrichtenverlust aber in jedem Fall zu verhindern ist, kommt JMS für die Persistierung der empfangenen Nachrichten zum Einsatz, um im Falle der nicht Verfügbarkeit eines Zielsystems die Nachricht erneut zustellen zu können. Kernkomponenten der Nachrichtenverarbeitung sind: Dynamische syntaktische Transformationen (TransformCdm-Komponente) Wertübersetzungen (ModifyAndEnrich Komponente) Nachrichtenrouting von der Quelle zum Ziel Die Verarbeitungslogik ist dynamisch und unter zur Hilfenahme wiederverwendbarer Komponenten realisiert, sodass die Anbindung neuer Kunden oder Dienstleister einfach möglich ist. Testansatz Um die Kernkomponenten robust zu machen und die Funktionsfähigkeit im Falle von Änderungen gewährleisten zu können wurden verschiedene Arten von Tests definiert, welche bei der Implementierung neuer Schnittstellen bzw. dem Aufschalten neuer Kunden oder Dienstleister zu implementieren waren. Die Implementierung der entsprechenden Tests wurde mit dem OC SOA Testing Framework durchgeführt, welches in unterschiedlichen Projektkontexten erstellt, erweitert und entsprechend gehärtet wurde. Das Framework bietet Funktionalitäten, wie Mocking von Services, Testen von XSL und Xquery Transformationen sowie die Validierung mittels XPATH ausdrücken an, um unterschiedliche Aspekte eines solchen Projektes auf Basis der Oracle SOA Plattform abdecken zu können. Abbildung 3: Testarten Wie die Grafik zeigt, werden unterschiedliche Arten von Test definiert, welche sich bezüglich Granularität, Ausführungsdauer und Zeitpunkt sowie der Testabdeckung unterscheiden. Die Tests sind dabei nicht strikt voneinander isoliert sind, sondern Überschneidungen aufweisen. Dennoch haben die Tests je einen unterschiedlichen Fokus, der von den Entwicklern im Augen behalten werden muss, wenn es um die Definition der entsprechenden Assertions geht. Ungeachtet dessen ist das Hauptziel dieses Ansatzes Fehler so früh wie möglich festzustellen, um frühzeitig reagieren zu können.
Build und Releasevorgehen Das Vorgehen bei Build und Release ist in der unten stehenden Abbildung skizziert. Nachdem ein Entwickler die Entwicklung eines Features abgeschlossen hat, werden die Änderungen am Code in das Source Control System (SCS) eingecheckt, in diesem Falle MKS. Danach startet der Entwickler einen entsprechenden Build Job der zunächst die Xquery Tests ausführt und im Anschluss den eigentlichen Build startet. Im Anschluss daran wird dann der Deployment Prozess über den Jenkins Server gestartet und das Feature auf der DEV Umgebung ausgerollt. Im Anschluss an das Deployment werden die entsprechenden Post-Deploy Tests ausgeführt. Sind auch diese erfolgreich so wird das Feature für fachliche Test auf der INT Umgebung freigegeben und dorthin transportiert. Im Anschluss an die erfolgreichen fachlichen Tests wird das Feature für die PROD Umgebung freigegeben und zu gegebener Zeit deployt. Abbildung 4: Build und Releasevorgehen Die Abwicklung des skizzierten Lifecycles wird systemtechnisch für das MKS abgebildet. D.h. im Falle von Fehlern geht das Feature zum Zwecke von Bugfixes zurück an den jeweiligen Entwickler. Fazit Mit Hilfe des beschriebenen Vorgehens ist es möglich die zentrale Integrationsplattform sehr stabil und robust zu betreiben und zu erweitern. Selbst Refactorings an zentralen Komponenten bedeuten dank des engmaschige Netz von Tests kein hohes Risiko für die Gesamtstabilität der Lösung. Für den Kunden bedeutet dies, dass die zentrale Integrationsplattform vorhanden ist, auf welche weiter aufgebaut werden kann, um nachhaltig und langfristig Wachsen zu können.
Kontaktadresse: Sven Bernhardt OPITZ CONSULTING Deutschland GmbH Kirchstraße 6 D-51647 Gummersbach Telefon: +49 (0) 2261-6001 0 Fax: +49 (0) 172-219 3529 E-Mail sven.bernhardt@opitz-consulting.com Internet: www.opitz-consulting.com