continuous integration in der praxis · administrator n pom kann gross ... n absolutes muss: maven:...
TRANSCRIPT
16.11.2009 … 1
Continuous Integration in der Praxisn Das Institut für Geistiges Eigentum (IGE)n Vom alten zum neuen Buildn Continuous Integration: Übersichtn Mavenn Nexusn Eclipse / m2eclipsen Hudsonn Metrikenn Fragen
…16.11.2009 2
Disclaimer
n Nicht nur Qualitätssicherung, Testenn Software-Qualität allgemein
n Der Build unterstützt die Entwicklern Alles, was automatisch gemacht werden kann,
wird automatisch gemacht.
…16.11.2009 3
Das Institut für Geistiges Eigentum (IGE)
n Kompetenzzentrum des Bundes für Geistiges Eigentum
n Markenn Patenten Designsn Urheberrecht
…16.11.2009 4
Das Institut für Geistiges Eigentum (IGE)
n Software-Entwicklung mit Java 6n 20 Entwicklern Ablösung des Kernsystems durch ESVn Architekturboard: Chef SW-Entwicklung, 4
Entwicklern Je 2 Entwickler für alten und neuen Build
…16.11.2009 5
Der alte Build
n Basierend auf Apache Antn Auf spezifische Bedürfnisse zugeschnittenn Library-Verwaltung in einem Verzeichnisn Build-Reihenfolge über Properties-Datein Für Nightly Build konzipiert
…16.11.2009 6
Der alte Build: Vorteile
n Man hat einen vollständigen Nightly Build!Das haben nicht alle Software-Firmen...
n Flexibel an Bedürfnisse anpassbarn Ant ist sehr stabiln Kleine Hürde für den Einstieg
…16.11.2009 7
Der alte Build: Nachteile
n Jeder Build ist spezifisch für jeweilige Firman Verständnis des Builds relativ schwierig
n Missbrauch als „Programmiersprache“n Für Prüfung der Abhängigkeiten immer
vollständiger Build notwendign Metriken wurden erzeugt, aber kein Build-
Abbruch
…16.11.2009 8
Der alte Build: Nachteile
n Library: JAR Helln Was für JARs in welchen Versionen gibt es?n Welches Projekt benötigt welche JARs?n Woher sind sie heruntergeladen worden?n Was ist ihre Lizenz?n Haben wir die Kontrolle, wer was herunterlädt?
…16.11.2009 9
Der neue Build: Ziele
n Mehr Kontrolle über Abhängigkeitenn Schnellere Reaktionszeiten bei Problemenn Automatische Überprüfung von Guidelinesn Verbesserung der SW-Qualität durch Metrikenn Möglichst auf Standard-Produkte und Open
Source bauenn Vorhandenes Know-How nutzen
n Schnittstelle zu Betrieb vereinfachen
…16.11.2009 10
Der neue Build:Continuous Integration
n Automatisierter Build und Test bei jedem Commitn Zeitnahes Feedback für den Entwickler (Mail,
RSS)n Entwicklung immer gegen aktuellste stabile
Version der anderen Komponentenn Build-Resultat wird sofort anderen zur Verfügung
gestellt
…16.11.2009 11
Übersicht
Einführung
Entwickler Aentwickelt ipiprj1
Entwickler Bentwickelt ipiprj2
ipiprj2 hängt von ipiprj1 ab.
…16.11.2009 12
Übersicht
Eclipse,m2eclipse
Entwickler A
Lokaler Build
Lokales Maven Repository
xy.jar
mvn installipiprj1
xy.jar ?
ipiprj1SNAP
SHOT.jar
CVS Hudson Zentrales Maven Repository
Projekt Websites
…16.11.2009 13
Übersicht
…16.11.2009 14
Übersicht
…16.11.2009 15
Übersicht
Eclipse,m2eclipse
Entwickler A
Nightly Build
xy.jar
xy.jar ?
ipiprj1SNAP
SHOT.jar
cvs checkout ipiprj1
Stabil?Ja
CVS Hudson Zentrales Maven Repository
Projekt Websites
cvs checkout ipiprj2
ipiprj2SNAP
SHOT.jarZZZZZ Stabil?
Ja
ipiprj2ipiprj1
sitedeploy
Lokales Maven Repository
Entwickler B
…16.11.2009 16
Maven
n Build-Framework von Apachen In unzähligen Projekten eingesetzt
n Apache-Projekten JBossn Glassfishn AppFusen Geronimon ...
…16.11.2009 17
Maven: Build
n Ein Projekt definiert nicht seinenBuild, sondern seine Konfiguration
n POM = Project Object Modeln Fixer Build-Ablauf mit so
genannten Goals (analog zuAnts Tasks)
n Das Goal ruft alle vorhergehendenGoals auf
…16.11.2009 18
Maven: Build
n Maven definiert Plugin-Architektur
n Plugins hängen sichin Goal ein
n Plugins sind wieder-verwendbar
n Durch eigene Pluginserweiterbar
n Aber quasi für alles gibt es schon ein Plugin
…16.11.2009 19
Maven: POM
n POMs werden vererbtn ipi-parent
Definiert für alle Projekte die eingesetzten Maven-Plugins und die generelle Build-Konfiguration
n esv-parent erbt von ipi-parentDefiniert die Abhängigkeiten für das Projekt ESV
n esv-ipi-versions erbt von esv-parentDefiniert die Versionen der Komponenten des Projekts ESV
…16.11.2009 20
Maven: Abhängigkeiten
n Beschreibung, von welchen anderen Projekten und Bibliotheken dieses Projekt abhängt
n Jedes Build-Artefakt (JAR, WAR, ...) weltweit eindeutig identifizierbargroupId, artifactId, version
n Transitive Abhängigkeiten unterstütztProjekt A braucht B, aber B braucht C
n Scopes: compile, runtime, test, provided
…16.11.2009 21
Maven: Abhängigkeiten
n Zentrale Kontrolle über Abhängigkeitenn Projekt darf nur vorgegebene Abhängigkeiten benutzenn Dies wird automatisch überprüft
n Maven Enforcer Pluginn Welche Abhängigkeiten (von allen zugelassenen) darf ein
Projekt haben?n Z.B. Abhängigkeit auf API, nicht auf Implementationn Z.B. Abhängigkeit nur innerhalb des gleichen Projekts
(Basisklassen, Utilities etc.)n Vorsicht: Build-Zyklen!
…16.11.2009 22
Maven: Version
n Versionierungskonzept in Mavenn <major>.<minor>.<bug fix>-<qualifier>n Vergleich als Text, nicht als Zahlen, daher
teilweise schlechte Vergleichen Versionskollisionen löst Maven automatischn Versionierte Abhängigkeit ändert sich nie mehrn Für die aktive Entwicklung gibt es SNAPSHOTs
n Wird immer auf neuere Datei-Version überprüft
…16.11.2009 23
Maven: Projekt-Layout
n Verzeichnis- und Dateistruktureines Projekts standardisiert
n Abhängig vom Projekt-Typn (JAR, EAR, WAR, JSF, GWT, ...)
n Generierung möglichn Klare Trennung von Quell-Dateien und
generierten Dateienn Generierte Dateien werden mit clean gelöschtn Generierte Dateien werden nie eingecheckt
…16.11.2009 24
Maven: Projekt
n Aufteilung in Module möglich:1 Projekt = n Module
n Architektonische Aufteilungn xyz-apin xyz-impln xyz-clientn xyz-batchn etc.
n Automatisch richtige Build-Reihenfolge bei Abhängigkeiten
…16.11.2009 25
Maven: Projekt-Layout
n Vorteilen Schnelle Einarbeitungn Gleiche Packages in Klassen und Testklassen
n Weniger Methoden publicn Nachteile
n Man sollte nicht davon abweichenn Gut für neue Projekte, schlecht für bestehende
…16.11.2009 26
Maven
n Schnittstelle zumBetrieb
n EARn WARn ZIP
n Immer ab Root-Verzeichnis (C:\ oder /)n Quasi alles möglich mit Maven Assembly Plugin
n Allerdings relativ komplex
…16.11.2009 27
Maven-Site: About
…16.11.2009 28
Maven-Site: Summary
…16.11.2009 29
Maven-Site: Team
…16.11.2009 30
Maven-Site: SCM
…16.11.2009 31
Maven-Site: CI
…16.11.2009 32
Maven-Site: Bugs
…16.11.2009 33
Maven-Site: Changes
…16.11.2009 34
Maven-Site: Dependencies
…16.11.2009 35
Maven-Site: Analyse
…16.11.2009 36
Maven-Site: Plugins
…16.11.2009 37
Maven-“Site“: Updates?
…16.11.2009 38
Maven-Site: Javadoc
…16.11.2009 39
Maven-Site: Source
…16.11.2009 40
Maven-Site: Tag List
…16.11.2009 41
Maven-Site: Dokumentation
n Weitere Dokumentation kann generiert werdenn XDoc (ähnlich XHTML)n APT (ähnlich Wiki)n FML (XML für FAQs)n DocBook (XML, kann auch PDFs generieren)
…16.11.2009 42
Maven: Vorteile
n Der De-facto-Standardn Viel Know-How vorhandenn (Inzwischen) gute Grunddokumentation auffindbar
n „Gemeinsame Sprache“, d.h. auch fremde Builds sind schneller verständlich
n Konvention statt Konfigurationn Konfiguration trotzdem nicht zu unterschätzen
n Beschreibt Projekt, nicht den Build-Ablaufn Daher Unterscheidung Anwender / Autor möglich
…16.11.2009 43
Maven: Vorteile
n Es gibt quasi für alles ein Pluginn Wenn nicht, schreibt man eines
n Es können sehr reichhaltige Informationen generiert werden
n Testen im Ablauf eingebautn Build schlägt fehl wenn Tests fehlschlagenn Unterscheidung Unit Test / Integrationstest
…16.11.2009 44
Maven: Nachteile
n The people who love Maven love the theory. The people who hate Maven hate the reality. (Zutubi)
n Schwieriges Debuggingn Spezialisten-Knowhow ist notwendig
n Am Markt verfügbarn Kommerzieller Support durch Sonatypen Unterschied zwischen Entwickler und Build-
Administratorn POM kann gross werden (geschwätziges XML)
…16.11.2009 45
Maven: Nachteile
n Teilweise schlechte bis nur spärliche Dokumentation
n Absolutes Muss: Maven: The Definitive Guiden Weiteres Muss: Archiv der Mailing-Liste
n Plugins: Teilweise Bugs und schlechter Supportn Alpha-Versionen über Monaten Bekannte Bugs: „Fix it yourself“n Support auf der Mailing-Liste von null bis sehr gut
n Plugin-Versionen festlegen, sonst unvorhersehbarer Build
…16.11.2009 46
Nexus
n Ein Proxy für Maven Repositories im Internetn Gruppierung von Repositories
n Von den Maven-Kernentwicklern (Sonatype) geschrieben
n Open Source und kommerziell (Nexus Pro)n Andere Produkte
n Artifactoryn Apache Archiva
…16.11.2009 47
Nexus: Vorteile
n Schnellere Ladezeiten von Abhängigkeitenn Totale Kontrolle über Abhängigkeiten, bis hin zur
Versionn Verwaltung von Abhängigkeiten mit restriktiver
Lizenzn Z.B. Oracle JDBC-Treiber
n Auch als Eclipse Repository verwendbar
…16.11.2009 48
Nexus: Vorteile
n Schnelle Suche von Abhängigkeitenn Web-GUI
…16.11.2009 49
Nexus: Vorteile
n Schnelle Suche vonAbhängigkeiten
n m2eclipse überNexus-Index
…16.11.2009 50
Nexus: Nachteile
n Eine weitere Software zum Verwalten und Verstehen
n Single Point of Failuren Totale Kontrolle bedingt eine Kontrollstelle
n Kann unter Umständen SW-Entwicklung behindern
…16.11.2009 51
m2eclipse
n Integration von Maven in Eclipsen Bequeme Suche nach Abhängigkeiten
n Auch Source Code und Javadocn Eigene Projektabhängigkeiten werden
intelligent verwaltetn Projekt geschlossen? à JARn Projekt offen? à Projekt
n Source Code lesbarn Debugging möglich
…16.11.2009 52
m2eclipse
…16.11.2009 53
m2eclipse: Vorteile
n Verheiraten zweier unterschiedlicher Welten:Es funktioniert!
n Gute Integration in Eclipsen Theoretisch Unterstützung von speziellen
Eclipse-Projektarten (WTP)n Web-Projektn EAR-Projekt
n Sonatype will in 1.0 den inkrementellen Build von Eclipse vollständig unterstützen
…16.11.2009 54
m2eclipse: Nachteile
n Teilweise langsamn Besonders Öffnen und Schliessen von Projekten
n Work in progress (0.9.7)n Unterschiedliche Builds
n Maven: Voller Buildn Eclipse: Inkrementeller Build
n Manchmal ist Handarbeit nötig, um Eclipse aufzufrischen
…16.11.2009 55
Hudson
n Der Build-Butlern „Shooting Star“ unter den Build/CI-Servernn Plugin-Architektur, es gibt ca. 200 verfügbaren Verteilte Builds auf x Servern
n Verteilte Lastn Andere Betriebssysteme
n Kommerzieller Support durch Sun
…16.11.2009 56
Hudson
n Benutzt durchn Glassfishn JBossn Sonatype (Maven)n NetBeansn SwingLabsn Apache Lucenen ...
…16.11.2009 57
Hudson
n Flexibler Einsatz von Build-Frameworksn Ant, NAntn Mavenn Grailsn Pythonn Rubyn Gantn Buckminstern Gradlen MSBuildn ...
…16.11.2009 58
Hudson
n Stösst automatisch Builds von Projekten an, die das erzeugte Projekt als Abhängigkeit haben
n Wird bei Maven-Projekten automatisch erkanntn Läuft zwar länger, dafür 100% stabiler Zustand
n Im IGEn CI-Server mit schnellem Build
n Rasches Feedback per Mail an „Schuldige“n „Schuldige“ per Source Code Management ermittelt
n Vollständiger Nightly Build mit Erzeugen der Maven-Siten Integrationstest nach Deploy des EARs
…16.11.2009 59
Hudson
…16.11.2009 60
Hudson
…16.11.2009 61
Hudson: Vorteile
n Extrem einfach zu installierenn Vieles läuft einfach ohne Arbeitn Gute Communityn Macht Spass: Schönes GUI (AJAX), tolle
Funktionalität – und alles gratis!n Schnelle Release-Zyklenn Build-Information: Mail, RSS,
Firefox-Plugin, Eclipse-Plugin,iPhone, Spezial-Displays, ...
…16.11.2009 62
Hudson: Vorteile
n Historische Diagramme mitausgewählten Daten
n Metrikenn Compiler-Warnungenn Tests (erfolgreich, ignoriert, fehlerhaft)
n Permanente Linksn Z.B. letzter erfolgreicher Build
von Projekt xyzn Ideal für Dokumentation
z.B. über ein Wiki
…16.11.2009 63
Hudson: Nachteile
n Releases haben oft Regressionsfehlern Konfiguration nicht vererbt: x-fach kopiert und
angepasstn Wir generieren sie teilweise mit Shell-Scripts
n Gehostet auf dev.java.net: Extrem langsamn Upstream/Downstream Builds mit Maven z.T.
fehlerhaftn Fehlerhafte Tests ergeben nur Warnung, keinen
gebrochenen Build
…16.11.2009 64
Metriken: JDepend
…16.11.2009 65
Metriken: JavaNCSS
n Momentanausser Betrieb
n Kommt mit gewissenGenerics nicht zurecht!
…16.11.2009 66
Metriken: FindBugs
n Untersucht Bytecode nach bekannten Bug-Patterns
n Jedes Pattern hat eine IDZ.B. ES_COMPARING_PARAMETER_STRING_WITH_EQ
…16.11.2009 67
Metriken: Checkstyle
n Umsetzung von Java-Guidelines, z.B. Sun Code Conventions
n Teilweise auch Bug Patternsn Javadoc-Überprüfung
…16.11.2009 68
Metriken: PMD
n Sucht potenzielle Probleme im Source Coden Bugsn Toter Coden Kopierter Coden Suboptimaler Code
…16.11.2009 69
„Metriken“: Compiler Warnings
n In Maven konfigurierbar (-Xlint)
…16.11.2009 70
Metriken: Cobertura (Testabdeckung)
…16.11.2009 71
Metriken: Cobertura (Testabdeckung)
…16.11.2009 72
Metriken: Vorteile
n Laufen automatisch ab, im Gegensatz zu Code Reviewsn Grafische historische Übersicht motiviert (hoffentlich):
„Ist mein Projekt jetzt besser?“n Sind auf individuelle Bedürfnisse anpassbar
n Konfigurationn Eigene Regeln schreiben
n Wenn Regeln festgelegt worden sind, kann der Build entsprechend abbrechen
n SW-Qualität „erzwingen“?
…16.11.2009 73
Metriken: Nachteile
n Mecker, mecker, mecker...n Build Game einführen?
n Teilweise Bugs (False Positives), daher müssen Schwellwerte erhöht werden
n In Hudson: Anzahl Fehler nur absolut konfigurierbar, nicht relativ zur Projektgrösse
n Compiler-Konfiguration in Eclipse: Toll, aber nicht wiederverwendbar
n Nicht einmal für den Eclipse Headless Build!n Teile davon können in Checkstyle und PMD emuliert
werden
…16.11.2009 74
Fazit
n Continuous Integration lohnt sich auf jeden Falln Verringert Reaktionszeit bei Fehlernn Wiederkehrende Arbeit automatisieren
n Metriken zwingen zu Disziplinn Gesundes Mass an Vorschriften findenn Es werden nie alle mit allem einverstanden sein
n Der Build ist nicht ein Nebengeräusch der Entwicklungn Er ist zentral und braucht Betreuungn Out-of-the-box-Lösung gibt es nicht, Anpassungen immer
nötign Alles zusammen kann relativ komplex werden
…16.11.2009 75
Fragen
n Zuerst eine an Sie:Was passiert bei Ihnen, wenn jemand den Build bricht?
n Ihre Fragen?
16.11.2009 … 76
Links
n Institut für Geistiges Eigentumn Mavenn Nexusn Hudsonn FindBugs, Checkstyle, PMD, Cobertura