Continuous Integration ohne Klimmzüge

Open-Source-Projekte profitieren von agilen Entwicklungsverfahren mit Continuous Integration (CI). Jede Veränderung des Codes im öffentlichen Repository sollte automatisch den Lauf der Testsuite anstoßen, um die Entwicklergemeinde unmittelbar auf etwaige Probleme hinzuweisen.

Klick statt Klimmzug

Wer meinte, es erfordere doch einige Klimmzüge, um mit CI-Tools wie Jenkins [2] (ehemals Hudson, [3]) und den dafür notwendigen Konfigurationsdaten zu einer Dauertestumgebung zu gelangen, sah sich kürzlich eines Besseren belehrt: Auf der Seite Travis-ci.org klickt der Nutzer den Login-Button an, der zum Projekthoster Github verzweigt. Dort spürt der Service die Repositories des Users aufs und holt – ebenfalls per Knopfdruck – die Genehmigung ein, diese im Administrationsbereich zu manipulieren. Zurück bei Travis findet der verdutzte Entwickler eine Liste seiner Github-Projekte mit formschönen On/Off-Knöpfen (Abbildung 1).

Abbildung 1: Legt der Travis-User den Schalter für ein Projekt um, benachrichtigt Github den Travis-Service bei jedem Code-Update.

Ein Klick auf »ON« stellt den CI-Server auf das Projekt ein. Nun muss nur noch eine etwa dreizeilige YAML-Datei in die Projektwurzel (Abbildung 2) – und von nun an wirft Travis bei jedem Push ins Github-Repository die Testsuite an (Abbildung 3) und meldet per E-Mail, falls etwas zusammenbricht. Der Travis-Service unterstützt neuerdings sogar Perl, und zwar in drei verschiedenen Versionen (5.10, 5.12, 5,14), nachdem Java, Javascript (mit Node.js), Python, PHP, Ruby und sogar Clojure, Erlang, Groovy, Haskell und Scala schon länger im Programm sind.

Abbildung 2: In der Datei .travis.yml im Rootverzeichnis eines Repository steht, in welchen Umgebungen Travis-ci.org die Tests fahren soll.

Abbildung 3: Direkt nach einem Code-Update auf Github wirft Travis-ci.org die Testsuite an.

Einfaches ist einfach

Im einfachsten Fall definiert die YAML-Datei ».travis.yml« , wie in Abbildung 2 gezeigt, nur die verwendete Sprache im Projekt (»language: perl« ) und Travis leitet daraus dann selbstständig per Konvention ab, wie die sprachtypischen Testsuites aufzurufen sind. In Perl geschieht dies üblicherweise mit dem Zweisatz »perl Makefile.PL; make test« , aber auch mit neueren »Build.PL« -Dateien kommt der Service klar. Nutzt ein Projekt aber von der Norm abweichende Testsuites, definiert der Entwickler einfach in ».travis.yml« , mit welchen Skripten diese aufzurufen sind.

Dabei läuft bei einem Perl-Projekt nicht nur die Testsuite ab, sondern der Travis-Service stellt auf einem seiner Worker-Systeme eine aufgeräumte Umgebung bereit, holt die in den Projektdateien angegebenen Perl-Module als Tarballs vom nächsten CPAN-Mirror, installiert sie in der definierten Reihenfolge und stößt erst dann die Testsuite an. All das erfordert keinerlei Konfiguration, der Service leitet diese Schritte und Aktionen allein von den mit »language: perl« festgelegten Standardkonventionen ab.

Abbildung 4: Die Testsuite läuft erfolgreich durch.

Laufen die Vorbereitungen inklusive der eigentlichen Testsuite problemlos durch, zeigt Travis dies im Ausgabefenster an (Abbildung 4) und markiert den Durchlauf in der Übersicht mit einem grünen Punkt. Falls im vorherigen Durchlauf ein Fehler aufgetreten war, geht im Erfolgsfall zudem eine E-Mail an den oder die Entwickler, ansonsten schweigt Travis.