Open Source Continuous Integration und Testing

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1. Einführung
1.1. Problemstellung
1.2. Zielformulierung
1.3. Anforderungen an das Projekt
1.4. Struktur der Arbeit
1.5. Methodik

2. Einführung in Continuous Integration Systeme
2.1. Versionsverwaltung
2.2. Continuous Integration Server (Marktanalyse)
2.2.1. Ranking
2.3. Build-Werkzeuge

3. Testen in einem CI System
3.1. Grundlagen des Softwaretestens
3.2. Marktanalyse der einzelnen Testwerkzeuge
3.2.1. Modultest
3.2.2. Das Testen von Weboberflächen

4. Metriken der Softwarequalität
4.1. Sonar als Werkzeug zum Messen von Metriken
4.2. Weitere Coding Rule Engines
4.3. Richtiger Einsatz von Softwaremetriken

5. Veränderung der Testprozesse in einem CI System
5.1. Manuelles Testen
5.2. Testautomatisierung
5.3. Testen in einer Continuous Integration Lösung
5.4. Evaluation der verschiedenen Testprozesse

6. Vorgehen bei Einführung von CI in ein Unternehmen
6.1. Phase Eins: kein CI Server
6.2. Phase Zwei: Nightly Builds
6.3. Phase Drei: Nightly Builds und Automatisiertes Testen
6.4. Phase Vier: Einführung von Metriken
6.5. Phase Fünf: Erweiterung der Builds durch Deployment
6.6. Phase Sechs: Automatisierte Akkzeptanztests
6.7. Phase Sieben: Continuous Delivery
6.8. Zusammenspiel von Prozessen, Menschen und Werkzeugen

7. Konzept für eine Continuous Integration Infrastruktur
7.1. Aufbau einer Continuous Integration-Umgebung
7.1.1. Apache Tomcat als Applikationsserver
7.1.2. Subversion als Versionsverwaltungswerkzeug
7.1.3. Jenkins als Continuous Integration-Server
7.1.4. Ant als Buildmanagement-Werkzeug
7.1.5. Sonar und Selenium als Qualitätsmanagement- und Testwerkzeuge
7.1.6. Eclipse IDE auf dem Client
7.1.7. Java Webapplikation zur Demonstration
7.1.8. Umgebungsvariablen des Systems
7.1.9. Freigaben der Ports
7.1.10. Aufbau des Jenkins Workspace
7.2. Prozesse in der Umgebung
7.2.1. Einchecken von Änderungen an der Softwarekonfiguration
7.2.2. Abfragen von Änderungen am Repository
7.2.3. Bauen und Testen der Applikation
7.2.4. Bereitstellung der gebauten Applikation

8. Evaluierung
8.1. Continuous Integration verändert das Produkt
8.2. Continuous Integration verändert die Prozesse

9. Fazit und Empfehlung für das Unternehmen

10. Anhang
10.1. Anhangverzeichnis

11. Quellenverzeichnis
11.1. Literaturverzeichnis
11.2. Internetquellen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Continuous Integration Ablauf

Abbildung 2: Jenkins Oberfläche

Abbildung 3: Projektgruppen Übersicht in Continuum

Abbildung 4: Relative Kosten der Fehlerbeseitigung

Abbildung 5: Abbildung xy: Darstellung der Zyklomatische Komplexitätsformel

Abbildung 6: Dashboard von Sonar

Abbildung 7: Testprozess für das manuelle Testverfahren

Abbildung 8: Testprozess in bei Testautomatisierung

Abbildung 9: Testprozess in einer CI-Lösung

Abbildung 10: Phasenweise Entwicklung und Standpunkt des Auftrag gebenden Unternehmens

Abbildung 12: Das Dreieck von Continuous Integration

Abbildung 13: Komponenten in der CI-Umgebung

Abbildung 14: Komponenten und Prozesse in der CI-Umgebung

Tabellenverzeichnis

Tabelle 1: CI-Server Funktionalitäten im Vergleich

Tabelle 2: Gewichtung der Kriterien an CI-Server

Tabelle 3: Ranking der CI-Server

Tabelle 4: Gewichtung der Kritierien für Testwerkzeuge

Tabelle 5: Ranking der Testwerkzeuge

Tabelle 6: Gewichtung der Kriterien für Weboberflächentest

Tabelle 7: Ranking der Werkzeuge für Oberflächentests

Tabelle 8: Umgebungsvariablen des Systems

Tabelle 9: Portfreigaben

1. Einführung

1.1. Problemstellung

Heutzutage wird Software zunehmende von global verteilten Teams entwickelt, die aus mehreren Entwicklern bestehen. Obwohl bereits von vielen Entwicklerteams die Methodik der agilen Softwareentwicklung erfolgreich angewandt wird, gibt es bei der Integration der einzelnen Prozessschritte immer noch Lücken und Verbesserungsbedarf. Die einzelnen Werkzeuge zur Unterstützung der Softwareentwicklung und insbesondere zum Testen werden in vielen Projekten als Einzelsysteme verwendet, wie beispielsweise ein isoliertes Versionsverwaltungssystem zum Einfügen von Codeteilen in das Gesamtprojekt. Dies führt dazu, dass fehlerhafter Code leicht in den primären Entwicklungszweig integriert werden kann. Da die Integration der einzelnen Softwarebausteine häufig zu Fehlern und Problem führt, wird diese von den Entwicklern gerne möglichst weit hinausgezögert. Kurz vor einem Release kommt es häufig zu einem sogenannten „Big Bang“ also einem Fehler-Urknall, welches häufig zu kostenintensiven Nacharbeiten und Zeitverzögerungen führt. Dabei ist es offensichtlich, dass die relativen Kosten zur Fehlerbeseitigung unverhältnismäßig steigen, je später ein Fehler gefunden wird.

Um genau diesen „Big Bang“ zu vermeiden wird zunehmend das Konzept von Continuous Integration in der Softwareentwicklung angewandt. Eines der Prinzipien der agilen Softwareentwicklung ist es stets ein funktionales Produkt bereitzustellen. An genau dieses Prinzip soll in dieser Arbeit angeknüpft werden. Durch Automatisierung und vollständige Integration von Versionsverwaltung, Build-Prozessen, Unit-Testen, Quellcodeanalyse und ständige Auswertungen wird dieses Prinzip umgesetzt und gefördert. So kann bereits durch das Einchecken von Code eines Entwicklers ein hoch automatisierter Prozess angestoßen werden. Das Resultat eines solchen Prozess ist eine komplett gebaute Software sowie ausführliche Ergebnisse aus Tests und Quellcodeanalysen. Schon dieser kleine Ausschnitt zeigt, dass es sich um ein äußerst komplexes, aber auch gewinnbringendes und interessantes Konzept handelt.

1.2. Zielformulierung

Das Projekt wurde in Auftrag gegeben, um für ein Unternehmen das Konzept und die Hintergründe einer Continuous Integration Lösung darzustellen. Dies soll zum Einen anhand einer schriftlichen Ausarbeitung geschehen, zum anderen anhand eines Prototypens in die Praxis umgesetzt und erprobt werden. Der Hauptaspekt liegt dabei auf der praktischen Umsetzung.

Ziel der schriftlichen Ausarbeitung ist, das Konzept einer Continuous Integration (CI) Lösung, sowie die einzelnen Komponenten im Open Source Bereich vorzustellen und kritisch zu hinterfragen. Zur Übersicht der verfügbaren Open Source CI- Server und Test Werkzeuge soll eine kurze Marktanalyse erstellt werden. Hierbei ist die Anforderungen des Unternehmens einen groben Überblick über die aktuellen Vertreter auf dem Open-Source Markt zu geben.

Bei der Erstellung eines Konzepts zum Aufbau einer Toollandschaft, soll neben der technischen Umsetzung auch das phasenweise Vorgehen zur Implementierung eines CI-Prozesses im Unternehmen eingegangen werden, insbesondere welche Veränderungen für die Entwickler entstehen.

Ein weiteres Ziel ist es den Mehrwert einer CI-Lösung, für die einzelnen Entwickler und das Unternehmen darzustellen. Es soll gezeigt werden, wie die Softwarequalität mit einer CI-Lösung sichergestellt und optimiert werden kann. Hierbei wird insbesondere der Aspekt des Softwaretestens in einer CI-Lösung beleuchtet. Es soll gezeigt werden, inwiefern sich die Testprozesse innerhalb einer CI-Lösung für den Entwickler verändern.

1.3. Anforderungen an das Projekt

Um das theoretische Konzept hinsichtlich der Umsetzbarkeit zu überprüfen, ist das hauptsächliche Ziel des Projekts, für das Auftrag gebende Unternehmen einen Prototyp zu erstellen. Hierbei ist bei der Auswahl der verschiedenen Komponenten auf die Anforderungen des Auftraggebers einzugehen.

Das Unternehmen zieht in Betracht seine Java Projekte zukünftig in einer Continuous Integration Lösung zu entwickeln. Hierbei möchte es sich nur auf Open Source Produkte stützten. Im Moment verwendet das Unternehmen das Versionskontrollsystem Subversion, das Build-Werkzeug Ant und das Testwerkzeug JUnit. Daraus ergibt sich die Anforderung eines CI-Systems das möglichst auf den bereits genutzten Werkzeugen aufbaut.

Die Anforderungen an die schriftliche Ausarbeitung bestehen darin dem Unternehmen eine Einführung in das Thema Continuous Integration zu geben und besonders das Vorgehen der Implementierung eines CI-Systems darzustellen - am besten anhand der praktischen Erfahrungen die während der Entwicklung des Prototypen gemacht wurden. Das Unternehmen ist daran interessiert zu erfahren, wie hoch der Aufwand einer Implementierung eines CI-Systems ist und welchen genauen Nutzen es dem Unternehmen stiftet.

1.4. Struktur der Arbeit

Im theoretischen Teil dieser Arbeit werden zunächst die Grundlagen von Continuous Integration Systemen eingeführt. Darunter finden sich auch die verschiedenen Komponenten, aus welchen eine CI Lösung aufgebaut ist. Die verschiedenen Anbieter von Continuous Integration Servern sowie von whitebox-Testframeworks und UI-Testframeworks im Open Source Bereich werden anhand ihrer Funktionalitäten miteinander verglichen und die vorteilhaftesten Tools für das Konzept ausgewählt.

Da das Testen von Software in CI-Lösungen eine besonders wichtige Rolle spielt, sind die Grundlagen des Testens ebenfalls kurz dargestellt. Die Vorteile der Testautomatisierung im Allgemeinen und insbesondere in einer CI-Lösung werden anhand von Prozessabläufen dargestellt. Es wird gezeigt wie alle Teststufen mithilfe eines CI-Systems automatisiert getestet werden können.

Im Anschluss wird das Vorgehen der Einführung einer CI-Lösung in einem Unternehmen zunächst theoretisch dargestellt und daraufhin anhand eines technischen Konzepts auch in der Praxis erläutert. Zuletzt wird der Einsatz eines CI-Systems hinsichtlich der Anwendung im Unternehmenskontext bewertet und ein Fazit für den Auftraggeber gezogen.

1.5. Methodik

Die Vorgehensweise zur Erstellung dieser Seminararbeit ergibt sich aus der Anforderungen an das Projekt, welche vor allem eine praktische Ausarbeitung vorsehen. Der theoretische Teil dieser Arbeit umfasst auch eine Literaturrecherche bei der vor allem Fachbücher, Magazine aber auch Internetartikel einbezogen wurden. Um die Vertreter der verschiedenen Werkzeuge anhand einer groben Marktanalyse miteinander zu vergleichen wurden Kriterien sowohl aus der Literatur als auch aus den Kundenanforderungen zusammengestellt. Alle Werkzeuge, die im praktischen Teil dieser Arbeit beschriebenen werden wurden während der Erstellung des Prototyps in Form praktischer Arbeit analysiert, bewertet und genutzt. So können insbesondere – aber nicht ausschließlich – in den Kapiteln 8-12 qualifizierte Aussagen über die Werkzeuge getroffen werden.

2. Einführung in Continuous Integration Systeme

Zur Einführung in die Thematik, wird zunächst das Konzept von Continuous Integration theoretisch vorgestellt. Dabei wird der Ablauf eines typischen CI-Prozess anhand eines Szenarios dargestellt und erläutert. Daraufhin werden die verschiedenen Komponenten eines CI- Systems kurz vorgestellt, und ein Überblick gegeben welche Vertreter des jeweiligen Werkzeuges sich zurzeit auf dem Markt befinden.

In der Softwareentwicklung ist unter Integration das zusammenfügen einzelner Softwaremodule zu einem Projekt zu verstehen. Während diese Aufgabe für einen einzelnen Entwickler noch relativ überschaubar ist, stellt sie für ein Entwicklerteam häufig einen großen Aufwand dar, sicherzustellen, dass die zusammengefügten Module fehlerfrei integrierbar sind.

Der Lösungsansatz für die oben ausgeführte Problemstellung ist ein agiles Entwicklungskonzept und nennt sich Continuous Integration (CI). Im Deutschen wird der Ansatz als kontinuierliche Integration bezeichnet. Es finden sich aber auch Bezeichnungen wie permanente oder fortlaufende Integration. Erfunden wurde das Konzept wahrscheinlich von mehreren Entwicklerteams unabhängig voneinander. Durch Kent Beck wurde permanente Integration im Rahmen von „Extreme Programming“ schließlich populär.^[1] Nigthly Builds, also das nächtliche Durchführen eines Build-Prozesses, stellen eine vereinfachte Version von Continuous Integration dar.

Continuous Integration ist ein agiler Entwicklungsprozess, bei dem der Code der zu entwickelnden Software so häufig wie möglich integriert, kompiliert, installiert und getestet wird.^[2] Hierbei wird immer nur ein kleiner Teil entwickelt und die Änderungen sofort in den Hauptzweig der Entwicklung integriert, sobald der Arbeitsschritt fehlerfrei integriert werden kann. Der Hauptbestandteil einer Continuous Integration Lösung ist, dass die Integration einer Änderung im Sourcecode automatisch einen neuen Build-Prozess anstößt. Um diesen Schritt ohne gewaltigen Mehraufwand für den Entwickler zu gewährleisten, wird durch die Kombination verschiedener Open-Source Werkzeuge ein Continuous Integration System aufgebaut. Die vier zentralen Komponente eines solchen Systems sind ein zentrales Repository beziehungsweise ein Versionskontrollverwaltungssystem, ein Continuous Integration Server, ein Build-System sowie automatisierte UnitTests und optional auch automatische Codeanalysen. Hierbei ist die Nutzung der verschiedenen Werkzeuge optional. Bevor diese Komponente im nächsten Abschnitt näher erläutert werden, soll zunächst der typische Ablauf eines Continuous Integration Prozesses anhand eines Szenarios dargestellt werden. Abbildung 1 stellt schematisch den typischen Aufbau eines CI-Systems dar.

Der Ausgangspunkt für die Verwendung eines CI-Systems ist ein Projekt, das mit CI arbeiten soll und dessen Quellcode mit einem Version Control System (VCS) verwaltet wird.^[3] Subversion^[4] ist ein Beispiel für ein gängiges VCS, diese werden im Laufe dieses Kapitels noch detaillierter beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Continuous Integration Ablauf

Zunächst wird in dem CI-Server konfiguriert, wo sich das Projekt im Versionskontrollsystem befindet und wie sich der CI-Server gegenüber dem VCS authentifiziert.^[5] Daraufhin erzeugt der CI-Server eine lokale Kopie des Projekts. Die Entwickler übergeben ihre Änderungen mindestens einmal am Tag in das VCS. Der CI-Server überprüft regelmäßig, ob im VCS Änderungen vorliegen. Ist dies der Fall, wird automatisch die lokale Datei auf dem CI-Server durch ein Update aktualisiert und automatisch ein Build angestoßen.^[6] Die Definition des Build kann je nach Projekt variieren, beinhaltet aber üblicherweise das Kompilieren des Sourcescodes sowie das Durchführen automatisierter Tests. Diese Ausführung übernimmt allerdings nicht der CI-Server sondern ein Build-Tool wie Ant oder Maven. Der Einsatz eines Build Werkzeuges setzt voraus, dass der Bauvorgang eines Projektes komplett automatisiert wurde und die Build spezifischen Dateien ebenfalls im VCS verwaltet werden.^[7]

Der Build kann entweder erfolgreich durchlaufen, vom Build Tool mit einer Warnung versehen werden oder fehlschlagen - zum Beispiel bei Abbruch des Compilers oder bei Überschreiten einer bestimmter Anzahl fehlgeschlagener Tests.^[8] Je nach Endstatuts wird er vom CI-Server klassifiziert und die Ergebnisse des Builds werden in Form von Berichten auf dem CI-Server gespeichert und sind über die CI-Server Webseite aufrufbar. Da der CI-Server Zugriff auf das VCS hat, kann er ermitteln welcher Entwickler den letzten CI-Build ausgelöst hat und informiert den Entwickler über E-Mail oder andere Kommunikationswege über das Build-Ergebnis.

Im Folgenden werden die einzelnen Komponenten eines CI-Systems vorgestellt und erläutert. Dabei wird bei der Komponente der Continuous Integration Servern auch eine kurze Marktanalyse durchgeführt.

2.1. Versionsverwaltung

Das Versionskontrollsystem (VCS) stellt die zentrale Schnittstelle für die Zusammenarbeit von mehreren Entwicklern dar.^[9] Die Nutzung eines VCS ist Vorrausetzung und damit auch Ausgangspunkt für die Nutzung eines CI-Systems. Durch die Nutzung eines Versionskontrollsystems ist über den gesamten Entwicklungszeitrum nachvollziehbar welche Änderungen zu welchem Zeitpunkt stattgefunden haben und von welchem Entwickler sie hinzugefügt wurden. Durch die zentrale Führung des Projektstandes wird eine konfliktfreie Entwicklung im Team ermöglicht.^[10] Im Unternehmensumfeld haben sich vor allem die Versionsverwaltungstools Subversion und CVS ( Concurrent Versions System) durchgesetzt. Das Quellcode-Repository befindet sich auf einem zentralen Server, was den Nachteil mit sich bringt, dass Änderungen nur eingefügt werden können wenn der Server auch online ist.

Neben den oben genannten zentralen Versionsverwaltungssystemen, besteht auch ein Ansatz der dezentralen Versionsverwaltung. Dezentrale Versionsverwaltungssysteme wie Git^[11] erweitern den Freiraum der Entwickler in Gestaltung und Zusammenarbeit, allerdings mit dem Nachteil dass sich die Komplexität in der Bedienung des Tools enorm erhöht.^[12] Der elementare Unterschied zu einem Quellcode-Repository auf einem zentralen Server besteht darin, dass jeder Entwickler eine Kopie (clone), aus einem remote liegenden Repository, auf seinen eigenen lokalen Rechner ziehen kann. Somit können Commits durchgeführt werden auch wenn keine Verbindung zu dem Server besteht - was einen großen Vorteil für dezentrale Versionsverwaltung bringt.^[13] Des Weiteren können die Entwickler untereinander Änderungen austauschen und synchronisieren.^[14]

Aus dem einführendem Gespräch mit einem Vertreter des Unternehmens ist bekannt geworden, dass bereits das VCS Subversion eingesetzt wird. Die große Mehrheit der Softwareprojekte des Unternehmens ist in einem Subversion VCS abgelegt. Es bedeutete einen erheblichen Aufwand die Projekte in ein anderes VCS zu übertragen.

Wie später in Kapitel 8.1. erläutert werden wird, muss auf dem CI-Server lediglich eine URL zum Verweis auf das VCS hinterlegt werden. Somit ist es auch für die Darstellung und Erarbeitung des Konzeptes von Continuous Integration unerheblich, ob es sich um ein bestimmtes VCS handelt.

2.2. Continuous Integration Server (Marktanalyse)

Der Continuous Integration Server ist eine Anwendung, die bei Änderung des Quellcodes in der Versionsverwaltung einen automatischen Build des gesamten Projekts auslöst. In dieser Anwendung lässt sich eine Vielzahl von Softwareprojekten verwalten. Dabei stellt der Continuous Integration Server die zentrale Schnittstelle zur Verwaltung der Projekte und der in der Umgebung des Servers integrierten Werkzeuge dar. Die Abbildung 2 zeigt exemplarisch die Oberfläche des CI-Servers Jenkins mit den darin angelegten Jobs (hierarchische Elemente zur Verwaltung von verschiedenen Projekten).

Bei der Wahl eines Continuous Integration Servers sollte auf verschiedene Kriterien geachtet werden. Hierbei sollte vor allem zwischen funktionalen und nicht-funktionalen Kriterien unterschieden werden. Aus den Anforderungen des Auftrag gebenden Unternehmens ergibt sich ein besonderer Fokus auf die funktionalen Kriterien:

-Kompatibilität mit der vorhandenen Infrastruktur
-Funktionsumfang und Erweiterbarkeit
-Optimierung für bestimmte Szenarien

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Jenkins Oberfläche

Im Folgenden werden die verschiedenen CI-Server anhand ihrer Funktionalitäten miteinander verglichen. Im Sinne der Kompatibilität mit der vorhandenen Infrastruktur sollte vor allem darauf geachtet werden, dass eine Interoperabilität mit einem vorhanden VCS oder einem etabliertem Build-Tool gewährleistet ist.^[15] So macht es zum Beispiel keinen Sinn ein Tool zu wählen welches das bestehende Versionskontrollsystem nicht unterstützt und man zunächst ein Plugin entwickeln müsste. Das gleiche gilt für die Unterstützung eines Build-Tools. Hierzu wird aufgezeigt welche Werkzeuge von dem jeweiligen CI-Server unterstützt werden, welche Grundfunktionen ein CI-Server mit sich bringt und inwiefern sich diese von dritter Seite anhand von Plugins funktional erweitern lassen.^[16] Ein weiteres Feature stellen die Kommunikationswege dar, die der CI-Server nutzen kann, um den Entwickler über den Verlauf seines Builds zu informieren. Hierbei können z.B. E-Mail aber auch proaktive Kommunikationswege wie InstantMessenger oder RSS-Feeds zum Einsatz kommen. Die Erweiterbarkeit der Tools bzw. die Anzahl an bereits bestehenden Plugins können ebenfalls für einen Produktverglich in Betracht gezogen werden. Darüber hinaus werden auch nicht-funktionale Kriterien wie zum Beispiel die Einfachheit der Installation, die Bedienbarkeit und die Oberflächengestaltung in Betracht gezogen und im Laufe des Kapitels ebenfalls bewertet.

Die Auswahl an CI-Servern auf den Markt ist sehr groß und vor allem sehr vielfältig. Eine Vergleichsmatrix mit den dreißig bekanntesten Vertretern von CI-Servern wurde von der Firma Thoughtworks entwickelt und kann auf deren Website eingesehen werden.^[17] Allerdings vergleicht diese Matrix CI-Server für alle Programmiersprachen und beinhaltet sowohl CI-Server aus dem Open Source als auch aus dem proprietärem Bereich.

Anhand folgender funktionalen Kriterien konnte eine Vielzahl an CI-Servern ausgeschlossen werden:

-CI-Server, die nicht für Java Projekte geeignet sind.
-CI-Server, die nicht als Open Source Lizenz verfügbar sind.
-CI-Server, die Apache Ant nicht unterstützen und diese Funktion auch nicht via ein Plugin System erweiterbar ist.
-Produkte, die nicht mit dem Versionsverwaltungssystem Subversion kompatibel sind.

Nach Anwendung der Kriterien musste die Auswahl ein weiteres Mal anhand des Bekanntheitsgrades des CI-Servers eingeschränkt werden. Dies ergibt sich aus den Anforderungen des Auftrag gebenden Unternehmens.

Im Folgenden werden die CI-Server Jenkins, Hudson, Continuum und Cruise Control kurz beschrieben und anhand einer Übersichtstabelle sowie einem Ranking miteinander verglichen.

In der Java Software-Entwicklung hat sich Jenkins^[18] welches früher unter dem Namen Hudson bekannt war, sehr erfolgreich auf dem Markt etabliert und wird von einer großen und aktiven Community unterstützt und weiterentwickelt.^[19] Dabei unterliegt Jenkins einer Plugin-basierten Architektur. Dies bedeutet, dass Jenkins nicht in die Anwendung selbst und Plugins getrennt ist, sondern vollständig aus diesen gebaut wird. Jenkins ist als Fork aus einer Abspaltung von dem CI-Server Hudson hervorgegangen. Anfang 2011 kam es zum Streit zwischen der Entwickler Community und Oracle, welches auf Namensrechte bestand und die Migration des Servers auf die Hosting Plattform Github verhindern wollte. Mittlerweile hat Oracle das mit Sun übernommene Open-Source Projekt Hudson an die Eclipse Foundation übergeben.

Aufgrund der Tatsache, dass Jenkins und Hudson auf dem gleichen Code basieren und seit der Spaltung keine bedeutenden neuen Features hinzugekommen sind, sind sich die beiden Tools sehr ähnlich. Einen aufwendigen Installationsprozess gibt es bei Jenkins beziehungsweise Hudson nicht. Native Pakete für eine Installation auf einem Unix/Linux System sowie auf Windows stehen auf der Jenkins Website bereit. Alternativ wird Jenkins mit einem integrierten Servlet-Container (Windston) ausgeliefert, was eine Standalone-Ausführung ermöglicht.^[20] Zum Starten des Tools muss lediglich die Webarchive (.war) Datei von der Projektwebseite heruntergeladen werden und über java jar- jenkins.war gestartet werden. Alternativ kann auch ein Servlet-Container wie Tomcat oder Glassfish genutzt werden. Jenkins verfügt über eine deutschsprachige Web-Oberfläche und ist über diese komplett bedienbar. Es sind keinerlei Konsoleneingaben nötig. Dies gilt auch für die Installation von Plugins oder Versionsupdates. Beim Anlegen eines Jobs können eine Vielzahl von Komponenten konfiguriert werden. Unter anderem lässt sich das Repository über eine URL einbinden, um den zu bauenden Quellcode auszuchecken.

Jenkins unterstützt bereits in der Standard Konfiguration eine Reihe von Testwerkzeugen. Weitere Werkzeuge, wie zum Beispiel Sonar als Werkzeug für Code Coverage Analysen, lassen sich über die Jenkins Plugins nachinstallieren.

Apache Continuum^[21] ist ein weiteres Open-Source Produkt welches für die Verwendung mit dem Build-Tool Maven konzipiert und in dessen Rahmen von Apache weiterentwickelt wurde.^[22] Wie bei Jenkins zeichnen sich die Funktionalitäten durch eine einfache Installation und Konfiguration aus, allerdings müssen bei der Installation Benutzerkonten angelegt werden sowie ein Arbeitsverzeichnis. Apache Continuum unterstützt eine Breite von Versionskontrollsystemen darunter auch CVS, Subversion und Mercruial. Da Continuum auf Maven basiert, wird mit Projekten gearbeitet, die in sogenannten Project Object Models (POM)- Dateien gespeichert sind. Dies ist eine Konfigurationsdatei, die die Schritte eines Builds bestimmt. Zur Verwaltung von Projekten können frei definierte Projektgruppen angelegt werden. Daraufhin wird ein Projekt eingerichtet indem man, im Idealfall, nur die SVN-URL zur Maven POM-Datei angibt oder alternativ eine pom.xml hoch lädt. Ein weiteres Feature von Apache Continuum ist die Unterstützung sogenannter Build-Queues. Dies ist bei Jenkins allerdings auch aufgrund des Build Pipeline Plugins möglich. Zusammenfassend zeichnet sich Apache Continuum vor allem durch die hervorragende Integration mit Maven2 und Maven SCM sowie durch ein umfassendes Management der Benutzerrechte und Möglichkeit der Einteilung von Benutzer in Projektgruppen aus. Allerdings fehlt die Möglichkeit Plugins einzubinden. Somit ist z.B. die Integration von Sonar um einiges aufwendiger als bei Jenkins. Abbildung XYZ zeigt den Fokus auf Projekte beziehungsweise die Einteilung in Projektgruppen bei Continuum und den Status der Vorgänge innerhalb der Projektgruppe.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Projektgruppen Übersicht in Continuum

Cruise Control^[23] war eines der ersten CIS auf dem Markt. Es wird somit auch häufig als Urvater der CI-Server bezeichnet. Cruise Control stellt sowohl ein CI-Tool, als auch ein erweiterbares CI-Framework dar, welches ursprünglich von der Firma Thoughtworks entwickelt wurde, heute aber als Open Source Projekt „unter einer BSD-ähnlichen Lizenz vertrieben wird“.^[24] Der Hauptbestandteil des CI-Servers stellt ein Prozess dar, der in einer Schleife („the loop“) Änderungen im CVS feststellt, Builds auslöst und über den Ausgang dieser Builds benachrichtigt. Allerdings steht dem Nutzer, anders als bei Jenkins und Hudson, keine Web-Oberfläche zur Konfiguration zur Verfügung sondern zwei webbasierte GUIs mit einer klassischen Ansicht und einem Dashboard.^[25]

Die folgende Übersichtstabelle gibt Auskunft über die Projektleitung beziehungsweise den Anbieter des jeweiligen Open Source CI-Server, die Lizenzform sowie die Versionsnummer des aktuellen Release, anhand welchem die CI-Server miteinander verglichen wurden. Des Weiteren werden die verschiedenen Funktionen und Werkzeuge, die der CI-Server unterstützt, gegenübergestellt.

Tabelle 1: CI-Server Funktionalitäten im Vergleich

Abbildung in dieser Leseprobe nicht enthalten

Anhand der Übersichtstabelle zeigt sich, dass die miteinander verglichenen CI-Server alle sehr gut mit den wichtigsten Vertretern der verschiedenen CI-Werkzeuge kompatibel sind. Darunter die Build-Werkzeuge Ant und Maven sowie die Versionskontrollsysteme Subversion, CVS und Git. Da die Anforderungen des Auftrag gebenden Unternehmens sich auch auf diese Werkzeuge beschränken, ist aufgrund der Übersichtstabelle noch kein Favorit feststellbar. Bei Apaches Continuum ist bereits zu erkennen, dass es sich aufgrund der fehlenden Plugin-Struktur von den anderen CI-Servern unterscheidet. Die Kommunikationswege sind bei allen CI-Servern sehr umfangreich, wobei sich Cruise Control eher auf die traditionellen Emails beschränkt. Die Übersicht zeigt auch, dass sich Jenkins und Hudson im Bereich der Funktionalitäten noch nicht sehr weit auseinander entwickelt haben. Lediglich die Anzahl an vorhandenen Plugins ist im Jahr nach der Spaltung bei Jenkins rapide gestiegen. Das kann mit der sehr aktiven Community begründet werden. Besonders bei der Entwicklung des Prototyps hat sich gezeigt, dass die Größe und Aktivität der Community eine entscheidende Rolle bei der Einführung und Integration eines CI-Servers spielt. So sind viele potentielle Probleme schon erkannt, dokumentiert oder auch bereits behoben.

Aufgrund der Tatsache, dass alle CI-Server die grundlegenden Anforderungen gleichermaßen erfüllen, wird im Folgenden ein Ranking durchgeführt, welches auch nicht-funktionale Kriterien wie die Bedienbarkeit des CI-Severs in Betracht zieht.

2.2.1. Ranking

Die Kriterien stammen zum Teil aus den Anforderungen des Auftrag-gebenden Unternehmens, für welches der Funktionsumfang eines CI-Servers aber auch der Installationsaufwand und der Gesamteindruck von Bedeutung ist. Die Bewertung der einzelnen Kriterien erfolgt aufgrund von Recherche und praktischen Erfahrungen mit den einzelnen CI-Servern. Besonders mit Jenkins haben die Autoren sehr viele praktische Erfahrungen gesammelt. Continuum bietet eine Live-Demo auf seiner Webseite an, durch welche die Autoren sich ein gutes Bild über die Funktionalitäten und die Bedienbarkeit des Tools machen konnten. Im Folgenden werden die ausgewählten Kriterien kurz näher erläutert:

Funktionsumfang: Dieses Kriterium bezieht sich auf die vorherige Übersichtstabelle 1 und bewertet wie viele CI-Werkzeuge von dem CI-Server unterstützt werden. Bei einer Unterstützung von allen gängigen CI-Werkzeugen wie Ant, Maven, CVS, SVN, etc. wurde volle Punktzahl vergeben. Hierzu zählt auch die Integration von Test Werkzeugen wie zum Beispiel JUnit oder TestNG.

Oberfläche: Je nach Übersichtlichkeit der Oberfläche eines CI-Servers gestaltet sich die Bedienung eines CI-Servers. Eine übersichtliche Oberfläche mindert die Einarbeitungszeit für den Entwickler.

Zunächst wird in Betracht gezogen wie die Oberfläche technisch umgesetzt ist, das heißt es wird bewertet ob der CI-Server über eine GUI oder ein Webinterface zu bedienen ist oder womöglich Konsoleneingaben nötig sind. Auch die verfügbaren Sprachen der Weboberflächen gehen in die Bewertung ein. Da die Analyse für ein deutsches Unternehmen durchgeführt wird, wird eine deutschsprachige Oberfläche positiv gewertet.

Bei Bewertung der Oberfläche wurde die Punktzahl generell auf 5 Punkte gesetzt, Abzug gab es im Falle dass keine GUI oder Webinterface vorhanden ist. Auch ein unattraktive, unübersichtliche Optik führt zu Abzügen. Darüber hinaus wird auch die Notwendigkeit von Konsoleneingaben mit einem Abzug gewertet.

Installationsaufwand: Für die Einführung eines CI-Prozesses in das Unternehmen sollte die Hürde des Installationsaufwandes möglichst gering sein. Ein CI-Server sollte ohne komplexe Installationsroutinen installierbar sein. Im Besten Fall führt ein Wizard den Nutzer durch eine Routine. Zur Beurteilung der Installationsroutine wurden die Installationsanleitungen herangezogen.

Konfigurationsaufwand: Nach Installation muss der CI-Server einmalig konfiguriert werden. Neben dem CI-Server und den verschiedenen Werkzeugen die in das System integriert sind, müssen aber die Build /Test und Deployment Prozesses konfiguriert werden.

Dieses Kriterium ist besonders wichtig, da es die meiste Zeit der Implementierung in Anspruch nimmt und somit einen sehr hohen Aufwand darstellt. Zudem birgt die Konfiguration des CI-Servers ein sehr hohes Fehlerpotential. Je mehr Werkzeuge in ein CI-System integriert werden umso höher ist der Konfigurationsaufwand da diese wiederum aufeinander abgestimmt werden müssen.

Zukunftssicherheit: Führt das Unternehmen einen CI-Server ein, so möchte es sicher gehen, dass dieser auch innerhalb der nächsten Jahre weiterentwickelt wird und im Notfall ein Support bereit steht, beziehungsweise ein aktive Community an die man sich mit Problemen wenden kann. Die Community kann anhand der Aktivitäten auf der Hosting Platform Github bewertet werden. Bei einer sehr aktiven Community sind viele „Commits“ zu beobachten, darüber hinaus werden regelmäßig neue Versionen des CI-Servers bereitgestellt.

Gesamteindruck: Bei diesem Kriterium wird die Internetpräsenz des CI-Servers im Allgemeinen in Betracht genommen, Referenzen zu bekannten Firmen sind ebenso wichtig wie eine gute Dokumentation anhand von Screenshots. Funktionierende Links zählen dabei ebenso zum Gesamteindruck.

Gewichtung der Kriterien:

Die folgende Tabelle zeigt die einzelnen Anforderungen mit ihren Gewichtungen und eine kurze Erklärung für die Gewichtung. Die Gewichtung geht von 1 – 5. Dabei spielt 1 die kleinste Rolle und 5 spiegelt eine wichtige Anforderungen dar.

Tabelle 2: Gewichtung der Kriterien an CI-Server

Abbildung in dieser Leseprobe nicht enthalten

[...]

---

^[1] Vgl.Wiest, S.(2011), S. 13

^[2] Vgl. Wagner, S./ Handte, M.(2012), S. 70

^[3] Vgl. Feustel, B./ Schluff, S. (2012)

^[4] http://subversion.apache.org/

^[5] Vgl. Feustel, B./ Schluff, S. (2012)

^[6] Vgl. Ebenda

^[7] Vgl. Feustel, B./ Schluff, S. (2012)

^[8] Vgl. Ebenda

^[9] Vgl. Wickner, B /Müller, B. (2012), S. 299

^[10] Vgl. Ebenda S. 300

^[11] http://git-scm.com/

^[12] Vgl. Wickner, B /Müller, B. (2012), S. 300

^[13] Vgl. Gentz, E. (2012)

^[14] Vgl. Ebenda

^[15] Vgl. Feustel, B./ Schluff, S. (2012)

^[16] Vgl. Ebenda

^[17] http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix

^[18] http://jenkins-ci.org/

^[19] Vgl. Wickner, B./ Müller, B.(2012), S. 302

^[20] Vgl. Wickner, B./ Müller, B.(2012), S. 303

^[21] http://continuum.apache.org/

^[22] Vgl. Schumacher, M. /Kaman, T. (2008), S. 53

^[23] http://cruisecontrol.sourceforge.net/

^[24] Vgl. Schumacher, M. /Kaman, T. (2008), S. 52

^[25] Wiest, S.(2011), S. 71