Kontinuierliche Integration am Beispiel Jenkins Sujeevan Vijayakumaran Ubucon, Berlin 20. Oktober 2012 1 / 25
Inhaltsverzeichnis 1 Über mich 2 Was heißt kontinuierliche Integration? 3 Test-Schnittstellen 4 Jenkins 2 / 25
Über mich Sujeevan svij Vijayakumaran Jahrgang 1992 wohnhaft Castrop-Rauxel Studium am IT-Center Dortmund (FH Dortmund) C++-Entwickler bei otris Software AG (Dortmund) Aktivität in FLOSS-Projekten: seit 09/2010: Ikhayateam ubuntuusers.de (Teamleiter) seit 09/2012: Redaktionsmitglied bei freiesmagazin 3 / 25
Was heißt kontinuierliche Integration? Zwei Grundsätze: 1 Integration 2 Kontinuierlich 4 / 25
Integration Einfügen des geänderten Quellcodes in das Ursprungsprojekt Einsatz von Versionsverwaltungssystemen wie Git, SVN, Mercurial etc. 5 / 25
Kontinuierlich Integration des neuen bzw. veränderten Quellcodes erfolgt in kurzen Abständen meist täglich Führt zum schnellen Erkennen von Fehlern im Quellcode Häufig wird dabei an Hand von Nightly Builds die kontinuierliche Integration getestet 6 / 25
Test-Schnittstellen 1 Unit-Tests 2 Integrations-Tests 3 System-Integration 7 / 25
Test-Schnittstellen Test-Schnittstellen für ein Apache-Module: Funktionsweise der Methoden z.b. in C++ HTTP-Schnittstelle z.b. mit Perl oder Python Skripte die HTTP-Requests abschicken 8 / 25
Beispiel: Testen am XML-Parser Einlesen eines RSS-Feeds (Eingabeobjekt): XML-Datei valide? XML-Datei wohlgeformt? Schreiben des RSS-Feeds (Ausgabeobjekt): Richtiger Pfad? Erwartungsgemäß geschrieben? 9 / 25
Jenkins Maintainer: Kohsuke Kawaguchi Entwickelt bei Sun unter dem Namen Hudson Nach Übernahme durch Oracle entstand der Fork Jenkins Programmiersprache: Java Plattformunabhängig unter MIT-Lizenz 10 / 25
Workflow in Jenkins 1 Auslösung 2 Ausschecken 3 Build-Vorgang 4 Post-Buildvorgang 11 / 25
Workflow in Jenkins Der Auslöser: Zeitgesteuert: bspw. jeder Tag um 18 Uhr. Eventgesteuert: Löse aus, wenn Vorgänger-Projekt erfolgreich. Änderung im Source-Code Manuell 12 / 25
Ausschecken des Quellcodes Das Repository (Git, SVN,... ) wird ausgescheckt. Auch checkout genannt. Der Quellcode wird dabei heruntergeladen. 13 / 25
Buildvorgang Das Projekt wird kompiliert. Die Tests werden ausgeführt. Sofern währenddessen ein Fehler auftritt, wird der Buildvorgang abgebrochen und geht in den nächsten Schritt über. 14 / 25
Post-Buildvorgang Bezeichnet alle Aktionen die nach einem Buildvorgang ausgeführt werden: Wenn erfolgreich: Bauen eines Paketes (deb, rpm,... ) Prüfen der Testergebnisse Setzen des Buildstatusses (Erfolgreich, Instabil, Fehlgeschlagen) Code-Analyse Versenden einer Benachrichtigung an die Entwickler (E-Mail, Jabber, IRC-Bot,... ) Trigger für mögliche Nachfolgende Jenkins-Jobs 15 / 25
Jenkins Was kann es noch? Build-Parametrisierung: Verschiedene CPU-Architekturen innerhalb eines Jenkins-Jobs Ausreizen der Möglichkeiten durch den Einsatz von Shell-Skripten Zahlreiche Anzahl an verfügbaren Plugins. 16 / 25
Ein Beispiel... Ein fiktives Projekt hat diverse Ansprüche: Durch Kontinuierliche Integration bzw testgetriebener Entwicklung soll eine gute Stabilität garantiert sein. Es soll sowohl unter Windows als auch unter den gängigen Linux-Distributionen funktionieren Möglichst jeden Sonntag soll es ein stabiles Release geben Die Dokumentation soll stets öffentlich zugänglich sein und auch aktuell gehalten sein, sie soll sowohl in HTML als auch als PDF verfügbar sein. Zudem wird ein Bugtracker gebraucht, in dem Nutzer Tickets erstellen können. 17 / 25
Das fiktive Beispiel Kontinuierliche Integration Als Versionsverwaltungssystem wird Git genutzt. Als Bugtracker wird Redmine genutzt. 18 / 25
Das fiktive Beispiel Bugtracking und Workflow Benutzer erstellt ein Bug-Report zu einem kleinen Fehler Programmierer korrigiert den Fehler zunächst und macht einen Commit in das Repository Danach wird ein Testfall zu dem Fehler geschrieben In der Commit-Nachricht wird auf das entsprechende Ticket verwiesen: Fixed Bug + Unit-Test. refs #1337 Im Ticket unter Redmine wird direkt auf das entsprechende Commit verlinkt. 19 / 25
Das fiktive Beispiel Plattformunabhängigkeit Für die kontinuierliche Integration wird Jenkins genutzt. Es werden hierfür zwei Jenkins-Jobs angelegt. Einmal für Windows und einmal für Linux Windows: Enthält vier Knoten: Windows Server 2012 mit Visual Studio 2012 und Windows Server 2008 R2 mit Visual Studio 2010, beide jeweils für 32-Bit und 64-Bit. Linux: 8 Knoten: SLES, RHEL, Debian, Ubuntu. Ebenfalls jeweils 32-Bit und 64-Bit. Echte benötigte Server: 2x Windows, 1x Jenkins-Host, 1x Jenkins-Slave Jenkins-Slave beinhaltet acht VMs mit den oben genannten Distributionen. 20 / 25
Das fiktive Beispiel Jenkins Build-Start: Täglich 19 Uhr Windows-Jenkins-Jobs laufen parallel an. Linux-VMs werden nacheinander per SSH hochgefahren und nach einem Lauf wieder heruntergefahren 21 / 25
Das fiktive Beispiel Wöchentliches Release Bei erfolgreichen Jenkins-Lauf werden installierbare Pakete geschnürt. Sofern der Sonntags-Lauf erfolgreich war, können die Pakete an das QS-Team übergeben werden. 22 / 25
Das fiktive Beispiel Dokumentation Bei erfolgreichen Jenkins-Lauf wird eine weitere Jenkins-Jobs ausgeführt Erzeugt HTML-Dokumentation und daraus auch eine PDF-Variante Erzeugnisse wird automatisch auf doc.project.name veröffentlicht Newsletter-Abonnenten werden über neue Version und Dokumentation informiert 23 / 25
Das fiktive Beispiel Danach fängt es alles wieder von vorne an. Und das meiste davon völlig automatisch! 24 / 25
Vielen Dank für die Aufmerksamkeit! Die Folien und Inhalte unterliegen (wenn nicht anders angegegen) der CreativeCommons Namensnennung-Weitergabe unter gleichen Bedingungen 3.0 Unported. Copyright 2012 Sujeevan Vijayakumaran 25 / 25