Continuous Integration mit Hudson
Dr. Christian Betzhttps://www.xing.com/profle/Christian_Betz
http://twitter.com/vizMind
» https://hudson.dev.java.net/
2
Über mich
Studium und Promotion inInformatik an der Uni Würzburg
In Hamburg seit 2005
Geschäftsführer knowIT-Software GmbHSoftware-Architekt bei der Plath GmbH
3
Continous Integration integriert nicht nur Software-Komponenten
4Architektur
5Coding
6Qualitätssicherung
7Projektmanagement
8
Hudson„An extensible continuous integration engine“
9Hudson einrichten
10
Starten
» Per WebStart
» java -jar hudson.war
» WAR in WebContainerdeployen
Webbrowser öfnen(per defaulthttp://localhost:8080/)
11
Konfgurieren
» Browser-basiert:
» System-Konfguration (eMail-Server, Pfade, Environment-Variablen)
» Plugins
» Nodes
» Monitoring
» Skript-Konsole
» XML-basiert
» Während Hudson läuft
12
„Free Style Software-Projekt“
» Erlaubt die Kombination von „jedem“ Versions-Kontrollsystem (VCS) mit „jedem“ Buildverfahren
» SVN, CVS out-of-the-box
» Maven, ANT, Shell, Batch out-of-the-box, auch beliebige Kombinationen
» Build-Auslöser
» Abhängig von Projekten
» Zeitgesteuert
» Abhängig vom VCS
» Trigger über http-requests
13
Build-Ergebnisse
» Je nach Projekt baut man unterschiedliche Artefakte
» JARs, WARs
» Installer
» Source-Bundles
» Builds können folgendes Ergebnis haben
» Stable
» Instable (Build läuft durch, aber z.B. Coverage ist unter Schwellwert)
» Failed
» Hudson kann Artefakte selbst archivieren oder fngerprinten
14Hudson im Einsatz bei Plath
15
Ein Beispiel-Projekt
» Server-Applikation als WAR
» Deployment in einen JBoss-Cluster
» Eclipse RCP Rich Client
» zu starten per WebStart, verpackt in WAR
» Deployment in den JBoss-Cluster
» Eclipse Online-Hilfe
» WAR mit OSGi-Bundles der Eclipse Hilfe
» Deployment in den Jboss-Cluster
» Client + Integrationstest
» Ausführen auf Windows-Maschine
16
Continous Build
» Baut nach jedem Check-in
» Projekte werden über Maven gebaut (Multi-Module Projects)
» Eclipse Client wird über Eclipse PDE Build (ANT) integriert
» Build-Ergebnis
» Compilierter Code, wird außerhalb von Hudson nicht weiterverwendet
» Unit-Tests (JUnit)
» Reporting von ToDo, Code Coverage, Checkstyle, FindBugs, PMD
» Email bei Veränderung des Build-Ergebnisses
17
Nightly Build
» Baut jede Nacht
» Projekte werden über Maven gebaut, anderes Profl
» Eclipse Client wird diesmal signiert und in WebStart-Archiv „verpackt“
» Services, Client-WebStart und Online-Hilfe werden in ein ZIP-File gepackt
» Build-Ergebnis
» Deploybares Artefakt, wird in ein Nexus-Repository „deployt“
» Cleanup der Datenbank (wird neu mit Testdaten gefüllt)
» Deployment per Gant (aus Nexus-Repository) aufJBoss-Cluster, wenn Build vorher erfolgreich
18
Integration Test
» Baut im Anschluss an erfolgreichen Nightly Build
» Ist gebunden auf einen Windows-Slave
» Führt einen Rich Client + Integrationstest-Bundle aus
» Reporting über Junit
» Zusammenfassen der Testergebnisse von Nightly-Build und Integration Test
19Hudson erweitern
20
Plugins
» Hudson hat einen eigenen Plugin-Mechanismus eingebaut (inkl. Updates)
» VCS
» ClearCase, GIT, Mercurial, Perforce
» Build
» Gant, Gradle, Grails, NAnt (.NET), Phing (PHP),rake (Ruby)
21
Interessante Plugins
» ActiveDirectory
» LDAP Email Plugin
» IssueTracking-Plugins
» Bugzilla
» JIRA
» Trac
» Metriken
» Checkstyle
» Findbugs
» Promoted Build Plugin
» Continous Integration Game
» Messaging
» IRC
» Jabber
» Deployment
» SCP
» FTP
» Deploy (via Cargo)
22
Ofene Issues
» Erlaubt Commit von fehlerhaftem Code (anders als z.B. Teamcity)
» Synchronisation der Build-Prozesse in der IDE und auf dem Build-Server
» Vordefnierte Projekttypen noch nicht ausgereift
» Fehlende Plugins für Spezialfälle
» bazaar
23
Continuous Integration als Schlüssel zum Projekterfolg?
24
Für Hudson spricht einiges...
» Open Source
» Einfach aufzusetzen
» Leicht zu erweitern (Plugins)
» Einfach zu bedienen
» Sehr stabil
» Verteiltes Bauen möglich
» Permanente URLs (z.B. auf latest-build)
» Auch zum Monitoring externer Jobs geeignet (z.B. Cleanup der Testumgebung)
» File fngerprinting
» Trend reports
25
… und noch mehr fürContinuous Integration» Kürzere Release-Zyklen
» Fehler werden schneller entdeckt
» Metriken können zentral gemessen werden
» Automatische Changelogs
» Transparenz für alle
26