inkl. JAVA Mag DVD DVD-INHALT Android: Datenbank und Content-Provider»113 Deutschland 12,90 Österreich 14,80 Schweiz sfr 25,50 5.2011 magazin Java Architekturen Web Agile JBoss ESB Prozessmodellierung im Service Bus»71 WIKI Plus Atlassian Confluence»60 www.javamagazin.de Alle Infos im Heft»50 JAHRES-ARCHIV 2010 Alle Ausgaben und Quellcodes aus dem Jahr 2010 JAX TV Continuous Integration State-of-the-Art mit Hudson /Jenkins > 36 Interviews mit Kohsuke Kawaguchi und Jason van Zyl > 44, 46 Was steckt hinter CloudBees > 48 BUCHAUSZÜGE mit Axis2 Alle DVD-Infos ab Seite 2 Scala 2.8 Neue Sprach-Features» 26 PrettyFaces Schöneres JSF» 94 Hibernate Search Das Runde muss ins Eckige» 52
Titelthema Continuous Integration Continuous Builds mit HudsonJenkins Zu Ihren Diensten, Sir! Mein Name ist Bob Bob D. Veloper. Ich arbeite in einem IT-Unternehmen und ich habe ein großes Problem. von Thorsten Kamann, Hanno Wendt und Bob D. Veloper In unserem Unternehmen entwickeln wir Webanwendungen für die Java-Plattform. Generell kann ich über den Entwicklungsprozess nicht klagen. Wenn da nicht die große Anzahl von Bugs in manchen der durchaus großen Anwendungen wäre. Dieses Problem hatten wir schon vor einigen Jahren, haben es aber mit automatischen Builds in den Griff bekommen. Super werden Sie jetzt denken. Der Mann hat s richtig gemacht. Aber bevor Sie enttäuscht diesen Artikel zur Seite legen: dieser automatische Build bestand aus einigen Perl-Skripten, die Ant starteten und den Build durchlaufen ließen. Bei einem Fehler wurde unser BiT (Build-Manager in Teilzeit) informiert. Und wenn er es nicht vergessen hat, hat er die Fehlermeldung an unseren Entwicklungsverteiler geschickt. Die Häufung der Bugs hat das Management veranlasst, sich das Thema einmal genauer anzusehen. Meine Rolle dabei ist, einen State-of-the-Art Continuous Build aufzusetzen. Womit wir beim Thema wären. Was ist denn ein State-of-the-Art Continuous Build? Das konnte das Management (natürlich) nicht beantworten. Ich habe mich im Internet und entsprechenden Fachmagazinen kundig gemacht, wie so etwas heutzutage gelöst wird. Ich konnte mir nicht vorstellen, dass unser Unternehmen das einzige mit solchen Problemen ist. Nach einiger Zeit kristallisierten sich grundlegende Ideen heraus: Builds werden direkt nach einem Commit in das Versionierungssystem automatisch gestartet Innerhalb dieser Builds werden auch die Unit Tests ausgeführt aber nur die Unit Tests Das so erzeugte Artefakt (z. B. Jar oder War) wird automatisch in ein Ablagesystem übertragen Bei einem Fehler werden das Team und insbesondere der Verursacher informiert Sie sehen, wir haben einiges zu tun. Wir? fragen Sie sich. Ja, wir werden das alles zusammen erledigen. Doch vorher möchte ich Ihnen noch Ivan Popov vorstellen. Ivan ist Administrator. Er wird die Installation der Serverkomponente vornehmen. Die Qual der Wahl Für den Continuous Build wird ein Tool benutzt davon gibt es einige, sowohl Open Source als auch kommer- 36 javamagazin 5 2011
Continuous Integration Titelthema ziell. Wir haben uns sehr früh auf eine Open-Source- Lösung geeinigt. Aus den verfügbaren Lösungen stach Hudson hervor. Hudson [1] hat schon etwas Vergangenheit hinter sich. Von Sun unterstützt, wurde Hudson zu dem Continuous-Integration-System auf java.net und später das beliebteste Open-Source-CI-System. Nach der Übernahme Suns durch Oracle entbrannte plötzlich ein Streit über die Rechte an der Codebasis und dem Namen. Daraus entstand Jenkins [2]. Er ist eigentlich baugleich mit Hudson. Was die Zukunft bringt, werden wir in den nächsten Monaten erfahren. Ivan und ich haben uns für Jenkins entschieden. Installation von Jenkins Haben Sie bereits einen Tomcat aufgesetzt, so können Sie das WAR-Archiv von Jenkins einfach in das webapps- Verzeichnis kopieren. Auch ohne bereits installierten Tomcat ist der Start von Jenkins sehr einfach. Ein java jarjenkins.war startet den integrierten Winstone Servlet-Container und stellt eine Instanz von Jenkins zur Verfügung. Unter den Adressen http://localhost:8080/ jenkins (Tomcat) oder http://localhost:8080 (integrierter Winstone) können Sie einen ersten Blick auf Ihren neuen Continuous Integration Server werfen (Abb. 1). Die Oberfläche von Jenkins ist sehr einfach gehalten: Im linken Bereich finden sich die kontextsensitive Navigation und darunter eine Übersicht der geplanten bzw. aktuell laufenden Builds. Den Hauptteil der Anwendung macht der Inhaltsbereich aus, in dem Konfigurationen, Übersichten und die Live-Konsolenausgabe angezeigt werden. Initiale Konfiguration Bevor Jenkins mit der Arbeit beginnen kann, benötigt er etwas Werkzeug. Die Minimalausrüstung bilden: ein JDK ein Build-Tool wie Maven, Ant, Gradle... ein Konnektor für das verwendete Source Control Management (SCM) Verwenden Sie als SCM Subversion oder CVS, dann benötigen Sie keinen zusätzlichen Konnektor mehr, da die Unterstützung direkt in Jenkins integriert ist. Für alle anderen gängigen SCM gibt es bereits Plug-ins [3]. Um ein Plug-in zu installieren, können Sie die Plug-in- Verwaltung von Jenkins aufrufen: Jenkins verwalten Plugins verwalten. Nach der Installation muss Jen- javamagazin 5 2011 37
Titelthema Continuous Integration deutlich mehr leisten kann, als nur einen Build zu starten. Ein Job besteht aus mehreren Phasen: Vorbereitung Abarbeitung Nachbereitung Abb. 1: Startbildschirm des neu installierten Jenkins kins neu gestartet werden, um die neu installierten Plugins zu aktivieren. Der nächste Schritt besteht aus einigen Konfigurationen, die Sie alle unter Jenkins verwalten System konfigurieren erledigen können. Die relevanten Bereiche in der Systemkonfiguration sind JDK und Maven. Beide Tools können Sie so konfigurieren, dass die aktuellen Versionen von den Hersteller- bzw. Projektseiten geladen werden. Ist das erledigt, können Sie Ihr erstes Projekt konfigurieren und die Build-Automatisierung dafür starten. Der erste Job Jenkins Arbeit wird in so genannte Jobs aufgeteilt. Grob könnte man sagen, dass ein Build ein Job ist. Das greift aber etwas zu kurz, da Jenkins innerhalb eines Jobs Abb. 2: Exemplarischer Workfl ow Jede dieser einzelnen Verarbeitungsphasen kann aus einer oder mehreren Aktionen (Actions) bestehen. In den meisten Jobs besteht die Vorbereitung darin, den zu kompilierenden Quellcode aus dem SCM der Wahl auszuchecken. Die Hauptarbeit besteht anschließend darin, den Quellcode zu bauen. Die Nachbereitung hat dann oft schon ein paar Aktionen mehr. Testergebnisse werden zusammengefasst, die erzeugten Artefakte archiviert und der Stand des SCM getaggt (Abb. 2). In unserem ersten Job wollen wir möglichst alle Standardeinstellungen behalten und nur die absolut notwendigsten Dinge konfigurieren. Dazu rufen Sie das Menü Neuen Job anlegen auf. In dem darauf folgenden Dialog geben Sie dem Job einen aussagekräftigen Namen, wie z. B. My_First_Jenkins_Job_1.0.0. Als Jobtyp wählen Sie Maven 2 Projekt bauen. Der Klick auf OK leitet Sie dann auf die eigentliche Konfigurationsseite weiter. Hier müssen Sie nur die Angaben für das SCM machen und etwas weiter unten in der Build-Sektion die gewünschten Maven-Goals angeben (Abb. 3). Damit haben Sie Ihren ersten Job fertig konfiguriert. Ein Klick auf Übernehmen bringt Sie auf die Übersichtsseite des Jobs, auf der Sie den Job mittels Jetzt bauen starten können. Jenkins startet den Job und nach einiger Zeit präsentiert er das Ergebnis. Während Jenkins arbeitet, sehen Sie links den Fortschritt. Klicken Sie auf die Fortschrittsleiste, gelangen Sie direkt zu der Konsolenausgabe und können live miterleben, was Jenkins überhaupt macht. Nach dieser kurzen Einführung kehren wir zurück zu Bob und Ivan. Ausführung von Tests Unser größtes Problem ist die automatische Ausführung von Tests und deren Auswertung. Wir haben einige Tests, die auch bisher ausgeführt wurden. Aber die Auswertung der Ergebnisse fand einfach nicht statt. Das ist einer der Punkte, die wir unbedingt ändern müssen. Jenkins unterstützt uns dabei mit einer sehr guten Integration des Unit-Test-Report-Formats (Surefire), d. h., er kann die von Maven erzeugten junit-berichte auswerten und in einem Diagramm anzeigen. Daraus können Sie bereits einen Trend der Anzahl der Tests und das Verhältnis der erfolgreichen und der fehlgeschlagenen Tests ablesen. Damit die Tests ausgeführt werden, müssen Sie lediglich Maven die entsprechende Anweisung erteilen 38 javamagazin 5 2011
Continuous Integration Titelthema es reicht schon die Angabe des Goals package (siehe auch weiter oben). Jetzt haben wir schon ein sehr wichtiges Ziel erreicht. Wir können die Builds starten, es werden Tests ausgeführt und Berichte erstellt. Absicherung von Jenkins In Jenkins gibt es viel zu konfigurieren. Allerdings kann man mit den vielen Möglichkeiten auch schnell etwas kaputt machen. Deswegen sollten solche Einstellungen auch nur Personen vornehmen, die wissen was sie tun. Ein weiterer Punkt für die Absicherung ist, dass nicht alle alles sehen können sollen. So sind Systemeinstellungen immer nur einem bestimmten Personenkreis zugänglich, da dort auch Passwörter verwaltet werden können. Jenkins bietet verschiedene Absicherungsvarianten: Unix Benutzer-/Gruppenverzeichnis LDAP Jenkins-eigene Benutzerverwaltung Delegation an den Servlet-Container Abb. 3: Jenkins Jobkonfi guration Im Plug-in-Repository gibt es noch weitere Plug-ins für die Zugriffskontrolle, z. B. für den Zugriff auf das firmenweite ActiveDirectory (AD). Allerdings können Sie den Zugriff auf ein AD auch mit dem eingebauten LDAP-Mechanismus bewerkstelligen. Das Gegenstück des ActiveDirectory auf Unix- und Linux-Systemen ist die Benutzer- bzw. Gruppenverwaltung. Jenkins kann genauso gegen die lokal konfigurierten Benutzer authentifizieren. Haben Sie eine kleine Jenkins-Installation, bei der sich der Aufwand für eine externe Benutzerverwaltung nicht lohnt, bietet sich die hausinterne Verwaltung an, die Jenkins bereits selbst mitbringt. Alternativ dazu kann man auch dem Servlet-Container die Benutzerverwaltung überlassen. Das macht Sinn, wenn für eine andere Anwendung bereits so etwas konfi guriert wurde. In unserem Fall wollen wir Jenkins mit LDAP absichern. Das ist schnell gemacht. Sie benötigen die üblichen Informationen für eine LDAP-basierte Authentifizierung. Ist der Zugang konfiguriert, stehen Sie vor der nächsten Entscheidung: Wer darf was? Jenkins bietet hier verschiedene Möglichkeiten: Anzeige
Titelthema Continuous Integration Abb. 4: Konfiguration LDAP Email Plugin Abb. 5: Dumb Slave Jeder darf alles Angemeldete Benutzer dürfen alles Projektbasierte Matrix-Zugriffssteuerung Matrix-basierte Zugriffssteuerung Legacy-Zugriffssteuerung Die erste Option Jeder darf alles entspricht dem Anonymous-Zugang, nur mit dem Vorteil, dass der Benutzername bei einigen Aktionen mit aufgezeichnet werden kann, wenn der Benutzer sich eingeloggt hat. Die zweite Option Angemeldete Benutzer dürfen alles ist eine etwas strengere Option. Hierfür muss der Benutzer zumindest angemeldet sein, um in Jenkins-Einstellungen und -Jobs zu arbeiten. Die beiden folgenden Zugriffsteuerungen basieren auf einer Matrix. Mit Matrix sind hier bestimmte Zugriffe pro Benutzergruppe gemeint. Bei der Projektbasierten Matrix können Sie die Regeln pro Projekt/Job abändern, das ist die mächtigste Zugriffssteuerung in Jenkins. Die Abb. 6: Slave-Konfiguration Windows allgemeine matrixbasierte Zugriffssteuerung bietet dieselben Möglichkeiten, allerdings global für alle Jobs in Jenkins. Die letzte Option spiegelt die Zugriffskontrolle früherer Versionen von Jenkins älterem Bruder Hudson wieder. Während der Benutzer admin alle Rechte hat, besitzt anonymous nur lesende Rechte. Benachrichtigungen Wir sind mit unserem Jenkins schon sehr weit gekommen. Nur was passiert, wenn ein Build fehlschlägt? Das war einer der Schwachpunkte im alten System. Es wurde keiner benachrichtigt, zumindest fast keiner. Der Build-Manager in Teilzeit (BiT) bekam immer eine E-Mail, konnte aber meistens nichts damit anfangen und hatte immer zu wenig Zeit. Das wollen wir dahingehend ändern, dass bei fehlgeschlagenen Builds das Team und insbesondere der Verursacher informiert werden. Dazu konfigurieren wir ein Benachrichtigungsschema. Die Konfiguration der E-Mail-Benachrichtigungen können Sie in der Jobkonfiguration erledigen. Aktivieren Sie die Option E-Mail Benachrichtigung. Dort geben Sie eine oder mehrere E-Mail- Adressen ein, an die die allgemeine Benachrichtigung verschickt werden soll. Hier bietet sich eine Verteilerliste an. Die Option E-Mails bei jedem instabilen Build senden bedeutet, dass auch fehlgeschlagene Tests eine Benachrichtigung erzeugen. Die zweite Option, getrennte E-Mails an diejenigen Anwender zu senden, die den Build fehlschlagen ließen, ermittelt aus einem Commit die Benutzer und versucht sie im Benutzerverzeichnis zu ermitteln. Das klappt natürlich nur zuverlässig, wenn die Benutzer im Versionierungssystem die gleichen wie die in Jenkins sind. Haben Sie sich gegen die Zugriffssteuerung mittels LDAP entschieden, müssen Sie dafür sorgen, dass die E-Mail-Adressen auf einem anderen Weg in Jenkins eingepflegt werden. Bei der Jenkins-eigenen Benutzerverwaltung ist das noch gut möglich, aber wenn der Container die Authentifizierung übernimmt, haben Sie ein Problem. Sind Sie jedoch in der glücklichen Lage, Ihre Benutzer in einem LDAP zu verwalten, können Sie das LDAP Email Plugin installieren. Es sorgt dafür, dass die E-Mail-Adressen aus dem LDAP ermittelt werden, obwohl die Authentifizierung nicht über das LDAP geschieht (Abb. 4). Eine andere direktere Möglichkeit, die beteiligten Personen zu benachrichtigen, ist das Versenden von Instant Messages. Jenkins unterstützt dabei das Jabber- (XMPP) und das IRC-Protokoll. Die Funktionsweise ist in etwa dieselbe wie bei der E-Mail-Benachrichtigung. 40 javamagazin 5 2011
Archivierung der erstellten Artefakte Ein Blick auf das Erreichte zeigt uns, dass wir ein gutes Stück weiter gekommen sind und bereits viele der eingangs gesetzten Ziele erreicht haben. Jetzt müssen wir uns noch überlegen, was mit den Artefakten passiert, die unser Build produziert. Unter Artefakten werden Archive, z. B. JARs, WARs, EARs, verstanden, die als Ergebnis aus einem Build entstehen. Üblicherweise will man mit ihnen etwas anfangen. WARs bzw. EARs können auf Testserver deployt werden. Nur für ein Deployment müssen sie auch auffindbar sein. Jenkins bietet ein Archivierungssystem, das wir uns im Folgenden genauer ansehen wollen. Jenkins kann beliebige Dateien archivieren. Nicht nur das Build-Artefakt, sondern auch beliebige Berichte und Konfigurationsdateien können archiviert werden. Dazu können Sie die Syntax der Ant Filesets verwenden. Sie gehen dabei vom Verzeichnis des Arbeitsbereichs aus, also dem Basisverzeichnis ihres Checkouts. Die Konfiguration für die Archivierung der Artefakte finden Sie unter den Post-Build-Aktionen in der entsprechenden Jobkonfiguration. Später in diesem Artikel kommen wir auf die archivierten Artefakte noch einmal zurück. Jenkins ist in der Lage, die archivierten Artefakte pro Build zu speichern. Sie können also einen beliebigen Build des gewünschten Jobs auswählen und finden auf der Übersichtsseite die archivierten Artefakte. Sie sind damit nicht gezwungen, immer nur den aktuellsten Stand zu verwenden, sondern können bei Bedarf auf einen älteren Stand zurückgreifen. Ein Nachteil dieses Verfahrens ist die potenziell große Datenmenge. Stellt dies bei Ihnen ein Problem dar, gibt es die Möglichkeit, zu konfigurieren, dass nur die aktuellsten Artefakte aufbewahrt werden. Diese Option finden Sie ebenfalls in der Jobkonfiguration unter Artefakte archivieren Erweitert. Deployment Von einem Build erzeugte Artefakte sollen in der Regel weiterverwendet werden. Das bedeutet, dass diese Artefakte den entsprechenden Teams oder Werkzeugen zur Verfügung gestellt werden müssen. Jenkins bietet dafür kein entsprechendes Verfahren an. Über einen URL kann zwar auf eine archivierte Ressource zugegriffen werden, aber das ist nicht wirklich intuitiv. Besser ist es, hierfür ein Repository für Artefakte einzurichten. Natürlich könnte man dafür das Versionierungssystem verwenden. Diese Lösung ist aber eher suboptimal, da Artefakte typischerweise ein binäres Format haben (JARs, DLLs...) und gängige Versionierungssysteme damit nicht wirklich gut arbeiten können. Eine andere Möglichkeit ist es, ein File-Repository zu verwenden. Das sieht vor, dass die Artefakte in einer definierten Struktur abgelegt werden, in der man über einige wenige Angaben jedes Artefakt wiederfinden kann. Zusätzlich können die Artefakte versioniert werden. Maven bringt ein solches Konzept mit seinen M2-Repositories mit. Nichts liegt also näher, als ein Werkzeug zu verwenden, dass dieses Konzept unterstützt. Die beiden bekanntesten Vertreter sind Sonatype Nexus [4] und Artifactory von JFrog [5]. Für beide Repositories bietet Jenkins zwei Möglichkeiten an, um Artefakte zu deployen. Die erste Möglichkeit ist die Option Bringe Artefakte in Maven- Repository aus (deploy). Dafür benutzt Jenkins das Maven Deploy Plugin. Das bedeutet für Jobs, die nicht auf Maven basieren, dass diese Funktion nicht zur Verfügung steht. Sie benötigen hier nur den URL des Repositories, in das Sie deployen wollen. Zusätzlich brauchen Sie eine entsprechende Konfiguration in der Maven-Installation, die Jenkins verwendet. Ihr Ziel-Repository muss in der Maven settings.xml mit Benutzername und Passwort hinterlegt sein. Für das Artifactory-Repository gibt es als zusätzliche Möglichkeit ein eigenes Jenkins- Plug-in. Hierfür brauchen Sie nichts mehr in Maven zu tun, da die Konfiguration des Repositories komplett in Jenkins geschieht. Die zweite Möglichkeit für ein Deployment der Artefakte ist Maven selbst. Sie können in der Jobkonfiguration einfach in Build Goals das Goal deploy angeben. Den Rest erledigt Maven für Sie. (Auch hier gilt, dass Maven über eine entsprechend konfigurierte settings. xml verfügen muss.) Anzeige
Titelthema Continuous Integration Abb. 7: Slave-Konfiguration Unix/Linux per SSH Der Vorteil der ersten Methode ist, dass erst ein vollständig erfolgreicher Build inklusive der Post-Build- Aktionen das Deployment der Artefakte startet. Im Repository befinden sich dadurch nur Artefakte, die zusammenpassen. Das betrifft vor allem Multi-Modul- Projekte. Ein anderer positiver Nebeneffekt ist, dass es nur eine Instanz gibt, die das Repository befüllt. Und das ist die Instanz, die auch entscheidet, ob ein Stand des Sourcecodes formal valide ist oder nicht. Jenkins und die Sklaverei Wie Sie sehen, hat ein einzelner Job schon einiges zu tun. Wenn Sie viele Projekte haben, bekommt Jenkins Performanceprobleme. Diese Probleme sind nicht in Jenkins selbst begründet, sondern in der Tatsache, dass die Systemressourcen einfach nicht ausreichen. Wenn jeder Job nur 1 GB Speicher reserviert, was ja keine ungewöhnliche Angelegenheit ist, ist die Anzahl der parallel ausführbaren Jobs sehr begrenzt. Reduzieren Sie die Anzahl der zeitgleich laufenden Jobs, haben Sie immer eine lange Warteschlange. Beides ist nicht optimal. Jenkins bietet die Möglichkeit, bestimmte Funktionalitäten auf andere Server auszulagern. Zu diesen Funktionalitäten gehört auch der eigentliche Build inklusive Checkout aus dem Versionierungssystem. Post-Build-Aktionen werden immer auf dem Master- Knoten ausgeführt. Aus diesem Grund können Sie auch bei verteilten Builds mit Slaves sicher sein, wo Sie Ihre archivierten Artefakte finden, sie werden alle auf dem Master gespeichert. Der Master-Knoten ist der Server, auf dem Jenkins selbst installiert ist. Um dem Master die Arbeit zu erleichtern, möchten wir ihm gern einen Slave-Knoten konfigurieren. Dazu wählen wir in Jenkins verwalten die Option Knoten verwalten aus. Ein Klick auf Neuen Knoten eröffnet uns die Möglichkeit, einen Dumb Slave zu konfigurieren, dem wir zuerst einen Namen geben müssen (Abb. 5). Dabei sollten wir bereits wissen, um was für einen Slave es sich handelt. Wollen wir ihn auf einem Windows- Server betreiben, ist der Name wichtig, da Jenkins ihn als den Servernamen interpretiert, auf dem der Slave installiert und gestartet werden soll. Wir hinterlegen in der Konfiguration noch Namen und Passwort des administrativen Nutzers des Slaves und können damit die Einrichtung unseres Windows-Slaves abschließen (Abb. 6). Für den Fall, dass wir einen Slave auf einem Unix oder Linux betreiben wollen, können wir den Namen frei wählen, da wir in diesem Fall in der Konfiguration noch die Informationen der SSH-Verbindung explizit angeben müssen, die für die Kommunikation zwischen Master und Slave genutzt wird (Abb. 7). Diese beiden Wege sind die gebräuchlichsten Lösungen, um Slaves einzurichten und zu betreiben. Daneben gibt es noch einige andere Varianten, die ebenso wie die beschriebenen unter [6] erläutert sind. Für welche Variante man sich schließlich entscheidet, hängt von verschiedenen Faktoren ab. Befinden sich Master und Slaves z. B. in durch eine Firewall getrennten Bereichen oder benötigt man für GUI-Tests ein grafisches Frontend, muss man sich mit den alternativen Konfigurationen auseinandersetzen und kann nicht den einfachsten Weg gehen. Lassen Sie sich jedoch dadurch nicht von verteilten Builds abhalten. Auch die etwas aufwändigeren Verfahren sind in [6] gut beschrieben, sodass Sie auf dem einen oder anderen Weg sicher zum Ziel kommen. Wenn man sich für verteilte Builds entschieden hat, ist es wichtig zu wissen, wie Jenkins seine Arbeit verteilt und wie man darauf Einfluss nehmen kann. Grundsätzlich gelten für Jenkins drei Regeln: 1. Wenn ein Job an einen Knoten gebunden wurde, wird dies immer berücksichtigt 2. Jenkins versucht, Jobs immer auf dem Knoten auszuführen, auf dem auch der vorherige Build des Jobs stattfand 3. Jenkins versucht, lange Builds an Slaves zu delegieren, da dies in Bezug auf die nötige Netzwerkinteraktion positiv ist Wollen Sie eine bestimmte Verteilung sicherstellen, können Sie Jobs an einen festen Slave binden. Dabei ist es sinnvoll zu betrachten, wie umfangreich der zugehörige Build ist. Da der Umfang der notwendigen Kommunikation zwischen Master und Slave über das Netzwerk logarithmisch und nicht linear zur Länge des Builds ist, lohnt es sich, lang laufende Builds auf einen Slave auszulagern. Jobs mit kurzer Build-Dauer können auf dem Master verbleiben, da bei Ihnen die potenzielle Wartezeit in der Job-Queue auf dem Master eher unkritisch ist. Bei diesen kleineren Jobs stünde allerdings die Netzwerkauslastung in einem schlechten Verhältnis zum Umfang des Jobs, was gegen die Auslagerung auf einen Slave spricht. 42 javamagazin 5 2011
Continuous Integration Titelthema Ein sinnvolles, denkbares Verteilungsszenario ist es also, umfangreiche Jobs mit langen Build-Zeiten fest an eigene Slaves zu binden, während man den kleineren Jobs keine festen Knoten oder aber den Master als Knoten zuweist. Wenn man den großen Jobs exklusive Slaves gibt, kann man so verhindern, dass der Build eines anderen Jobs lange warten muss, um zum Zug zu kommen. Auf dem Master können zwar Wartezeiten entstehen, weil sich etliche Jobs in der Queue drängeln. Da sie aber alle überschaubare Durchführungszeiten haben, sollten diese Wartezeiten noch in einem vertretbaren Rahmen bleiben, solange die Anzahl der Jobs auf dem Master nicht ein gewisses Maß überschreitet. Eine feste Zahl lässt sich als Grenzwert hierfür nicht angeben, da dies sicher individuell von den zu bauenden Projekten abhängt. Wird die Warteschlange auf dem Master aus Sicht der Entwicklung jedoch zu lang, kann man reagieren, indem man die größeren Jobs an Slaves bindet, und so das Gedränge wieder reduzieren. Die Verteilung der Jobs auf die verschiedenen Knoten hat keinen Einfluss auf archivierte Build-Artefakte. Sie werden grundsätzlich auf dem Master abgelegt. Eine andere Möglichkeit ist die Vergabe von Labels für einen Slave. So ein Label beschreibt die Fähigkeit eines Slaves (z. B. Windows XP, UbuntuUISelenium,.NET). In der Jobkonfiguration können Sie dann angeben, dass Sie einen Slave mit bestimmten Fähigkeiten verwenden wollen. Jenkins ermittelt dann selbstständig, welcher Slave für den Job am besten geeignet ist. Fazit In dieser kurzen Einführung konnten wir Ihnen nur einen kleinen Einblick in die Möglichkeiten von Jenkins gewähren. Jenkins bietet Ihnen alle Möglichkeiten, die ein Continuous Build Server bieten sollte. Mit der großen Anzahl an Plug-ins haben Sie die Möglichkeit, aus Jenkins mehr herauszuholen als nur Software-Builds. Jenkins kann die zentrale Instanz sein, die über den Zustand Ihrer Projekte Bescheid weiß. Deployments auf Test- und Produktivsystemen können Sie ebenfalls über Jenkins administrieren. In diesem Sinne wünschen wir Ihnen viel Spaß mit Jenkins. Thorsten Kamann ist als Softwarearchitekt, Coach und Projektmanager bei itemis tätig. Seine Schwerpunkte sind neben Softwarearchitektur die Themen Qualität, Aufbau von Ent wick lungsinfrastrukturen, Anpassungen von Prozessen an agile Methoden und Scrum. Neben der Arbeit in Open-Source-Projekten veröffentlicht er regelmäßig Artikel in Fachmagazinen und seinem Blog. Weiterhin hält er Vorträge auf Fachkonferenzen. Hanno Wendt arbeitet bei der itemis AG als Softwareentwickler und Berater. Zusammen mit Thorsten Kamann kümmert er sich bei itemis um den Themenschwerpunkt Continuous Integration und hilft Kunden bei der Umsetzung ihrer individuellen CI-Strategie. Bob D. Veloper arbeitet als Teamleiter, Architekt und Technologieexperte bei einem mittelständischen IT-Unternehmen in Deutschland. Sein Fokus liegt auf der Optimierung von Ent wicklungsprozessen und agilen Methoden/Technologien. Links & Literatur [1] http://www.hudson-ci.org/ [2] http://www.jenkins-ci.org/ [3] http://wiki.jenkins-ci.org/display/jenkins/plugins [4] http://nexus.sonatype.org/ [5] http://www.jfrog.com/ [6] http://wiki.jenkins-ci.org/display/jenkins/distributed+builds Anzeige