Travis CI für Fortgschrittene

In unserem ersten Artikel über Travis CI haben wir kurz angerissen, was überhaupt ein Continuous-Integration-Server ist und was Travis alles grob kann. In diesem Folgebeitrag wollen wir ein wenig tiefer in das System einsteigen und nicht nur anschneiden was man alles machen kann, sondern auch ein „wie“ hinzufügen.

Nehmen wir als Beispiel ein Open-Source-Projekt, dass meine Kollegen und ich vor zwei Wochen veröffentlicht haben. Dabei handelt es sich um ein Tool für visuelle Regressionstests wie phamtomCSS, nur eben für PHP. Unsere Anforderungen an ein CI-System waren folgende:

Tool hat Abhängigkeit zu Imagick als PHP-Erweiterung
Tool nutzt PhantomJS als Browser
Tool muss unter php 5.3, php 5.4 und php 5.5 laufen
Tool setzt auf Codeception auf und muss mit Version 1.8 und 2.0.0-beta kompatibel sein
Version 2.0.0-beta von Codeception ist nicht php 5.3 kompatibel

Wahrscheinlich hatten wir mit diesen Anforderungen die meisten Standardprobleme mit einer CI-Umgebung bereits angeschnitten. Wie wir dies gelöst haben wird im folgenden Abschnitt erklärt.

Wie bereits im ersten Artikel beschrieben wird Travis einzig und allein über eine Datei mit dem Namen .travis.yml im Rootverzeichnis des Projektes angesteuert. Diese zu erstellen bedeutet Travis korrekt auf das Projekt auszurichten.

Abhängigkeiten zu nicht vorhandenen Bibliotheken (Tool hat Abhängigkeit zu Imagick als PHP-Erweiterung)
Die Travis-CI-Umgebung hat zwar viele Pakete vorinstalliert, Imagick ist aber nicht dabei. Aus diesem Grund muss man die Installation in seinem eigenen Skript übernehmen.
Vor jedem Testdurchlauf hat man die Möglichkeit ein oder mehrer Skripte aufzurufen. Diese sind im Abschnitt before_script einzutragen. Da pecl bereits auf dem System vorhanden ist, ist die Installation von Imagick relativ trivial (apt-get ud Composer sind übrigens auch vorhanden). Zumindest wenn man weiß, wie es geht. Die Zeile in unserer YAML-Datei sieht wir folgt aus:
```
before_script:
  - printf "\n" | pecl install imagick
```
Warum wir ein printf „\n“ mit Code haben ist einfach zu erklären. Bei der Installation von Imagick muss man auf der Kommandozeile eine Frage beantworten oder einfach ENTER drücken, für den Default-Wert. Das übernimmt das printf für uns.
Starten von benötigten Programmen im Hintergrund (Tool nutzt PhantomJS als Browser)
PhantomJS ist zwar bereits auf dem System installiert, das Problem ist aber, dass Codeception am liebsten über eine Selenium-Server damit kommuniziert und der ist nicht drauf. Also wieder das before-skript nutzen und Selenium herunterladen und im Hintergrund starten:
```
before_script:
  - wget http://selenium.googlecode.com/files/selenium-server-standalone-2.35.0.jar
  - java -jar selenium-server-standalone-2.35.0.jar -port 4444 >/dev/null 2>&1 &
```
Wer sich mit Linux ein wenig auskennt, weiß, dass mit dem & der Befehl in den Hintergrund befördert wird und mit dem Größer-Symbol der Output direkt in den Mülleimer befördert wird. Wenn man dies nicht macht, wird das Log-File von Travis recht unübersichtlich, weil in allen Ecken Zeilen aus dem Selenium-Server zu finden sind.
Mehrere PHP-Versionen unterstützen (Tool muss unter php 5.3, php 5.4 und php 5.5 laufen)
Auch wenn man denkt, dass dieser Punkt am kompliziertesten ist, ist er doch trivial. Travis hat eine Umgebung für jede dieser Versionen und wenn man Spaß hat oder einfach nur neugierig ist, kann man sogar gegen HHVM von Facebook testen. Nützt einem im wahren Leben wahrscheinlich noch nicht so viel, aber das kann ja bald kommen.
```
language: php
php:
  - 5.3
  - 5.4
  - 5.5
```
So würde die travis.yml in unserem Fall dafür aussehen. Recht einfach und trotzdem mächtig.
Kompatibilität zu mehreren Werkzeug-Versionen (Tool setzt auf Codeception auf und muss mit Version 1.8 und 2.0.0-beta kompatibel sein)
Auch recht einfach, aber nicht so häufig im Einsatz sind Umgebungsvariablen, wie wir sie aus dem Linux-Umfeld kennen. Wenn man diverse „Strings“ in seinen Skripten immer wieder verwenden will, kann es sinnvoll sein diese in eine Variable auszulagern, so man sie im Fall einer Änderung nur an einer Stelle editieren muss. In unserem Fall wollen wir die Codeception-Version auslagern. Dies würde sich in Code wie folgt niederschlagen:
```
env:
 - CODECEPT_VERSION="1"
```
Jetzt können wir diese Variable im weiteren Skript nutzen. Unser eigentlicher Aufruf sieht dann wie folgt aus:
```
script: php codecept${CODECEPT_VERSION}.phar run -d
```
Das eigentlich Problem, dass wir gegen zwei verschiedene Versionen von Codeception testen wollen, haben wir noch nicht gelöst. Ist aber auch nicht weiter kompliziert. Travis gibt und die Möglichkeit eine zweite bzw. n-te Variante unserer Umgebungsvariablen zu hinterlegen. Dies sieht dann wie folgt aus:
```
env:
 - CODECEPT_VERSION="1"
 - CODECEPT_VERSION="2"
```
Schon unser Continuous-Integration-Server nicht mehr nur drei mal die Tests durchlaufen (php 5.3, php 5.4, php 5.5), sondern sechs mal. Jetzt läuft das System z.B. für php 5.3 mit Codeception 1 und Codeception 2. Travis nennt dies eine Matrix. Was ja auch Sinn macht.
Entfernen von Testdurchläufen aus der Matrix (Version 2.0.0-beta von Codeception ist nicht php 5.3 kompatibel)
Travis wäre nicht so toll, wenn man hierfür nicht auch eine einfache Lösung anbieten würde. Der Aufbau der Matrix ist recht einfach, aber auf diese Weise kann man nur eine starre Struktur aufbauen, die keine Ausnahmen kennt. Um diese nachträglich einzuführen hat man die Möglichkeit einzelne Elemente zu entfernen. Diese kann man aus einer Kombination aus env und php identifizieren. In unserem Fall wollen wir php 5.3 und Codeception 2 nicht miteinander spielen lassen.
```
matrix:
  exclude:
    - php: 5.3
      env: CODECEPT_VERSION="2"
```
Auf diese Weise kann man noch ein paar kleine Spielereien machen. Zusätzlich zu exclude gibt es auch einen „allow failues“-Befehl. Dies könnte man zum Beispiel auf die HHVM-Tests anwenden. Ist zwar schön zu wissen, dass man damit kompatibel ist, aber wenn ein Test mal fehlschlägt, dann hat das keine Aussage darüber, ob das Tool funktioniert. Ist ja schließlich nicht wichtig, dass es in dieser Umgebung funktioniert.

Alles in allem ist die Verwendung von Travis recht intuitiv, wenn man ein wenig Erfahrung mit Linux und Softwareentwicklung hat, aber wer aus der Webentwicklung kommt, der sollte damit kein Problem haben.

PS: Für alle, die gerne mal das ganze Skript am Stück sehen wollen, dem sei dieser Link ans Herz gelegt.