Travis CI

Manchmal nutzt man Tool, die für einen selbstverständlich sind und vergisst, dass es vielleicht nicht allen so geht. Wer nicht in der Open-Source-Szene unterwegs ist, der hat vielleicht nicht so häufig Kontakt zu Travis CI, welches ich heute grob vorstellen will. Zuallererst hoffe ich mal, dass ich den Artikel umsonst schreibe, weil ihr alle die Continuous-Integration-Lösung bereits kennt. Und wenn nicht, dann wird es Zeit.

Travis CI ist also eine Software (as a Service), die mir kontinuierlich hilft zu überprüfen, ob meine Anwendung noch läuft oder ob ich sie kaputt programmiert habe. Dabei ist das Tool sehr stark an GitHub gekoppelt.

Nehmen wir folgende Situation. Nils bastelt gerade im Open Performance Monitor und checkt seinen Source-Code bei GitHub ein. Jetzt bekommt Travis CI einen Stupser von den Hub-Jungs und checkt meinen Quelltext aus. Nun kann man über eine Konfiguration, die mit im Projekt liegt dem Server sagen, was er alles mit dem Projekt anstellen soll. In unserem Fall wäre es das Bauen des Projektes und das anschließende Ausführen der Unit Tests. Wenn die Tests erfolgreich durchlaufen, macht er nichts und wenn nicht, dann bekomme ich eine Mail. Eine solche Konfiguration könnte wie folgt aussehen:

language: php
php:
- 5.5
- 5.4
- 5.3

before_script:
- composer install

script: phpunit --bootstrap tests/bootstrap.php tests

Schön finde ich, dass man auf Anhieb sehen kann, was gemacht wird. Zumindest das geschulte Entwicklerauge. Vor den Tests wird Composer aufgerufen, um die Abhängigkeiten aufzulösen und danach wird phpunit ausgeführt. Das war’s schon. Sobald man diese Steuerdatei unter dem Namen .travis.yml in Root-Verzeichnis seines Projektes angelegt hat und die Systeme verbunden hat, kann es losgehen.

Jetzt kommen wir zu den tollen zusätzlichen Features. Das noch geschultere Auge wird nämlich auch die angegebenen PHP-Versionen entdeckt haben. Travis erkennt diese und wird die Tests in drei Umgebungen ausführen und zwar parallel. Einmal PHP 5.3, einmal 5.4 und dann noch PHP 5.5.

Ein weiteres einfaches, aber dennoch nützliche Feature sind die Build-Status-Icons. Hinter jedem Projekt steckt eine Grafik-URL mit dem Build-Status.

Wenn mein Projekt jetzt kaputt ist, kann das jeder sofort sehen. Momentan ist es heile, aber wer weiß, was der Tag noch so alles bringen wird.

Mein Lieblingsfeature existiert im Zusammenhang mit Pull Requests. Jeder der sich ein wenig mit Git und GitHub auskennt, weiß, dass sich ganz viel um solche Requests dreht. Travis weiß, wie wichtig sie sind und reagiert auf diese. Für uns Projektverantwortliche bedeutet dies, dass jedes mal, wenn uns jemand einen solchen Request übergibt, Travis losläuft und schaut, ob das was da kommt auch funktioniert. Wenn ja, dann sagt mit das die Oberfläche in GitHub. Beim Fehler natürlich auch.

Wer Detailfragen hat, der kann die gerne stellen. Ich hoffe, dass ich dem ein oder anderen das System schmackhaft gemacht habe.