DOAG SOA Continuous Integration · Was bedeutet Continuous Integration? Automatische regelmäßige...

Jürgen Broda

DOAG Konferenz 2011

SOA Continuous Integration

© OPITZ CONSULTING GmbH 2010 Seite 1SOA Continuous Integration – DOAG 2011

Continental Automotive GmbH

Martin Karmann,Daniel Kleine-AlbersOPITZ CONSULTING München GmbH

Nürnberg, 15.11.2011

Agenda

1. Continuous Integration im SOA Umfeld

2. SOA CI Zutaten� Tests� Buildskripte� Buildserver� Testsysteme

© OPITZ CONSULTING GmbH 2010 Seite 2SOA Continuous Integration – DOAG 2011

� Testsysteme

3. Nutzen im Projekt

Was bedeutet Continuous Integration?

� Automatische regelmäßige Builds

� Entwicklungsstände werden täglich eingecheckt

� Zentrales Code Verwaltungssystem für eine gemeinsame Codebasis

� Unit-Tests werden zusammen mit dem Code erstellt

© OPITZ CONSULTING GmbH 2010 Seite 3SOA Continuous Integration – DOAG 2011

� Unit-Tests werden zusammen mit dem Code erstellt

� Tests werden automatisiert ausgeführt

� Testreports werden automatisch erstellt und veröffentlicht

� Automatische Dokumentation

Was bringt mir CI für eine SOA?

� Jederzeit compilierbare Codebasis (Service compiliert)

� Deployments in kleinen Iterationen (Service ist deploybar)

� Immer verfügbare Testergebnisse (Service funktioniert)

� Automatisiertes Reporting (Service ist dokumentiert)

© OPITZ CONSULTING GmbH 2010 Seite 4SOA Continuous Integration – DOAG 2011

� Erzieherische Effekte!

� Unterstützt agile Vorgehensweisen

Was macht eine SOA Applikation aus?

Ext.

Service

User InterfaceBatch Server

Ext.

Service

Fro

nte

nd

Mid

dle

war

e

Web Service

BPEL

© OPITZ CONSULTING GmbH 2010 Seite 5SOA Continuous Integration – DOAG 2011

Service

Int.

Service

Backend

Int.

Service

Service

Int. Storage

Backend

Bac

ken

dM

idd

lew

are

BPEL

Was macht eine SOA Applikation aus?

� Applikationen sind autonome Services

� SOA als Kommunikationshub

� Heterogene Systemlandschaft

� Heterogene fachliche Anforderungen

� Geschäftslogik modelliert als BPEL/BPMN Prozess

© OPITZ CONSULTING GmbH 2010 Seite 6SOA Continuous Integration – DOAG 2011

� Geschäftslogik modelliert als BPEL/BPMN Prozess

� Auch hier: Planung, Entwicklung, Test, Deployment

� => Neue Herausforderungen an eine CI

Herausforderungen an eine SOA CI

� Abhängigkeiten� Fremdservices / -systeme� Infrastruktur (Verfügbarkeit u. Performance)

� Testen� Testumgebung� Integrationstests

© OPITZ CONSULTING GmbH 2010 Seite 7SOA Continuous Integration – DOAG 2011

� Integrationstests

� Dokumentation� BPEL Prozesse� Servicebeschreibungen

� Toolunterstützung

Tests

� Testklassen� Unit Tests – einzelne Services (Service Tests) und einzelne Komponenten� Integration Tests – mehrere Services in Komposition� System Tests – mit allen angebundenen Systemen

� Oracle Composite Tests� Kann für System Tests und Service Tests verwendet werden

© OPITZ CONSULTING GmbH 2010 Seite 8SOA Continuous Integration – DOAG 2011

� Kann für System Tests und Service Tests verwendet werden� Nicht für Integration Tests über mehrere Composites

� Eigenes Testframework� Für Unit, Integration und System Tests� Erlaubt Mocking von Service Referenzen (auch über mehrere Composites

hinweg)� Tests als JUnit-Tests -> Vorteile bei IDE-Integration und Reporting

Tests

@Test

public void shouldCreateNewIssue() {

mockCompositeReference(COMP_NAME, COMP_REV, REF_NAME, new MockService() {

public String serviceCallReceived(String serviceName, String req) {

if (req.contains("createItem") && req.contains("Issue")) {

assertXpathEvaluatesTo("//@Type", "Issue", req);

return xmlu.soapEnvelope(readClasspathFile("MockResponse_CreateItem.xml"));

} else {

© OPITZ CONSULTING GmbH 2010 Seite 9SOA Continuous Integration – DOAG 2011

} else {

throw new ServiceException(xmlu.soapFault("Call not supported", req));

}

}

});

String req = xmlu.soapEnvelope(readClasspathFile("Request.xml"));

String res = invokeCompositeService(COMP_NAME, COMP_REV, SVC_NAME, req);

String resBody = xmlu.getSoapBody(res);

assertXpathEvaluatesTo("//im:id", "13540", resBody);

}

Testsysteme

� Um testen zu können werden Testsysteme aller an der SOA beteiligten Systeme benötigt� Oft schwierig und aufwändig� Alternative evtl.: nur lesende Operationen testen, andere nur „gemockt“

� Eigene SOA Suite Instanz empfehlenswert� Erfahrung: Stabilitätsprobleme durch häufiges Deployment; Probleme mit

© OPITZ CONSULTING GmbH 2010 Seite 10SOA Continuous Integration – DOAG 2011

� Erfahrung: Stabilitätsprobleme durch häufiges Deployment; Probleme mit Datenbankgröße

� Alternativ: nur eigene Partition

Buildskripte

� Ant-Skripte für Composite Build und Deployment gehören zum JDeveloper Lieferumfang

� Ergänzt um Ausführung von Standard-JUnit-Tests und Config-Plan-Generierung

© OPITZ CONSULTING GmbH 2010 Seite 11SOA Continuous Integration – DOAG 2011

Buildserver

� Hudson / Jenkins

� Führt nach bestimmten Regeln den Build aus� Zeitgesteuert� Bei Änderung am Source Code

� Reporting über Testfälle und Testergebnisse

© OPITZ CONSULTING GmbH 2010 Seite 12SOA Continuous Integration – DOAG 2011

� Herausforderung: Abhängigkeiten zwischen Services müssen korrekt abgebildet werden (falls nicht zeitgesteuert)

Buildablauf Hudson

Config. Mgmt.

System

Externe

TestsystemeExterne

Testsysteme

Bu

ildse

rver

Artefakt (SAR)

SOA Suite

Testergebnisse

© OPITZ CONSULTING GmbH 2010 Seite 13SOA Continuous Integration – DOAG 2011

Nachbearbeitung

Hu

dso

n B

uild

serv

er

Buildskripte

Artefakt (SAR)

Holt Source Code Erstellt Deployt

Testet

Testergebnisse

Trigger

Stellt bereit

Projektdarstellung

� Integrationsprojekt im Bereich der Produktentwicklung auf Basis einer serviceorientierten Architektur

� Continuous Integration wurde frühzeitig im Projekt aufgesetzt

� Continuous Integration Server lies sich schnell und unkompliziert aufsetzen

© OPITZ CONSULTING GmbH 2010 Seite 14SOA Continuous Integration – DOAG 2011

unkompliziert aufsetzen

� Anbindung an das Configuration Management System problemlos möglich

Herausforderungen

� Verfügbarkeit ausreichender und versionsstabiler Testsysteme

� Technisch stabile SOA Suite

� Notwendigkeit eines eigenen Testframeworks

� Verankerung der Ergebnisse aus den Integrationstests in

© OPITZ CONSULTING GmbH 2010 Seite 15SOA Continuous Integration – DOAG 2011

� Verankerung der Ergebnisse aus den Integrationstests in den internen Entwicklungsprozessen

Nutzen

� Auswirkungen von Änderungen an Komponenten auf die Servicekonsumenten lassen sich sehr schnell testen

� Zeitnahes Feedback an den Entwickler und das Projektteam

� Schnelle und umfassende Regressionstests

� Aktueller Überblick über den Testverlauf im Bezug auf die

© OPITZ CONSULTING GmbH 2010 Seite 16SOA Continuous Integration – DOAG 2011

� Aktueller Überblick über den Testverlauf im Bezug auf die Anforderungen

Fazit

� Continous Integration beginnt nach der Installation eines Buildservers� Technische Implementierung der Testautomatisierung mit geringem Aufwand

möglich� Prozesstechnische Verankerung im Unternehmen als Herausforderung

� Continous Integration ist in einer SOA unverzichtbar

© OPITZ CONSULTING GmbH 2010 Seite 17SOA Continuous Integration – DOAG 2011

� Je höher der Reifegrad der Entwicklungsprozesse desto höher der Nutzen von Continous Integration

� Je stärker die Verankerung von Continous Integration in den Entwicklungsprozess desto höher der Nutzen

Diskussion

© OPITZ CONSULTING GmbH 2010 Seite 18SOA Continuous Integration – DOAG 2011

Kontakt

Martin Karmann

Jürgen BrodaJuergen.Broda@continental-corporation.comTelefon: +49 941 790-79726Mobil: +49 160 7452566

© OPITZ CONSULTING GmbH 2010 Seite 19SOA Continuous Integration – DOAG 2011

Martin.Karmann@opitz-consulting.comTelefon: +49 89 680098-1486Mobil: +49 173 3883421

Daniel Kleine-AlbersDaniel.Kleine-Albers@opitz-consulting.comTelefon: +49 89 680098-1473Mobil: +49 173 7276088