Besser, öfter, mehr

Continuous Integration mit Git, Gerrit und Jenkins

Stephan Wagner und Marcus Handte

Eclipse Magazin

Der Artikel „Besser, öfter, mehr“ von Stephan Wagner und Marcus Handte ist erstmalig erschienen im

Eclipse Magazin 5.2012

Vor dem Kopieren des war-Archivs in das webapp-Verzeichnis des Tomcat-Servers müssen noch die Rechte des Gerrit-eigenen Verzeichnisses so gesetzt werden, dass der Tomcat ausführende Benutzer dort sowohl lesen als auch schreiben kann. Durch die Verbindung zu der im vorangegangenen Schritt bereits initialisierten Datenbank kennt Gerrit das Verzeichnis und kann dort seine Konfigurationsdatei laden.

Um einen externen Zugriff auf beide Anwendungen zu ermöglichen, können in einem Apache-Webserver entsprechende Weiterleitungen auf die beiden Anwendungen eingestellt werden. Darin kann die Authentifizierung der Nutzer konfiguriert werden (Listing 2). Durch diese Konfiguration werden die Anmeldedaten, die zuvor an den Apache-Webserver gesandt wurden, auch an den Tomcat-Server und somit an Jenkins und Gerrit weitergeleitet. Damit Gerrit auch in der Lage ist, diese Daten zu nutzen, muss die Konfigurationsdatei $gerrit_home/etc/gerrit.config um die entsprechenden Einträge erweitert werden:

Listing 2


        AuthName "Gerrit Auth"
        Require ldap-group cn=mygroup,ou=role,ou=groups,o=myorg,c=de
  SSLRequireSSL
        ProxyPass http://localhost:8080/gerrit
        ProxyPassReverse http://localhost:8080/gerrit

  # Deaktiviert die HTTP-Authentifizierung, da diese für die git Kommunikation direkt von Gerrit durchgeführt wird
        Satisfy Any
        Allow from all
        ProxyPass http://localhost:8080/gerrit/p/
        ProxyPassReverse http://localhost:8080/gerrit/p/

        AuthName "Jenkins Auth"
        Require ldap-group cn=mygroup,ou=role,ou=groups,o=myorg,c=de
        SSLRequireSSL
        ProxyPass http://localhost:8080/jenkins
        ProxyPassReverse http://localhost:8080/jenkins
[auth]
        type = HTTP_LDAP
[ldap]
        server = ldap://localhost
        accountBase = ou=people,o=myorg,c=de
        groupBase = ou=groups,o=myorg,c=de

Nun kann die Anmeldung an Gerrit zum ersten Mal erfolgen. Dabei wird automatisch der erste (und nur der erste) Benutzer als Administrator in der Datenbank abgespeichert. Sollen noch weitere Nutzer administrative Rechte erhalten, so können sie unter ADMIN | GROUPS der Gruppe Administrators hinzugefügt werden. Auch ist das Anlegen weiterer Gruppen, die für eine feingranulare Rechtevergabe benötigt werden, auf dieser Seite möglich. Zur Konfiguration der nutzerabhängigen Einstellungen gelangt man über den Punkt SETTINGS in der oberen rechten Ecke des Webinterface. Hier befindet sich auch das durch Gerrit gesetzte HTTP-Passwort, das für den Zugriff auf die Git Repositories benötigt wird. Zusätzlich zu der Installation der Software wird ein dedizierter Nutzer benötigt, mit dem sich der Jenkins-Server bei Gerrit anmelden kann, um auf das Repository zuzugreifen. Dieser Nutzer wird im Folgenden build genannt. Er ist unter Gerrit einer neuen gleichnamigen Gruppe hinzuzufügen. Um über diesen die Verbindung zu Gerrit zu erstellen, muss ein SSH-Schlüsselpaar generiert und installiert werden. Eine Anleitung dazu befindet sich unter [6].

Erstellen eines Git Repositories

Als erster Schritt muss zunächst ein neues Git Repository angelegt werden. Seit der Gerrit-Version 2.3 ist das im Webinterface unter ADMIN | PROJECTS | CREATE NEW PROJECT möglich. Ein neues Projekt sollte die grundlegenden Berechtigungen von dem Projekt All-Projects erben, das bereits die wichtigsten Rechte definiert. Durch den Haken bei Create initial empty commit wird beim Anlegen ein initialisierender Commit durchgeführt, der es später erleichtert, das Repository zu klonen. Nach Abschluss dieses Schritts steht das Git Repository unter dem URL $gerrit_url/p/

psenv::pushli(); eval($_oclass[„project_name“]); psenv::popli(); ?>

zur Verfügung. Nach dem Erzeugen des Projekts wird die Übersicht über die Projekteigenschaften angezeigt, die das Anlegen weiterer Zweige sowie die Konfiguration von nutzerspezifischen Rechten ermöglicht.

Anlegen einer Arbeitskopie

Anschließend ist es möglich, eine lokale Kopie des Projekts mittels git clone zu erzeugen. Zur Nutzung von Gerrit müssen hierbei zusätzliche Einstellungen vorgenommen werden. Insbesondere muss das Push-Verhalten des lokalen Repositories verändert werden, um nicht wie üblich von HEAD (dem momentan aktiven Branch) nach refs/master (dem entfernten master Branch) zu pushen, sondern nach refs/for/master. Durch diese Umstellung wird Gerrit beim Hochladen von Änderungen automatisch aktiviert. Weiterhin werden Änderungen nicht direkt in den Hauptzweig der Entwicklung übernommen, sondern zunächst als Change Request für den abschließenden Integrationstest und das Code Review angenommen. Um diese Schritte zu automatisieren, kann das Git Repository auch alternativ über das eGit-Eclipse-Plug-in von Gerrit heruntergeladen werden. Nach der Installation des eGit-Plug-ins in Eclipse [7] steht die Perspektive Git Repository Exploring zur Verfügung, die eine Schaltfläche für das Klonen eines Repositories anbietet. Diese öffnet einen Dialog, der alle für den Vorgang benötigten Daten abfragt. Auf der letzten Seite des Dialogs muss ein Haken bei Configure Push to Gerrit Code Review gesetzt und der URI durch den bereits zum Klonen verwendeten ersetzt werden. Nach Abschluss des Vorgangs wird ein Git Push automatisch an refs/for/master und damit an Gerrit weitergeleitet.

Einrichten eines Beispielprojekts

Da nun das Repository fertig konfiguriert ist, kann mit der Arbeit begonnen werden. Hierfür müssen sowohl der Quellcode für die zu entwickelnde Software als auch der Code für die Tests und etwaige Skripte zur Erstellung und zur Testausführung in das Git Repository kopiert werden. Um diese Schritte einfach zu halten, nutzen wir im Folgenden Apache Maven. Grundsätzlich können jedoch beliebige Konfigurationsverwaltungssysteme verwendet werden. Zur weiteren Illustration legen wir ein neues Maven-Projekt mit dem Archetype maven-archetype-quickstart an. Dabei werden neben der Maven-typischen .pom-Projektkonfigurationsdatei auch Java-Beispielklassen für eine Anwendung und einen simplen Test generiert. Dieses Projekt ist sofort nutzbar und kann mittels maven install kompiliert und lokal getestet werden.

Einrichten automatisierter Integrationstest

Bevor dieser Code jedoch als Änderung an Gerrit übertragen werden soll, muss auf dem Jenkins-Server noch ein Job erstellt werden, der das Projekt bei jedem übertragenen Commit neu übersetzt und testet. Dazu meldet sich ein Nutzer mit administrativen Rechten an Jenkins an und erstellt einen neuen Job über die Schaltfläche NEUEN JOB ANLEGEN. Dieser benötigt einen aussagekräftigen Namen und soll in unserem Beispiel ein Maven-Projekt ausführen, weshalb die Option Maven 2/3 Projekt bauen gewählt wird. Anschließend wird die Hauptkonfigurationsseite des neuen Jobs angezeigt. Sie bietet eine Fülle von Optionen betreffend der einzelnen Plug-ins. Um die Unterstützung für das neue Projekt umzusetzen, müssen hier jedoch lediglich die Unterstützung für Git und Gerrit sowie das Übersetzen und Testen mittels Maven konfiguriert werden.

Zuerst muss die Verbindung zum Git Repository hergestellt werden. Dazu wird der von Gerrit bereitgestellte SSH-Zugang verwendet, wozu die SSH-Schlüssel des Nutzers build benötigt werden. Liegen diese im Home-Verzeichnis des Nutzers, der Tomcat ausführt, werden sie automatisch genutzt. Weiter muss der Build-Auslöser – die Bedingung, unter der der Übersetzungs- und Testvorgang startet -konfiguriert werden. Durch das Jenkins-Plug-in Gerrit Trigger wird die Option Gerrit Event hinzugefügt. Aktiviert man diese, erscheinen weitere Konfigurationsoptionen, die wie in Abbildung 2 ausgefüllt werden müssen. Zuletzt muss Jenkins noch die Maven-Konfigurationsdatei bekannt gemacht werden, damit der Übersetzungs- und Testprozess gestartet werden kann.

Abb. 2: Konfigurationsoptionen nach Aktivierung der Option Gerrit Event

Soll abweichend von diesem Beispiel ein nicht auf Maven basierendes Projekt überprüft werden, kann im ersten Schritt „FREE STYLE“-SOFTWAREPROJEKT BAUEN ausgewählt werden. Dadurch wird auf der Hauptkonfigurationsseite unter dem Punkt BUILDVERFAHREN die Möglichkeit gegeben, Alternativen zum Übersetzen und Testen der Software zu konfigurieren. Zu den standardmäßig verfügbaren Varianten gehören das Ausführen von Ant- sowie Shell-Skripten. Jedoch lässt sich die Auswahl durch Installation weiterer Plug-ins erweitern. Eine Liste dieser Erweiterungen befindet sich unter [8].

Geschrieben von
Stephan Wagner und Marcus Handte
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.