SOA Continuous Integration

Transkript

1 SOA Continuous Integration Jürgen Broda Continental Automotive GmbH Regensburg Martin Karmann und Daniel Kleine-Albers OPITZ CONSULTING München GmbH München Schlüsselworte SOA, CI, Continuous Integration, Oracle SOA Suite, Tests Einleitung Das Konzept von Continuous Integration ist in der klassischen Softwareentwicklung, z.b. im JEE- Umfeld, etabliert und dessen Vorteile sind dort ohne Zweifel anerkannt. Wie kann man nun dieses erfolgreiche Konzept auf eine SOA-Entwicklung übertragen? Was bedeutet es in diesem Umfeld überhaupt? Welche technischen Voraussetzungen sind nötig, um Continuous Integration auf Basis einer SOA Suite 11g anzuwenden? Welche Vorteile bringt das Vorgehen aus Projektsicht? Dieser Vortrag versucht, diesen Fragen auf den Grund zu gehen und konkrete Hinweise zu geben, wie auch Sie Continuous Integration in Ihrem SOA Projekt anwenden können. Continuous Integration und deren Vorteile Continuous Integration beschreibt den Prozess des regelmäßigen, vollständigen Neubildens und Testens einer Anwendung. Die Idee ist, dass jeder Entwickler seine Änderungen häufig in die zentrale Versionsverwaltung eincheckt, so dass diese laufend ( kontinuierlich ) mit den Änderungen der anderen Entwickler integriert werden und das gesamte System automatisiert getestet wird. Größere Änderungen werden dabei inkrementell in kleinen Portionen entwickelt. Zudem werden geeignete Unit Tests direkt mit dem Code entwickelt. [1] Einige Vorteile, die sich daraus ergeben, sind: Das System ist stets kompilierbar und getestet Probleme bei der Integration fallen schnell auf und nicht erst kurz vor dem Meilenstein Ein lauffähiger Stand ist stets verfügbar und kann für Demo- und Testzwecke verwendet werden Erziehung der Entwickler, Code stets kompilierbar und lauffähig zu halten und in kurzen Intervallen einzuchecken Berichte (z.b. Tests, Codequalität) und Dokumentation (z.b. Javadoc) sind laufend verfügbar Unterstützt agile Vorgehensweisen SOA Anwendungen und deren Besonderheiten Unter einer SOA Anwendung verstehen wir einen Service, der für Konsumenten zur Verfügung steht. Die Besonderheit ist, dass dieser aus mehreren anderen, internen und externen Services komponiert werden kann. Diese weiteren Services werden teilweise unter derselben Hoheit entwickelt, sind aber teilweise auch komplett unabhängig und haben somit getrennte Entwicklungszyklen. Die SOA ist sozusagen ein Kommunikationshub. Eine weitere Besonderheit bei SOA Anwendungen ist, dass die Geschäftslogik nicht programmiert, sondern vorwiegend in BPEL oder BPMN modelliert wird. Daraus ergeben sich einige neue Herausforderungen für eine CI im SOA Umfeld:

2 Dokumentation der Prozesse (BPELdoc?) Granularität der Tests (reine Schnittstellentests? Komponententests?) Abhängigkeit von vielen Fremdservices Bereitstellung einer kompletten Testumgebung Teilweises Fehlen von Toolunterstützung (Testmöglichkeiten, Dokumentation,...) Abbildung 1: Aufbau einer SOA Applikation CI Zutaten für die SOA Suite 11g Um eine CI mit Hilfe der Oracle SOA Suite 11g umzusetzen sind einige Bestandteile nötig: Tests Buildskripte Buildserver Testsysteme Tests sollten in einem Softwareprojekt auf mehreren Ebenen erfolgen. Im Folgenden wird beschrieben, wie die klassischen Unit-, Integrations- und Systemtests auf das SOA Umfeld übertragen werden können. Unit Tests sichern die korrekte Funktion kleiner Bestandteile, z.b. einer Klasse oder einer überschaubaren Gruppe von Klassen. Im SOA Umfeld könnte man Unit Tests z.b. für einzelne XSL-Transformationen oder aber auch für einzelne Services schreiben. Integrationstests testen mehrere Services in Komposition, ohne jedoch von externen Services abhängig zu sein. Diese werden für Integrationstests durch Mocks ausgetauscht. Systemtests testen das Gesamtsystem inklusive der Anbindung an alle externen Systeme. Um Fehler schnell lokalisieren zu können sind Tests auf allen drei Ebenen notwendig wenn z.b. ein Systemtest fehlschlägt, aber keiner der Integrations- und Unittests ist es wahrscheinlich, dass der

3 Fehler an einem externen System oder der Verwendung dessen Schnittstelle liegt. Schlägt hingegen ein Unit Test fehl, liegt der Fehler in der getesteten Unit und kann dort mit Hilfe der Flow Traces der SOA Suite einfach lokalisiert werden. Oracle stellt mit den Composite Tests bereits ein Werkzeug zur Verfügung, mit dem viele Szenarien der Unit- und Systemtests einfach abgebildet werden können. So kann man Testnachrichten erzeugen und an anderen Stellen des Composites Asserts und Mock-Antworten anbringen. Leider ist es damit nicht möglich, auch Integrationstests über mehrere Composites hinweg zu realisieren. Daher hat OPITZ CONSULTING (OC) ein Testframework entwickelt, dass basierend auf JUnit die Möglichkeit bietet, eine beliebige Gruppe an Composites zu testen und beliebig Service-Referenzen einfach und flexibel durch Mocks zu ersetzen (siehe Listing 1). Damit lassen sich alle drei Testarten mit einem Framework realisieren. Ein weiterer Vorteil ist, dass solche Standard-JUnit-Tests direkt aus dem JDeveloper gestartet werden können, was für die Composite Tests leider nicht möglich public void createshouldcallsvcref() { // Mock Service Reference svcref mockcompositereference(comp_name, COMP_REV, "svcref", new MockService() { public String servicecallreceived(string svcname, String requeststr) { if (requeststr.contains("createitem")) { // Assertions on request received by mock assertxpathevaluatesto("//@type", "Issue", requeststr); assertxpathevaluatesto("//username", "Expected_User", requeststr); return xmlu.soapenvelope(readclasspathfile("mockresponse.xml")); else { // Throw a SOAP fault if a wrong request is received by mock throw new ServiceException(xmlu.soapFault("Wrong call", requeststr)); ); // Save a custom file to the composite with placeholders replaced setreplaceproperty("dvmuser", "my_test_username"); String dvm = applyreplacements(readclasspathfile("connections.dvm.xml")); savefiletocomposite(comp_name, COMP_REV, "Connections.dvm", dvm); // Read request and execute String req = xmlu.soapenvelope(readclasspathfile("request.xml")); String res = invokecompositeservice(comp_name, COMP_REV, SVC_NAME, req); String resultbody = xmlu.getsoapbody(res); // Assertions on service reply (body part) assertxpathevaluatesto("//id", "123456", resultbody); assertxpathevaluatesto("//comment", "Comment", resultbody); Listing 1: Composite Unit Test im OC Testframework Da das Reporting bei Tests eine große Rolle spielt, ist zu erwähnen, dass sowohl die Oracle Composite Tests als auch die Tests des OC Frameworks Standard-JUnit-Reports ausgeben, die von gängigen Tools problemlos verarbeitet werden können. Um die Tests auszuführen, sind Testsysteme erforderlich. Zuallererst braucht man eine SOA Suite Instanz für die Tests. Unseren Erfahrungen nach, ist eine komplett eigene Instanz sehr

4 empfehlenswert, da es durch das häufige Deployment der Composites zu Stabilitätsproblemen der SOA Suite und zu Problemen mit der Datenbankgröße kommen kann. Zwingend nötig ist eine eigene Partition auf der SOA Suite, um andere Services, die nicht im Rahmen der CI erstellt werden, nicht zu beeinflussen. Des Weiteren sollten im Idealfall Testinstanzen aller externen Systeme, die von den Services verwendet werden, zur Verfügung stehen. Dadurch ist es möglich, zuverlässige Systemtests zu erstellen, die nicht durch externe Datenveränderungen fehlschlagen. Zudem können so auch problemlos Tests mit Schreibvorgängen in externe Systeme durchgeführt werden. Die Bereitstellung dieser Testsysteme stellt oft die größte Herausforderung bei der Einführung einer CI dar und ist oft schwierig und aufwändig. Alternativ kann man nur lesende Operationen testen und alle anderen Vorgänge werden nur gegen Mocks getestet dadurch verliert man allerdings ein großes Stück Sicherheit, die durch vollständige Tests gegeben wäre. Buildskripte sorgen dafür, dass das Bauen und das Testen einer Anwendung automatisiert möglich ist. In der Oracle Entwicklungsumgebung stehen bereits ANT-Skripte bereit, die Composites automatisch bauen und deployen können und auch die Composite Tests ausführen. Für die CI- Umgebung sind diese Skripte um das Ausführen der JUnit-Tests und der Generierung von Config Plans ergänzt worden. (Letzteres ist mehr ein Komfort-Feature der Config-Plan enthält eine Liste der WSDLs in einem Projekt, auf welche die Search-Replace -Statements angewendet werden. Diese Liste veraltet schnell und führt dann zu einem Nicht-Funktionieren des Plans die Generierung erzeugt diese Liste dynamisch bei jedem Build.) Der Buildserver hat die Aufgabe, nach bestimmten Regeln (z.b. zeitgesteuert oder bei Änderungen am Source Code) einen Build zu starten, diesen auszuführen und ggf. Nachbereitungsaufgaben (z.b. Bereitstellung von Test-Reports, Benachrichtigung von Projektteilnehmern) vorzunehmen. Grundsätzlich kommt hier jeder CI-Server in Frage, der ANT-Skripte ausführen kann. Wir haben sehr gute Erfahrungen mit Hudson / Jenkins gemacht. Eine große Herausforderung bei der Konfiguration des Buildservers ist, dass die Abhängigkeiten zwischen den Services korrekt abgebildet werden. So sollte verhindert werden, dass abhängige Services gebaut werden, bevor deren Abhängigkeiten gebaut wurden. Das könnte dazu führen, dass Tests fälschlicherweise fehlschlagen, obwohl die Funktionalität in den jeweils neuesten Versionen gegeben ist. Abbildung 2: Buildablauf auf dem Buildserver

5 Erkenntnisse im Kundenprojekt In einem Projekt zur Integration von verschiedenen in der Produktentwicklung genutzten Applikationen konnte der oben beschriebene Ansatz erfolgreich eingesetzt werden. Der Hudson-CI- Server wurde dabei bereits in einer sehr frühen Phase des Projekts aufgesetzt und dessen Verwendung im Projektverlauf schrittweise ausgebaut. Der CI-Server ließ sich ohne Probleme und mit geringem Aufwand installieren. Auch die Anbindung an das beim Kunden verwendete Konfigurationsmanagementsystem war ohne weiteres möglich. Eine Herausforderung im Projekt war die Verfügbarkeit einer vollständigen und stabilen Testumgebung. Die kontinuierliche und automatisierte Testausführung durfte nicht durch Weiterentwicklung der integrierten Applikationen beeinflusst werden. Aus diesem Grund wurde eine Testinfrastruktur aufgesetzt, welche jede Applikation in allen freigegebenen Versionen beinhaltet. Neben dem technischen Aufbau einer CI Umgebung erfolgte auch die Verankerung in den internen Entwicklungsprozessen. Die Ergebnisse der Tests wurden nahtlos in das Testmanagement integriert, auftretende Fehler werden im Rahmen des Change- und Problemresolutionmanagement direkt an den Entwickler und das Projektteam zurückgespielt. Der größte Mehrwert des Continuous Integration konnte im Zusammenspiel mit dem Anforderungsmanagement erzielt werden. Im Projekt wird jede Anforderung durch mindestens einen Testfall abgedeckt. Die Beziehung zwischen Testfall und Anforderung ist im System hinterlegt und für den verantwortlichen Requirements Engineer ersichtlich. Durch die automatisierte und kontinuierliche Ausführung der Testfälle hat dieser zu jeder Zeit einen aktuellen Stand bezüglich der erfolgreichen Umsetzung seiner Anforderungen. Zusammengefasst kann man sagen, dass die technischen Hürden zur Implementierung von CI eher gering sind. Eine Herausforderung stellt die Integration des CI in die internen Entwicklungsprozesse dar. Je besser CI in die Entwicklungsprozesse eingebunden und je höher der Reifegrad der Entwicklungsprozesse ist, desto größer ist der Nutzen im Projekt. Quellen [1] Kontaktadresse: Daniel Kleine-Albers OPITZ CONSULTING München GmbH Weltenburger Str. 4 D München Telefon: +49 (0) Fax: +49 (0) daniel.kleine-albers@opitz-consulting.com Internet: