Travis CI Konfiguration für GitHub

[AdSense-A]

Von Travis CI hört man immer mehr und mehr, wenn man auf GitHub aktiv ist. Travis CI ist ein für OpenSource Zwecke kostenloser Anbieter einer Continuous Integration Lösung. Zusätzlich dazu lassen sich die jeweiligen Status-Flags eines Builds auch als Badge innerhalb der eigenene readme.md auf GitHub einbinden. Einerseits ergibt dies den Vorteil, dass deutlich mehr Transparenz über die Funktionsfähigkeit der Software der Öffentlichkeit dargestellt werden kann und somit ein höheres Vertrauen bei Nutzern der Software entsteht, andererseits ist Travis CI kostenfrei und zum automatisierten Unittesten einer auf GitHub bereitgestellten Anwendung optimal und einfach zu konfigurieren.

Was benötige ich um Travis CI nutzen zu können?

Als erstes wird für die Verwendung vom CI ein GitHub Account benötigt, sowie ein eigenes Git-Repository, welches der Öffentlichkeit zugänglich ist. Anschließend wird der Account über die offizielle Seite von Travis mit dem GitHub Konto verknüpft. Anschließend sofern der Service nicht für das entsprechende Github-Repository bereits konfiguriert wurde, wird dieser in den Einstellungen des Repositorys konfiguriert:

Github Konfiguration

Anschließend muss der CI konfiguriert werden. Die Konfiguration erfolgt anhand einer YAML-Datei mit dem Namen “.travis.yml”. Hierbei können Routinen gefahren werden die vor- oder nachdem eigentlichen CI-Run erfolgen können. Dabei unterscheidet Travis die jeweiligen Routinen wie folgt:

• language – Um welche Sprache handelt es sich?
• before_install – Was soll vor der Installation passieren?
• install – Was soll installiert werden?
• before_script – was soll vor dem Unittest ausgeführt werden?
• script – Unittest lauf
• after_script – Was soll nach dem Unittest passieren?
• after_success – Was soll bei einem erfolgreichen Run passieren?
• after_failure  – Was soll nach einem fehlgeschlagenen Run passieren?
• notifications – Wie soll die Benachrichtigung erfolgen?

Wenn die notwendigen Routinen ausgewählt sind, kann die Konfiguration des Scripts begonnen werden. Hierzu habe ich ein Beispiel Travis-Script erstellt:

language: php

php:
    - 5.4
    - 5.5

install:
  - composer self-update
  - composer install
script:
    - phpunit --coverage-clover build/logs/clover.xml -c tests/phpunit.xml 

after_script:
    - php vendor/bin/coveralls

notifications:
    email: false

Language & php

Der Parameter “language” konfiguriert PHP als Scriptsprache für den Unittest. Anschließend ist ein weiterer Konfigurationspunkt “php” konfiguriert. An dieser Stelle werden die Jobs definiert. Hier in diesem Beispiel wird ein Run mit dem Enviroment der PHP-Version 5.4 und PHP-Version 5.5 getestet.

 Install

Im Install Schritt definiere ich welche Installationen erfolgen sollen. Hierbei wird Composer erst einmal auf den neusten Stand gebracht und anschließend werden alle notwendigen Composer-Pakete installiert.

Script

Dieser Part ist der entscheidende Part. Hier erfolgt der eigentliche Unittests. Verlässt an diesem Punkt eine Anwendung die Routine mit einem anderen ExitCode als 0 so ist der Test gescheitert. In diesem Abschnitt wird bei mir exemplarisch PHPunit mit einem Coveragetest ausgeführt.

[AdSense-B]

After_Script

After Script entscheidet, was nach dem Unittest passiert. In diesem Beispiel verwende ich als weiteren Dienst Coveralls.io um die Coverage des Projektes zu ermitteln.

Notifications

Hier wird definiert wie die Benachrichtigung nach einem Build erfolgt. Standardgemäß, wenn dieser Punkt nicht konfiguriert ist, wird eine Email nach jedem Build versendet. Email: false sagt an dieser Stelle, dass keine Email-Notification erfolgen soll.

Unittesten mit Travis-CI

Anschließend wenn die Konfigurationsdatei erstellt ist und die notwendigen Tests erstellt sind, kann ein Unittest-Run erfolgen. Der Unittest-Run erfolgt beim Pushen auf die Remote-Branch. Dieser sieht wie folgt exemplarisch dann aus:

Travis Run