image

Continuous Integration mit Hudson

image

Dr. Simon Wiest ist Professor für Informatik im Fachbereich »Electronic Media« an der Hochschule der Medien, Stuttgart. In seiner selbstständigen Tätigkeit als freier Berater für Continuous Integration begleitete er Softwareteams zwischen 5 und 1.200 Entwicklern. Seit 2007 ist er Committer und Evangelist im Hudson-Projekt. Seine Beiträge wurden mit einem Sun Microsystems Community Innovation Award ausgezeichnet. Er spricht regelmäßig auf Fachkonferenzen, in Firmen und Java User Groups. Dr. Wiest ist zu erreichen unter www.simonwiest.de.

Simon Wiest

Continuous Integration
mit Hudson

Grundlagen und Praxiswissen
für Einsteiger und Umsteiger

Simon Wiest

Lektorat: René Schönfeldt
Copy-Editing: Annette Schwarz, Ditzingen
Herstellung: Nadine Thiele
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck und Bindung: Media-Print Informationstechnologie, Paderborn

Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:
Buch 978-3-89864-690-1
PDF 978-3-89864-887-5
ePub 978-3-89864-852-3

1. Auflage 2011
Copyright © 2011 dpunkt.verlag GmbH
Ringstraße 19 B

69115 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Geleitwort von Kohsuke Kawaguchi

One of the challenges in an open-source project is to come up with a comprehensive documentation. In the face of incoming bug reports and new feature requests, it always ended up postponed. So for the longest time, we relied on the community contributed Wiki and mailing list archives as a substitute for a documentation. The problem with those resources is that they are neither linear nor particularly well organized. Those are often specific questions and answers, troubleshooting guides, and other instructions, but it just doesn’t work well with those who are new to continuous integration or Hudson to get a broad view on what it has to offer. I’ve done a few smaller articles in Japan toward this goal in the past, but it only made me more convinced that this is a serious undertaking.

So I was very happy when I learned that Simon was writing a book. In this book, he discusses the bread and butter functionalities of Hudson in details. Those of you who are new to Hudson and those of you who are using Hudson for a while are both likely to find this book useful. I should also point out that the part in which he discusses the organizational implications of Hudson is novel, and should come in very handy for those who are approaching CI in a more careful manner.

Simon is a longtime member of the Hudson community, and quite instrumental in the localization work. I don’t remember exactly when he became a part of the community – German translation wasnt the first translation of Hudson, although it was pretty close. But the first real impression that he made on me was when he came up with a tool that tracks the progress of localizations in various languages, complete with a list of translations that became out of date, by looking at the version control history of the source files. I just went »Wow!«. So it was only natural that he won a Glassfish Community Award in 2008 in recognition of these valuable contributions. And finally now that this book is finished, I’m hoping he’d have time to wrap that up and make it generally available.

I’d be also amiss if I talked about Simon without mentioning his own Hudson extreme feedback devices, which is a triplet of plastic bears that glow and flash as your build status changes. This was done via Ethernet-controlled power sockets, and was one of the early feedback devices around Hudson. As a builder of one of those XFDs myself, I think there’s something with bright LEDs that attracts geeks, but I digressed.

I hope you enjoy his book.

Kohsuke Kawaguchi

Creator of Hudson

Inhaltsverzeichnis

1

Einleitung

1.1

Kennen Sie die »Integrationshölle«?

1.2

Warum Continuous Integration (CI)?

1.3

Warum Hudson?

1.4

Warum dieses Buch?

1.5

Wer dieses Buch lesen sollte

1.6

Wie man dieses Buch lesen sollte

1.7

Konventionen

1.8

Website zum Buch

1.9

Danksagungen

1.10

Zusammenfassung

2

CI in 20 Minuten

2.1

Was ist CI?

2.2

Was ist CI nicht?

2.3

Software entwickeln ohne CI

2.4

Software entwickeln mit CI

2.5

Zusammenfassung

3

Welche Vorteile bringt CI?

3.1

Reduzierte Risiken

3.2

Verbesserte Produktqualität

3.3

Allzeit auslieferbare Produkte

3.4

Gesteigerte Effizienz

3.5

Dokumentierter Build-Prozess

3.6

Höhere Motivation

3.7

Verbesserter Informationsfluss

3.8

Unterstützte Prozessverbesserung

3.9

Zusammenfassung

4

Die CI-Praktiken

4.1

Gemeinsame Codebasis

4.2

Automatisierter Build

4.3

Häufige Integration

4.4

Selbsttestender Build

 

4.4.1

Compiler

 

4.4.2

Unit-Tests

 

4.4.3

Komponententests

 

4.4.4

Systemtests

 

4.4.5

Inspektionen

4.5

Builds (und Tests) nach jeder Änderung

4.6

Schnelle Build-Zyklen

4.7

Tests in gespiegelter Produktionsumgebung

4.8

Einfacher Zugriff auf Build-Ergebnisse

4.9

Automatisierte Berichte

4.10

Automatisierte Ausbringung (Deployment)

4.11

Zusammenfassung

5

Hudson im Überblick

5.1

Die Hudson-Story

5.2

Architektur und Konzepte

 

5.2.1

Systemlandschaft

 

5.2.2

Datenmodell

 

5.2.3

Benutzerschnittstellen

5.3

Die Top-10-Highlights

 

5.3.1

Schnelle Installation

 

5.3.2

Effiziente Konfiguration

 

5.3.3

Unterstützung zahlreicher Build-Werkzeuge

 

5.3.4

Anbindung von Versionsmanagementsystemen

 

5.3.5

Testberichte

 

5.3.6

Benachrichtigungen

 

5.3.7

Remoting-Schnittstelle

 

5.3.8

Abhängigkeiten zwischen Jobs

 

5.3.9

Multikonfigurationsbuilds (»Matrix-Builds«)

 

5.3.10

Verteilte Builds

 

5.3.11

Plugins

5.4

Hudson im Vergleich zu Mitbewerbern

 

5.4.1

Proprietäre Eigenentwicklungen

 

5.4.2

CruiseControl

 

5.4.3

ThoughtWorks Cruise

 

5.4.4

Atlassian Bamboo

 

5.4.5

JetBrains TeamCity

5.5

Zusammenfassung

6

Installieren und Einrichten

6.1

Schnellstart in 60 Sekunden

6.2

Systemkonfiguration

6.3

Fortgeschrittene Installation

 

6.3.1

Systemvoraussetzungen

 

6.3.2

Ablaufumgebungen

 

6.3.3

Datei-Layout

 

6.3.4

Installationsmethoden

 

6.3.5

Starten und Stoppen

 

6.3.6

Aktualisieren

 

6.3.7

Backups

 

6.3.8

Deinstallation

 

6.3.9

Plugins

 

6.3.10

Tipps aus der Praxis

6.4

Zusammenfassung

7

Hudson im täglichen Einsatz

7.1

Ihr erster Hudson-Job im Schnelldurchlauf

 

7.1.1

Den ersten Job einrichten

 

7.1.2

Statusanzeigen auf der Übersichtsseite

7.2

Jobtypen

 

7.2.1

Gemeinsamkeiten

 

7.2.2

Free-Style-Projekt

 

7.2.3

Maven-2-Projekt

 

7.2.4

Multikonfigurationsprojekt (»Matrix-Builds«)

 

7.2.5

Überwachung eines externen Jobs

7.3

Versionsmanagement integrieren

 

7.3.1

Konfiguration eines Projekts

 

7.3.2

Repository-Browser anbinden

7.4

Auslösen von Builds

 

7.4.1

Manuell (build trigger)

 

7.4.2

Zeitgesteuert

 

7.4.3

Bei Änderungen im Versionsmanagementsystem

 

7.4.4

Abhängigkeiten zu anderen Projekten

 

7.4.5

Auslösung durch Plugins

7.5

Testwerkzeuge integrieren

 

7.5.1

JUnit, TestNG

 

7.5.2

Weitere Test-Frameworks der xUnit-Familie

7.6

Benachrichtigungen verschicken

 

7.6.1

E-Mail

 

7.6.2

Email-ext (Plugin)

 

7.6.3

RSS-Feeds

 

7.6.4

Hudson Build Monitor (Firefox Add-on)

 

7.6.5

Twitter (Plugin)

 

7.6.6

hudson-eclipse (Eclipse-Plugin)

 

7.6.7

Informationsradiatoren

 

7.6.8

eXtreme-Feedback-Geräte anbinden

7.7

Dokumentationswerkzeuge integrieren

 

7.7.1

Javadoc

 

7.7.2

Maven Site

 

7.7.3

Einbindung beliebiger HTML-Berichte

7.8

Analysewerkzeuge integrieren

 

7.8.1

Checkstyle, PMD, FindBugs

 

7.8.2

Warnings (Plugin)

 

7.8.3

Task Scanner (Plugin)

 

7.8.4

Cobertura (Plugin)

 

7.8.5

Sonar (Plugin)

7.9

Issue-Tracker integrieren

 

7.9.1

Atlassian JIRA

 

7.9.2

Mantis

7.10

Zusammenfassung

8

Hudson für Fortgeschrittene

8.1

Parametrisierte Builds

 

8.1.1

Definition von Parametern

 

8.1.2

Typische Anwendungsfälle

8.2

Ansichten (views) und Dashboards

 

8.2.1

Benutzerdefinierte Listenansichten

 

8.2.2

Projekte filtern und gruppieren

 

8.2.3

Verschachtelte Ansichten

 

8.2.4

Hudson als Ihr Build-Portal

8.3

Parallelisierung der Build-Aktivitäten

 

8.3.1

Abhängigkeiten zwischen Projekten

 

8.3.2

Nachgelagerte Builds zusammenführen

 

8.3.3

Exklusiver Zugriff auf Ressourcen

 

8.3.4

Parameterübergabe an nachgelagerte Builds

 

8.3.5

Abbruch hängender Builds

8.4

Multikonfigurationsprojekte

 

8.4.1

Anlegen eines Multikonfigurationsprojekts

 

8.4.2

Verteilte Matrix-Builds

 

8.4.3

Zusammenfassung der Build-Ergebnisse

8.5

Verteilte Builds

 

8.5.1

Warum verteilen?

 

8.5.2

Warum nicht verteilen?

 

8.5.3

Slave-Knoten einrichten

 

8.5.4

Verteilen der Build-Umgebung

 

8.5.5

Überwachen des CI-Clusters

 

8.5.6

Virtualisierung

 

8.5.7

Bauen in der Wolke

8.6

Hudson absichern

 

8.6.1

Authentifizierung

 

8.6.2

Autorisierung

 

8.6.3

Auditierung

8.7

Weitere nützliche Plugins

 

8.7.1

Claim

 

8.7.2

Configuration Slicing

 

8.7.3

Build-Promotion

 

8.7.4

Description Setter

 

8.7.5

Green Balls

 

8.7.6

Locale

 

8.7.7

Continuous Integration Game

8.8

Zusammenfassung

9

Hudson erweitern

9.1

Erste Schritte

 

9.1.1

Schnellstart: Ihr erstes Plugin in 60 Sekunden

 

9.1.2

Anatomie eines Plugins

 

9.1.3

Einrichten einer Entwicklungsumgebung

 

9.1.4

Zusammenfassung

9.2

Hudsons Plugin-Konzept

 

9.2.1

Hudsons Technologie-Stapel

 

9.2.2

Was muss ein Plugin-Entwickler wissen?

 

9.2.3

Hudsons Erweiterungspunkte (Extension Points)

9.3

Beispiel: Das Plugin »Artifact Size«

 

9.3.1

Die Aufgabe

 

9.3.2

Erweiterungspunkt »ListViewColumn«

 

9.3.3

Erweiterungspunkte »Recorder« und »Action«

 

9.3.4

Erweiterungspunkt »CLICommand«

 

9.3.5

Bereitstellen der Artefaktgröße per XML-API

 

9.3.6

Online-Hilfetexte

 

9.3.7

Lokalisierung und Internationalisierung

9.4

Zusammenfassung

10

Aufwand einer CI-Einführung

10.1

Erstaufwand für Vollautomatisierung des Builds

10.2

Erstaufwand für Erstellung von fehlenden Tests

10.3

Optimieren des Build-Prozesses für CI

10.4

Hardwareressourcen für ein CI-System

10.5

Installation des CI-Systems

10.6

Administration des CI-Systems

10.7

Schulung

10.8

Zusammenfassung

11

Tipps zur Einführung von CI

11.1

Mit einem Pilotprojekt starten

11.2

Build-Zeiten kurz halten

11.3

Codeanalyse: Sanft starten, konstant steigern

11.4

Nur messen, was auch beachtet wird

11.5

Erscheinen neuer Plugins verfolgen

11.6

Den Spaß nicht vergessen

12

Fazit und Ausblick

12.1

Continuous Integration – wie geht’s weiter?

12.2

Hudson – wie geht’s weiter?

12.3

Zusammenfassung

 

Literatur und Quellen

 

Index

1 Einleitung

• Was ist Continuous Integration? Und was bringt sie Ihnen?

• Wer ist Hudson und was kann er für Sie tun?

• Wer sollte dieses Buch lesen? Und wie?

1.1 Kennen Sie die »Integrationshölle«?

Softwareintegration im Fegefeuer»Oh ja!«, sehe ich den einen oder anderen Leser leidvoll nicken. Falls Ihnen der Begriff nicht geläufig sein sollte – die Geschichte beginnt meistens so:

Sie arbeiten in einem jener »führenden Softwarehäuser« an der Entwicklung des Flaggschiffproduktes mit. Am kommenden Tag soll Ihre Abteilung die längst überfällige neue Version Ihrer Software ausliefern – vom Vertrieb seit Monaten verlangt und vom Marketing noch länger beworben. Ihr Chef hat nachtleuchtende Silikonarmbändchen mit dem Aufdruck »Failure is not an option« verteilen lassen.

Die Entwickler werfen also eilig auf dem Abteilungsserver ihre Codeänderungen ab, die sie in den letzten Wochen auf ihren Rechnern erbrütet haben. Doch schon bald wird klar: Die Integration wird auch dieses Mal wieder direkt im Fegefeuer stattfinden!

Erst nach vielen Korrekturen kompiliert das Projekt. Die (spärlich) vorhandenen Tests schlagen fehl, manchmal aber auch nicht. Adrenalin trifft auf Testosteron. Es wird laut in der Abteilung: »Bei mir läuft’s aber« – »Ich habe dort nichts geändert!« – »Ohne vernünftiges Refactoring sage ich gar nichts mehr!«

Am späten Abend laufen die Tests endlich durch. Kein Wunder, denn störende Programmteile wurden beherzt auskommentiert. Man muss ja auch etwas für das nächste Service Pack übrig lassen, oder nicht?

Kurz vor Mitternacht übernimmt »der Meister« das Kommando. Als langjähriger Mitarbeiter mit Kopfmonopol kennt er als Einziger die geheimen Schritte, die notwendig sind, um eine Distribution zu erstellen – und ja, nur er hat die notwendigen Werkzeuge dazu auf seinem Rechner installiert. Abblende nach Schwarz.

Am nächsten Tag wird die Software tatsächlich ausgeliefert. Das Team hat Bauchschmerzen, denn keiner weiß wirklich genau, welche Änderungen in dieses Release eingeflossen sind. Die alten Hasen haben schlauerweise schon mal vierzehn Tage Urlaub eingereicht. Die jüngeren Kollegen stellen sich unter den Türsturz und halten die Luft an. Hoffentlich nicht zu lange, denn das Marketing bewirbt bereits die nächste Version: »the next big thing«…

Neue HoffnungWährend Sie also im Wartezimmer Ihres Betriebspsychiaters über die Ereignisse der letzten Tage nachsinnen, erleben Sie einen wilden Wunschtraum: Wäre es nicht fantastisch, wenn …

• jemand rund um die Uhr alle Codeänderungen an Ihrem Produkt im Auge behielte?

• Jemand, der das komplette Produkt selbstständig integrieren könnte, bis hin zur Distribution? Am besten nach jeder Änderung? Ohne gelangweilt, genervt oder nachlässig zu werden?

• Jemand, der Ihr Produkt gründlich testen und bei neuen Problemen sofort Alarm schlagen würde?

• Jemand, der den gesamten zeitlichen Verlauf Ihres Projekts kennen würde, von der ersten Codezeile an? Der Ihnen mit gebrauchsfertigen Visualisierungen und Berichten helfen würde, Trends und wiederkehrende Fehlermuster aufzuspüren?

Mit anderen Worten: Wäre es nicht schön, einen persönlichen Butler zu haben, der sich kontinuierlich um die Integration Ihres Produktes kümmert?

Die gute Nachricht: Mit dem Continuous-Integration-System Hudson steht Ihnen genau ein solcher »Build-Butler« zur Verfügung. Er kann innerhalb von Minuten seine Dienstwohnung auf Ihrem Server beziehen, kommt mit den allerbesten Referenzen und arbeitet für Sie kostenlos. Interessiert?

image

Abb. 1–1
Hudson – Ihr Build-Butler

1.2 Warum Continuous Integration (CI)?

Risiken minimieren, Qualität steigernContinuous Integration ist ein hervorragendes Werkzeug, um in Softwareentwicklungsprojekten Risiken zu minimieren und Qualität zu steigern. Wie das?

Viele Entwicklungsprojekte geraten in Gefahr, weil die Integration, also die »Endmontage« aller Programmkomponenten, erst im allerletzten Moment angegangen wird. Leider ist dies der denkbar schlechteste Zeitpunkt für unliebsame Überraschungen. Die eingangs geschilderte »Integrationshölle« ist in vielen Softwareprojekten traurige Realität. CI propagiert häufigere Integrationen als den Ausweg aus dieser Misere. Nur: Wie soll ein Team gleich mehrmals am Tag integrieren, wenn schon die bisherige Frequenz »Einmal im Quartal« kaum zu bewältigen war?

Unverzichtbare Grundlage dafür ist die vollständige Automatisierung des Integrationsprozesses, der auch Tests, Dokumentation, Bereitstellung usw. eines Produktes umfassen kann. Viele Teams setzen dazu bereits Werkzeuge wie Ant, Maven oder Eigenentwicklungen ein. Im zweiten Schritt sorgt dann ein CI-Server für die regelmäßige Ausführung dieses Integrationsprozesses, etwa nach jeder Codeänderung oder einmal pro Nacht (nightly build).

Vorteile von CIHäufige Integration vermeidet nicht nur das Durchleiden der »Integrationshölle« (oft verschlimmernd gefolgt von ihrem hässlichen Cousin »Big Bang Testing«). Sie bietet sogar noch eine ganze Reihe weiterer, wichtiger Vorteile:

Der Integrationsaufwand sinkt, weil bei frühzeitiger Warnung kleinere Korrekturen ausreichen, um ein auseinanderlaufendes Projekt wieder auf gemeinsamen Kurs zu bringen. Umfangreiche Nacharbeiten unter hohem Zeitdruck vor dem Fertigstellungstermin entfallen.

Die Fehlersuche wird vereinfacht, weil häufigere Integrationen geringere Veränderungen zur vorausgegangenen Integration bedeutet. Das ist wünschenswert, denn je weniger geändert wird, desto weniger Stellen kommen als Fehlerquelle in Frage und müssen untersucht werden.

Die Teammoral steigt, weil häufigere Integrationen auch mehr Rückmeldungen an die Entwickler bedeuten. Erfolgreiche Änderungen und neue Funktionen werden zeitnah vom CI-System positiv bestätigt. Stellen Sie sich einfach einen Kollegen vor, der Ihnen nach jeder Änderung wenige Minuten später anerkennend auf die Schulter klopft. Zum anderen lässt sich – wie durch ein Fangnetz gesichert – mutiger entwickeln, beherzter refaktorisieren und gefahrlos Neues ausprobieren.

Manuelle Routineaufgaben entfallen durch Automatisierung. Die Erzeugung lauffähiger Zwischenstände und interner Demoversionen (»Kann man schon was sehen?«) ist somit kein lästiger Zeitfresser mehr, sondern läuft unaufgeregt nebenher. Pannen beim Integrieren und Bereitstellen eines Produktes werden vermieden, weil dieser Ablauf nicht mehr alle paar Monate, sondern mehrmals am Tag durchgeführt wird.

Was hält Sie also noch davon ab, diese Vorteile Ihrem Team zugänglich zu machen? Sie benötigen lediglich eine motivierte Person, welche die CI-Einführung in die Hand nimmt (das sind Sie), technisches und organisatorisches Know-how (dieses Buch) und ein gutes CI-System (nächster Absatz).

1.3 Warum Hudson?

Der Markt bietet inzwischen zahlreiche CI-Systeme an. Eine Vergleichsmatrix mit den dreißig bekanntesten Vertretern finden Sie unter [ThoughtWorks10]. Spricht man mit Entwicklern in Firmen und auf Konferenzen, lässt sich jedoch eine Konzentration auf wenige Anbieter beobachten. Vor allem Hudson erfreut sich hier großer Beliebtheit. Warum entscheiden sich Unternehmen wie eBay, Yahoo, Oracle, SAP oder die Allianz für Hudson?

Vorneweg: Es liegt nicht an der kostenlosen Verfügbarkeit. Selbstverständlich macht dieser Umstand den Einstieg leichter. Aber als alleinige Erklärung für Hudsons Erfolg greift dies zu kurz, denn:

• Es existieren zahlreiche kostenlose Alternativen. Zudem bieten inzwischen viele kommerzielle Hersteller eingeschränkte »Einsteigerversionen« ebenfalls kostenfrei an.

• Selbst kostenpflichtige CI-Systeme dürften sich bereits nach wenigen Monaten amortisiert haben, etwa durch Produktivitätsgewinne.

Vorteile von HudsonViele Anwender stufen stattdessen Hudsons einzigartige Kombination folgender Vorteile als ungleich wichtiger ein:

Schnelle Resultate:

Hudson ist zügig installiert und eingerichtet. In Kapitel 5 werden Sie eine produktionstaugliche Instanz in 60 Sekunden aufsetzen. Sind Ihre Build-Prozessse schon mit Ant oder Maven automatisiert, können Sie in vielen Fällen bereits nach wenigen Minuten von CI mit Hudson profitieren.

Unkomplizierter Betrieb:

Die meiste Zeit arbeitet Hudson, wie man es von einem erstklassigen Butler erwartet: diskret wachsam im Hintergrund, genügsam im Ressourcenverbrauch und geschliffen in den Umgangsformen. Die webbasierte Benutzeroberfläche lässt auch Gelegenheitsadministratoren die wichtigsten Handgriffe ohne Handbuch erledigen.

Plugin-Architektur:

Trotz etablierter »best practices« und aller Standardisierung werden Sie in jedem Team leicht unterschiedliche Werkzeugketten vorfinden. Dank seiner Plugin-Architektur ist Hudson ein wahres »Infrastruktur-Chamäleon«. Es unterstützt unterschiedlichste Versionsverwaltungen, Build-Werkzeuge, Compiler, Testframeworks, Nachrichtenkanäle usw. Über 200 Plugins stehen bereits zur Verfügung, und wöchentlich kommen neue hinzu. Da diese Plugins ebenfalls unter der liberalen MIT-Open-Source-Lizenz vorliegen, sind sie exzellente Ausgangspunkte für Eigenentwicklungen, etwa um hauseigene, proprietäre Systeme anzubinden.

Große, hilfsbereite Anwender- und Entwicklergemeinde:

Mit über 180 Committern (15 an der Kernanwendung, die weiteren schreiben Plugins), dürfte Hudson eines der CI-Systeme mit der breitesten Entwicklerbasis sein. Bei einer strategischen Entscheidung – vor allem für den Einsatz eines Open-Source-Produkts – ist dies ein nicht unerheblicher Aspekt. Rund 18.000 ausgetauschte Nachrichten auf Hudsons Mailinglisten im Jahr 2009 unterstreichen zusätzlich die Vitalität des Projekts.

Der Autor dieses Buches ist aktiver Evangelist und Committer im Hudson-Projekt Sie dürfen also eine engagierte Darstellung der Vorzüge dieses Produktes erwarten. Trotzdem mag Hudson nicht für alle Teams optimale CI-Server sein. Insbesondere die kommerziellen Werkzeuge locken mit einer engeren Verzahnung in Produkte desselben Herstellers (z. B. IntelliJ TeamCity mit IDEA, Atlassian Bamboo mit JIRA, Microsoft Team Foundation Server mit Visual Studio). Am Ende von Kapitel 5 werden wir daher auch auf gängige Alternativen zu Hudson eingehen.

Statt sich nun aber monatelang auf die Suche nach dem idealen CI-System zu begeben, ist viel wichtiger, überhaupt erst einmal häufigere Integrationen einzuführen und eine gelebte CI-Kultur aufzubauen. Ob Hudson dabei nur übergangsweise als Türöffner fungiert oder zum ständigen Begleiter wird, ist nachrangig.

1.4 Warum dieses Buch?

Seit 2008 halte ich regelmäßig Vorträge zu Hudson auf Fachkonferenzen, bei Firmen und in Java User Groups. Ebenso regelmäßig kommt im Anschluss an diese Vorträge die Frage nach einer »richtigen Dokumentation« für Hudson auf.

Das sollte Sie stutzig machen: Seit wann wollen Anwender Handbücher lesen? Ausgerechnet für eine Software, die sich intuitive Bedienung und Benutzerfreundlichkeit auf die Fahnen geschreiben hat? Selbstverständlich werden die wichtigsten Funktionen und Plugins auf der Hudson-Homepage1 erklärt. Es gibt hilfreiche Blog-Einträge im Internet und zwei vitale Mailinglisten für Anwender und Entwickler. Und wer es ganz genau wissen möchte, kann jederzeit den Quelltext inspizieren2. Warum also ein Hudson-Buch?

Viele Anwender hatten das Zusammenpuzzeln von Informationshäppchen aus dem Internet leid und wünschten sich nicht nur Beschreibungen zu einzelnen Hudson-Funktionen, sondern auch konzeptionelles Hintergrundwissen zur CI sowie Erfahrungsberichte aus erfolgreichen CI-Einführungen. Erstaunlicherweise ist das Buchangebot für CI-Titel sehr überschaubar, z. B. [Duval07]. Andere Werke stellen das Thema vor, können aber aus Platzgründen nur sehr bedingt in die Tiefe gehen [Hüttermann10, Larman10, Smart08, Hüttermann07, Clark04]. Titel explizit zu Hudson sucht man komplett vergeblich. Selbst auf dem internationalen Buchmarkt existieren momentan nur Veröffentlichungen in der Entstehungsphase, etwa das lesenswerte, aber bisher nur in Englisch verfügbare Open-Source-Buch von J. F. Smart [Smart10].

Umso mehr freute mich die Anfrage des dpunkt.verlages im Sommer 2009, »ob denn der deutsche Buchmarkt für ein Hudson-Buch reif wäre?«. Aus dieser Anfrage entwickelte sich das Ergebnis, das Sie nun in den Händen halten. Es soll Sie in folgenden Aspekten unterstützen:

CI-Grundlagen:

Eine umfassende Einführung in die Konzepte, Vorteile und Herausforderungen kontinuierlicher Integration. Durch die produktneutrale Darstellung bleibt dieser Teil unabhängig von ständig neu erscheinenden Systemen und Versionen relevant.

Hudson für Einsteiger:

Ein schneller Start mit Hudson, von der Installation über die Konfiguration bis hin zur Anwendung im Alltag

Hudson für Fortgeschrittene:

Anregungen zu Themen wie Build-Zeit-Optimierung, verteiltem Bauen oder der Entwicklung eigener Plugins

CI einführen:

Praxistipps zur erfolgreichen CI-Einführung in Ihrer Organisation, mit Fallstudien aus unterschiedlichen Unternehmensgrößen

Darüber hinaus soll dieses Buch nicht nur Ihren Kopf, sondern auch Ihren Bauch ansprechen und Ihnen Lust auf kontinuierliches Integrieren machen. Wie oft in Softwaretechnik stellt auch bei der CI der Mensch einen maßgeblichen Erfolgsfaktor dar. Wissen und Werkzeuge sind nutzlos, wenn CI nicht wirklich gelebt wird. In diesem Sinne wünsche ich Ihnen nicht nur großen Wissenszuwachs bei der Lektüre, sondern im Idealfall auch gute Unterhaltung.

1.5 Wer dieses Buch lesen sollte

Was bringt Ihnen dieses Buch?Dieses Buch wurde primär für Softwareentwickler und -architekten konzipiert, dürfte aber auch IT-Projektleitern und Informatikstudierenden nützen:

Entwickler und Architekten:

In diesem Buch lernen Sie Werkzeuge und Verfahren kennen, die Sie von lästigen Routineaufgaben entlasten und Ihnen mehr Zeit für die kreativen und kniffligen Aufgaben der Softwareerstellung lassen. Sie werden sich mit Hudson ein zuverlässiges Frühwarnsystem einrichten, das Sie Probleme beheben lässt – längst bevor sie bei den Kollegen der Qualitätssicherung, Ihren Chefs oder Kunden aufschlagen.

IT-Projektleiter:

Softwareentwicklung steckt voller Überraschungen. Ihr Releaseprozess sollte keine davon sein. Sie werden Werkzeuge und Verfahren kennenlernen, die Ihnen helfen, Risiken zu minimieren und Qualität zu steigern. Sie werden CI erfolgreich in Ihrer Organisation einführen, weil Sie mit diesem Buch auf bewährten Vorgehensweisen und dem bereits bezahlten Lehrgeld anderer Teams aufbauen können.

Informatikstudierende:

In diesem Buch lernen Sie Werkzeuge und Verfahren kennen, deren Wert zwar im Prinzip unbestritten, aber längst noch nicht Standard in allen Entwicklungsteams ist. Ob als Praktikant oder baldiger Berufseinsteiger: Mit Ihrem CI-Wissen haben Sie eine Trumpfkarte im Ärmel, die Ihnen auch als »Junior« den Respekt Ihrer Kollegen einbringen kann. Hudsons geringer Ressourcenbedarf und seine hohe Anpassungsfähigkeit erlauben problemlos eine Einführung »nur mal als Experiment«, ohne gleich eine bestehende Infrastruktur komplett auf den Kopf stellen zu müssen.

Benötigtes VorwissenIdealerweise haben Sie bereits Erfahrung in Softwareprojekten sammeln können und die Höhen und Tiefen einer Produktentwicklung miterlebt. Die meisten Beispiele in diesem Buch verwenden als Technologiestapel Java, Maven und Subversion. Sie benötigen lediglich Grundkenntnisse in diesen Technologien, um dem vorliegenden Buch folgen zu können. Trotzdem sei Ihnen an dieser Stelle eine hervorragende Einführung in das Konfigurationsmanagement ans Herz gelegt [Popp09]. Der optimale Einsatz eines Versionsmanagementsystems und die Erstellung von Build-Skripten mit Ant oder Maven sind Gebiete, die problemlos den Rahmen dieses vorliegenden Werkes sprengen würden.

Windows, Linux oder Mac OS X?Hudson ist in Java implementiert und daher auf vielen Plattformen verfügbar, darunter auch Windows, Linux, Mac OS X. Rund zwei Drittel aller Hudson-Server werden unter Linux betrieben. Auf den Entwicklerarbeitsplätzen dominiert hingegen meist Windows. Die Beispiele in diesem Buch sind daher aus der Perspektive eines Entwicklers mit einem Windows-System gewählt. Durch Javas Plattformunabhängigkeit ist dies aber nur an wenigen Stellen von Bedeutung. Sie werden im Buch auf diese wichtigen Unterschiede jeweils hingewiesen werden. Auch softwareentwickelnde Mac-OS-X-Anwender dürften keine Probleme haben, sich an den Windows-Beispielen zu orientieren.

1.6 Wie man dieses Buch lesen sollte

Dieses Buch ist so strukturiert, dass Sie es linar von vorne bis nach hinten lesen können und dabei von den Grundlagen zu immer fortgeschritteneren Themen geführt werden.

Wenn Sie wenig Zeit haben…Sollten Sie jedoch wenig Zeit haben, möchte ich Ihnen untenstehende Lesepfade mit passenden Abkürzungen empfehlen (Abb. 1–2). Die ausgelassenen Kapitel können Sie dann später, je nach persönlichem Bedarf, in Angriff nehmen.

image

Abb. 1–2
Empfohlene Lesepfade für die Zielgruppen dieses Buches

Entwickler und Architekten:

Beginnen Sie mit den CI-Grundlagen in Teil 1 und lernen Sie Hudson in Teil 2 komplett kennen. Überfliegen Sie abschließend Teil 3, um einen Eindruck von den organisatorischen Aspekten einer CI-Einführung zu bekommen.

IT-Projektleiter:

Beginnen Sie mit den CI-Grundlagen in Teil 1 und lernen Sie Hudson in Teil 2 steckbriefartig kennen. Da Sie Hudson hauptsächlich als Beobachter verwenden werden, überspringen Sie die technischen Details. Die organisatorischen Aspekte in Teil 3 sind für Sie relevanter. Sie sollten diesen Teil daher komplett lesen.

Studierende:

Beginnen Sie mit den CI-Grundlagen in Teil 1. Lernen Sie danach Hudson in Teil 2 detailliert kennen, sparen sich jedoch die ganz fortgeschrittenen Themen wie etwa Plugin-Entwicklung für später auf. Überfliegen Sie abschließend Teil 3, um einen Eindruck von den organisatorischen Aspekten einer CI-Einführung zu bekommen.

1.7 Konventionen

Deutsche und englische FachbegriffeIn diesem Buch finden Sie überwiegend deutsche Fachbegriffe. Sollte keine allgemein akzeptierte deutsche Übersetzung existieren oder der Bezug zur Dokumentation eines Werkzeuges durch die Übersetzung erschwert werden, wurden die englischen Begriffe belassen. Deutschen Übersetzungen ist bei der ersten Verwendung der englische Originalbegriff in Klammern (brackets) nachgestellt.

TypografieDer kursive Schriftschnitt hebt wichtige Stellen hervor. Texte, die der Benutzeroberfläche Hudsons entnommen wurden (z. B. Hudson image Hudson verwalten), sind ebenfalls kursiv gestellt.

Ausschnitte aus Quelltexten oder der Kommandozeile sind in der Schriftart LetterGothic dargestellt. Passen Quelltexte oder Befehle nicht in eine Zeile, wurden Sie mithilfe des Zeichens image umbrochen:

image

1.8 Website zum Buch

Auf der Website zum Buch, www.ci-mit-hudson.de, finden Sie Fehlerkorrekturen, ein Literaturverzeichnis mit »anklickbaren« Links sowie die Quelltexte zur Plugin-Entwicklung aus Kapitel 9.

1.9 Danksagungen

Mein herzlicher Dank gilt zunächst meinem Lektor René Schönfeldt. Er ermunterte mich nicht nur erfolgreich zu diesem Buchprojekt, sondern verlor auch bei grotesken Terminverspätungen meinerseits nie die Fassung.

Großer Respekt gebührt außerdem den aufmerksamen und kritischen Lesern der Betaversionen dieses Buches: Ullrich Hafner, Michael Hüttermann, Jan Matèrne, Hans-Peter Seitz, Martin Stransfeldt, Jürgen Walter, Lorenz Wiest sowie den unbestechlichen anonymen Gutachtern! Mario Ernst danke ich für seine Recherche zum Thema »Blau/Grün« im japanischen Kulturkreis.

Am meisten stehe ich jedoch in der Schuld meiner Familie, allen voran meiner Frau Evelyn und meiner Tochter Floriane, die in den letzten Monaten viel zu oft auf Ehemann und Papa verzichten mussten. Ohne Euer Verständnis gäbe es dieses Buch nicht. Danke.

Simon Wiest
Gomaringen, im Oktober 2010

1.10 Zusammenfassung

Dieses Kapitel eröffnete Ihnen einen ersten Einblick in die Welt der CI: Sie haben erfahren, welche Probleme CI lösen möchte, und Sie haben Hudson als verbreitetes CI-System kennengelernt. Sie wissen, was Sie als Entwickler, IT-Projektleiter oder Studierender in diesem Buch erwartet, und kennen Ihren optimalen Lesepfad.

Im nächsten Kapitel definieren wir genauer, was Continuous Integration ist – und was nicht. Anschließend statten wir »unserem« Entwicklungsteam vom Beginn dieses Kapitels zwei Besuche ab, jeweils vor und nach der CI-Einführung. Ähnlichkeiten mit Ihrem Alltag sind nicht ausgeschlossen …

1. http://hudson-ci.org

2. Sie müssen dazu den Quelltext nicht herunterladen. Unter http://fisheye.hudson-ci.org können Sie diesen auch bequem im Webbrowser einsehen.

2 CI in 20 Minuten

Erinnern Sie sich noch an die Integrationshölle, die das Softwareteam zu Beginn des vorausgegangenen Kapitels durchschreiten musste? Wie Sie richtig vermuten, könnte CI viele der beschriebenen Probleme lösen.

In diesem Kapitel lernen Sie daher zunächst das CI-Konzept in einer knappen Definition kennen: Was also ist CI? Wir fragen aber auch: Was ist CI nicht? Anschließend kehren wir zu »unserem« Softwareteam in einem Vorher-Nachher-Vergleich zurück und überprüfen, wie CI dieses Team im Alltag unterstützen kann.

Nach der Lektüre dieses Kapitels kennen Sie also die Grundzüge der CI und haben einen ersten Eindruck von deren Vorteilen, aber auch von den notwendigen Voraussetzungen. Sie schaffen sich damit eine gute Grundlage für die darauffolgenden zwei Kapitel, die dann auf Vorteile und Voraussetzungen im Detail eingehen werden.

2.1 Was ist CI?

Zahlreiche Softwareteams dürften unabhängig voneinander die Idee des kontinuierlichen Integrierens »erfunden« haben. Populär geworden ist sie unter dem Namen »Continuous Integration« jedoch erst als eine der Praktiken der Extremprogrammierung (eXtreme Programming, kurz: XP), wie beispielsweise durch Kent Beck beschrieben [Beck99].

CI nach Martin FowlerBegriffsbildend dürfte letztendlich Martin Fowlers Artikel »Continuous Integration« gewesen sein, in dem er das Kernkonzept folgendermaßen beschreibt:

»Die Kontinuierliche Integration ist eine Softwareentwicklungspraktik, bei der Teammitglieder ihre Arbeit häufig integrieren. Üblicherweise integriert jede Person im Team mindestens einmal täglich was zu mehreren Integrationen am Tag führt. Jede Integration wird durch einen vollautomatisierten Build (und Test) geprüft, um Fehler so schnell wie möglich aufzudecken« ([Fowler00], aus dem englischen Original übersetzt).

Im Kern geht es also darum, die Integration aller Codeänderungen nicht mehr als eine einmalige Phase am Ende eines Entwicklungsprojekts zu betrachten. Vielmehr soll diese »Endmontage« einer Software viel häufiger erfolgen, typischerweise sogar mehrfach am Tag. Im Idealfall wird die Integration damit zum »Nicht-Ereignis«, da sie ohnehin ständig stattfindet. Vorteil: Wer mehrmals täglich den Ernstfall probt, hat auch keine Angst mehr davor.

Der Entwicklungsprozess mit CIWie sieht also der Entwicklungsprozess in einem minimalen CI-System aus? Betrachten wir dazu den Ablauf der kontinuierlichen Integration (CI) in Abbildung 2–1:

image

Abb. 2–1
Ablauf der kontinuierlichen Integration (CI)

Neuer Code entsteht zunächst auf den Rechnern der Entwickler. Nach eingehender lokaler Überprüfung durch den Entwickler werden alle Codeänderungen an ein zentrales Versionskontrollsystem übertragen (1). Dieser Vorgang wird vom CI-Sever bemerkt (2), der daraufhin einen neuen Build auf Build-Servern veranlasst (3). Nach Abschluss des Builds werden die Ergebnisse (Programme, Testberichte, Dokumentationen usw.) auf den CI-Server zur Auswertung und Archivierung übertragen (4). Über geeignete Kommunikationskanäle (E-Mail, RSS, Issue-Tracker usw.) meldet der CI-Server den Ausgang des Builds an die Entwickler zurück (6). Diese bekommen so eine zeitnahe positive Bestätigung ihrer Arbeitsergebnisse – oder aber einen Hinweis auf neu aufgetretene Fehler. In diesem Falle kann der Entwickler sofort mit der Verbesserung seines Codes beginnen: Der CI-Zyklus beginnt von vorne. Darüber hinaus können auch andere interessierte Parteien den aktuellen Stand der Softwareentwicklung verfolgen, z. B. Teamleiter, Tester, Kunden usw.

Voraussetzungen für CICI-Systeme haben in der Praxis zahlreiche Schnittstellen zu weiteren IT-Systemen (z.B. zentrales Benutzerverzeichnis, Test- und Produktionsserver, Software-Repositories). In kleineren Arbeitsgruppen werden die benötigten Dienste oftmals auf derselben Hardware ausgeführt, in großen Unternehmen werden hingegen eigens dafür vorgesehene Server eingesetzt. Das Funktionsprinzip ist jedoch das gleiche und setzt hinsichtlich des Entwicklungsprozesses gewisse Rahmenbedingungen voraus. Genau betrachtet können diese fast vollständig aus der Anforderung des häufigen Bauens (und Testens) abgeleitet werden. Fowler zählt in seinem Artikel folgende zehn Praktiken als Voraussetzung für wirkungsvolles CI auf:

1. Gemeinsame Codebasis:

Alle Daten, die in ein Produkt eingehen, werden an einem gemeinsamen Ort verwaltet, typischerweise in einem Versionskontrollsystem.

2. Automatisierter Build:

Das Produkt muss vollautomatisch aus seinen Grundbestandteilen übersetzt und zusammengebaut werden können.

3. Selbsttestender Build:

Entstandene Produkte werden während des Builds automatisch auf korrekte Funktionsweise überprüft.

4. Häufige Integration:

Entwickler integrieren ihre Arbeitsergebnisse mindestens einmal pro Tag. Anders ausgedrückt: Sie checken mindestens einmal am Tag ihren Stand in das Versionskontrollsystem ein.

5. Builds (und Tests) nach jeder Änderung:

Nach jeder Änderung wird vollautomatisch gebaut und getestet. Sind die Änderungen klein, lassen sich so neue Fehler sehr schnell in den korrespondierenden Änderungen auffinden.

6. Schnelle Build-Zyklen:

Zwischen dem Einchecken einer Änderung und der Rückmeldung durch das CI-System sollte möglichst wenig Zeit vergehen. Idealerweise liegt diese Dauer im Minutenbereich.

7. Tests in gespiegelter Produktionsumgebung:

Tests sollten in einer möglichst realitätsnahen Umgebung stattfinden. In der Konsequenz muss also auch der Aufbau dieser Testumgebungen automatisiert werden.

8. Einfacher Zugriff auf Build-Ergebnisse:

Der letzte Stand des Produkts sollte für alle Beteiligten einfach zugänglich sein. Dies gilt nicht nur für Entwickler, sondern auch für Tester, Kundenberater, Projektleiter usw.

9. Automatisierte Berichte:

Die Ergebnisse der Builds müssen vollautomatisch »gebrauchsfertig« aufbereitet werden. Zum einen beinhaltet dies das Verschicken von Benachrichtigungen, zum anderen auch die Visualisierung von archivierten Informationen aus vergangenen Builds.

10. Automatisierte Verteilung:

Ein CI-System sollte nicht nur den Softwareerstellungsprozess automatisieren, sondern auch die Verteilung zu den jeweiligen Anwendern bzw. das Ausbringen auf Test-, Demonstrations- und Produktionsserver.

Wenn Sie sich die Liste der zehn Praktiken betrachten, fragen Sie sich vermutlich, ob hier nicht zu viel vorausgesetzt wird? Muss nicht zu viel umgestellt werden? Lohnt sich dieser Aufwand?

Um es vorwegzunehmen: Es lohnt sich auf jeden Fall! Jede dieser Praktiken ist bereits für sich isoliert gesehen wertvoll und wird vielleicht sogar bereits in Ihrer Arbeitsgruppe praktiziert. Erst in der Summe hingegen ermöglichen sie einen runden Entwicklungsprozess, der auf hoher Frequenz kontinuierlich wechselt zwischen Entwickeln, Einchecken, Bauen, Testen, Berichten und erneut Entwickeln, Einchecken, Bauen, …

2.2 Was ist CI nicht?

Wie wir im vorausgegangenen Abschnitt gesehen haben, beinhaltet CI eine weitestgehende Automatisierung typischer Arbeitsschritte der Softwareentwicklung, z. B. Kompilieren, Testen, Archivieren, Verteilen, Berichten (denken muss man glücklicherweise noch selber). Kein Wunder also, dass kaum ein anderer Dienst mit so vielen anderen IT-Systemen in Kontakt steht wie ein CI-Server: vom Versionskontrollsystem bis zum E-Mail-Server, von der Benutzerverwaltung bis zum Produktionsserver.

Das Build-OrchesterIm Zusammenspiel dieser IT-Systeme übernimmt der CI-Server sozusagen die Rolle des Dirigenten im »Build-Orchester«. Sicher – man kann auch ohne CI brauchbare Software erstellen. Und genauso würden die Berliner Philharmoniker auch ohne Dirigent locker vom Blatt musizieren können. Ungleich besser wird das Ergebnis jedoch unter der Leitung eines Sir Simon Rattle. Rattle selbst greift dabei weder zur Bratsche noch zur Oboe. Stattdessen überlässt er dies den jeweiligen Virtuosen. Trotzdem ist sein »Mehrwert« so groß, dass er als Dirigent auf Konzertplakaten zuerst aufgeführt wird. Analog gilt für Continuous Integration:

• CI ist keine Programmiersprache wie C/C++, Python oder Java. Sie steuert aber die entsprechenden Compiler, um Quelltexte zu übersetzen.

• CI ist kein Build-Werkzeug wie Make, Ant oder Maven. Sie ruft aber typischerweise solche Werkzeuge auf.

• CI ist kein Versionskontrollsystem wie Subversion, CVS, Git oder Perforce. Sie kommuniziert aber mit ihnen, um von Codeänderungen der Entwickler zu erfahren.

• CI ist kein Test-Framework wie JUnit, TestNG oder Selenium. Sie ruft aber solche Frameworks auf, um übersetzte Programme zu testen.

• CI ist kein Werkzeug für statische Codeanalyse wie PMD, Checkstyle oder FindBugs. Sehr wohl aber werden diese Werkzeuge in einem CI-Build aufgerufen und deren Ergebnisse ausgewertet.

• CI ist kein Repository für erzeugte Artefakte wie Nexus oder Artifactory. Sie kann aber Produkte eines CI-Builds dort ablegen und so anderen IT-Systemen und Entwicklern bereitstellen.

• CI ist kein einzelnes Produkt, sondern integriert vielmehr eine Vielzahl von Technologien für die jeweiligen Arbeitsschritte der Softwareerstellung (Compiler, Build-Werkzeuge, Testverfahren usw.)

• CI ist keine markengeschützte Methode, für die sich Zertifikate sammeln lassen. In der agilen Softwareentwicklung ist CI jedoch nicht wegzudenken und auch in anderen Methoden sinnvoll einsetzbar.

Und: CI ist kein Allheilmittel gegen schlechten Code, fehlerhafte Software und enge Projektzeitpläne. Sie hilft aber, Probleme schneller zu entdecken und früher zu beheben. Dies spart Zeit in nachgelagerten Phasen und vergrößert den zeitlichen Puffer für Unvorhergesehenes (»Alle mal herhören: Unser Kunde hat gerade angerufen …«).

Nachdem wir uns vom CI-Ablauf und der eingesetzten Technik ein Bild gemacht haben, wollen wir in den nächsten zwei Abschnitten CI an einem Vorher-Nacher-Beispiel betrachten.

2.3 Software entwickeln ohne CI

Zu Beginn des vorangegangenen Kapitels hatten wir ein Softwareteam in der heißen Phase der Release-Integration besucht. Erinnern Sie sich noch an die Tiefpunkte, mit denen dieses Team ohne Continuous Integration zu kämpfen hatte? Hier ein »Worst of«:

Integration als besondere Aktivität»Am kommenden Tag soll Ihre Abteilung die längst überfällige neue Version Ihrer Software ausliefern …« – Die Integration wurde bis auf den letzten Drücker hinausgeschoben, weil sie nicht als Teil des Entwicklungsprozesses betrachtet oder im Eifer der Codierung verdrängt wurde (»Der Kunde bezahlt uns fürs Programmieren und nicht fürs Dateien zusammenkopieren.«).

Späte Integration»Die Entwickler werfen also eilig auf dem Abteilungsserver ihre Codeänderungen ab, die sie in den letzten Wochen auf ihren Rechnern erbrütet haben.« – Code wurde über Tage und Wochen in Silos lokal entwickelt. Schnittstellen und Abhängigkeiten diffundieren dabei zwangsläufig auseinander, wenn nicht immenser Abstimmungsaufwand betrieben wird (»Oh je – alle in den Teamraum! Wir müssen ganz dringend noch ein Meeting machen.«).

Tests als »Code zweiter Klasse«»Die (spärlich) vorhandenen Tests schlagen fehl, manchmal aber auch nicht.« – Die Tests deckten nur geringe Teile des zu prüfenden Codes ab. Zusätzlich trugen unzuverlässige Tests das Übrige bei, um das Vertrauen in Testberichte zu erschüttern. Sicheres Alarmsignal hierfür sind Dialoge nach folgendem Schema: Projektleiter: »Ist das Feature komplett?« Entwickler: »Die automatischen Tests laufen eigentlich durch, aber die Tester müssten sich das trotzdem nochmals gründlich anschauen …«

Keine Builds auf neutralem Grund»Bei mir läuft’s aber! – Ich habe dort nichts geändert!« – Jeder Entwickler arbeitet auf seinem Rechner in seinem persönlichen lokalen Ökosystem aus Werkzeugen, Einstellungen und ausgecheckten Quelltexten. Kein Wunder, dass auf unterschiedlichen Rechnern unterschiedliche Ergebnisse beobachtet werden können. Wer aber hat Recht, wenn es keine verbindliche und neutrale Instanz gibt, die hier entscheidet?

Lange Build- und Test-Zyklen»Am späten Abend laufen die Tests endlich durch.« – Lange Build-Zeiten bedeuten weniger Chancen pro Tag, um geänderten Code zu bauen und zu testen. Das Resultat ist Programmierung im Stile von »Commit and Run«: Kurz vor Arbeitsende einchecken, dann schnell den Arbeitsplatz verlassen und am nächsten Morgen in den Trümmern nachschauen, wie der nächtliche Build mit den Änderungen klargekommen ist. So griffig dieses Konzept sein mag, so stark limitiert es die Anzahl an Rückmeldungen zum Entwickler – in diesem Fall auf eine pro Tag.

Geringe Automatisierung und Dokumentation kritischer Schritte»Als langjähriger Mitarbeiter mit Kopfmonopol kennt der Meister als Einziger die geheimen Schritte, die notwendig sind, um eine Distribution zu erstellen – und ja, nur er hat die notwendigen Werkzeuge dazu auf seinem Rechner installiert.« – Teile des Erstellungsprozesses sind nicht dokumentiert, werden manuell ausgeführt und können nur in bestimmten Rechnerumgebungen stattfinden. Folgerichtig tauchen im Ablauf der Softwareerstellung immer wieder Flüchtigkeitsfehler durch menschliche Nachlässigkeit auf. Im besten Falle sind sie nur lästig, im schlimmsten Falle aber fatal – denn durch die Abhängigkeit von wenigen Köpfen und Rechnern hat man gleich mehrere K.o.-Punkte (single points of failure) geschaffen.

Geringe Automatisierung der Dokumentation»Das Team hat Bauchschmerzen, denn keiner weiß wirklich genau, welche Änderungen in dieses Release eingeflossen sind.« – Von Hand erzeugte Dokumentation kann selten mit dem Tempo der Änderungen in einem Softwareprojekt mithalten. Im Ergebnis erhält man Dokumentation, die erfreulicherweise zu 80% auf dem neuesten Stand ist. Leider weiß man hingegen nicht, welche 20% der Dokumentation inzwischen veraltet sind …

2.4 Software entwickeln mit CI

Besuchen wir »unser« Softwareteam ein paar Monate später. Der hohe Leidensdruck in den Integrationsphasen führte zur Installation eines CI-Servers, der nun stetig das Zusammenspiel aller beteiligten Personen und IT-Systeme koordiniert.

Integration als »Nicht-Ereignis«Seit der Vollautomatisierung der Integration erstellt der CI-Server inzwischen vollautomatisch aus den Quelltexten des Versionsmanagementsystems das fertige Produkt – genau so, wie es der Kunde letztendlich erhält: Ein Installationsprogramm, eine Liste mit den Änderungen seit der letzten Version, eine aktuelle Dokumentation der externen Schnittstellen sowie ein Prüfprotokoll des vorgeschriebenen Testlaufs. Die Integration ist zum »Nicht-Ereignis« geworden.

Häufige Integration, häufiges ErfolgserlebnisDie Entwickler wurden in der Folge geradezu süchtig nach dem »schnellen Erfolgserlebnis« und checken nun ihre Änderungen nach eingehender lokaler Prüfung sehr viel häufiger ein.

Tests als »Code erster Klasse«Durch zusätzliche Tests konnte die Codeabdeckung erhöht werden. Vor allem aber wurden unzuverlässige Tests überarbeitet, so dass deren Ausgang nun nicht mehr von veränderlichen Einflüssen wie Netzwerkbandbreite oder der momentanen Auslastung des E-Mail-Servers abhängt. Und weil auf Testberichte wieder Verlass ist, erhalten fehlgeschlagene Tests sofortige Aufmerksamkeit.

Builds auf neutralem GrundImmer noch kommt es vor, dass Entwickler auf unterschiedlichen Rechnern zu unterschiedlichen Ergebnissen kommen. Entscheidend ist aber nun, was das CI-System nach Ausführung der Tests befindet. Somit gibt es endlich einen neutralen Schiedsrichter, der – frei von Skrupel und Häme – aufgetretene Probleme und fehlgeschlagene Tests mitteilt.

Kurze Build- und Test-ZyklenDie Build-Zeit konnte durch geschickte Verteilung und Parallelisierung auf mehrere Rechner auf unter 15 Minuten gedrückt werden. Dadurch wurde der Taktschlag ganz erheblich erhöht und langes »Codieren im Nebel« abgeschafft.

Vollautomatisierung kritischer SchritteDurch die Automatisierung kann inzwischen selbst der Praktikant eine aktuelle Produktversion zu Demonstrationszwecken für den Vertrieb erstellen. Die erfahrenen Entwickler haben damit auch endlich wieder mehr Zeit, sich um wirklich knifflige Probleme zu kümmern oder den Junior-Entwicklern Tricks aus ihrem Erfahrungsschatz beizubringen.

Automatische Erstellung der DokumentationDie Schnittstellendokumentation wird endlich nicht mehr von Hand in einer Textverarbeitung geführt, sondern in jedem Build aufs Neue vollautomatisch aus den Quelltexten erzeugt. Seitdem hatte es wesentlich weniger Anrufe erboster Kunden gegeben, die – streng der veralteten Dokumentation folgend – Fehlermeldungen beim Aufruf nicht mehr vorhandener Funktionen erhalten hatten.

GruppenstolzIm Abteilungsflur fallen drei niedliche Lampen in Form von Gummibären auf. Sie sind in den Ampelfarben Rot, Gelb und Grün aufgestellt und zeigen rund um die Uhr die Testergebnisse des letzten Projekt-Builds an. Zurzeit leuchtet der grüne Bär, was selbst für Branchenfremde als gutes Zeichen interpretierbar ist. Ein dankbarer Entwickler huscht vorbei und stellt vor dem grünen Bären ein kleines Schälchen mit Süßigkeiten ab …

2.5 Zusammenfassung