Continuous Integration mit GitHub

Und ein wenig Continuous Inspection gibt es obendrauf! Aber was ist das nun wieder für Krams?

Begriffsbestimmung

Continuous Integration bedeutet nichts weiter, als seinen Code automatisiert und regelmäßig zu bauen und automatisiert zu testen. Ziel ist es, zeitnah eine Rückmeldung zu bekommen, wenn irgendwas kaputtgeht. Wenn man 15 Minuten nach einem Checkin sieht, dass der Build kaputtgeht oder ein Unit-Test fehlschlägt, weiß man, was man getan hat und kann gezielt suchen. Wenn man dagegen nur einmal alle drei Monate Build und Test durchführt, hat man vermutlich nicht nur einen Fehler an der Backe, sondern mehrere. Dann viel Spaß beim Suchen!

Continuous Inspection ist dasselbe in Grün für Code-Metriken, statische Codeanalyse und so Zeugs (z.B. Testabdeckung oder FindBugs-Läufe für Java).

Man kann für beide Sachen teure Systeme anschaffen. Oder sich einen lokalen Jenkins installieren (einfach, weil fertiges Debian-Paket, und kostenlos) und dann konfigurieren (mmmmmmmh, nunja…). Oder man nimmt was fertiges aus der Tüte:

Zutatenliste

1. ein GitHub-Account
2. ein Travis-CI-Account (auuuus Berlin!)
3. ein CodeCov-Account

Vorbereitung

Ihr braucht auf jedem der drei genannten Dienste einen Account (allesamt für öffentliche Projekte komplett kostenlos) und ganz wichtig: Sowohl Travis als auch CodeCov müssen mit eurem GitHub-Account verknüpft sein. Wie das genau geht is left as an exercise to the reader weil ich das natürlich nur ein einziges Mal vor ein paar Jahren gemacht habe und jetzt nicht mehr weiß, wie. War aber bestimmt ganz einfach!

Rezept

Jetzt kommt Fernsehküche mit ganz viel „ich habe das hier schon einmal vorbereitet“:

1. Man legt sich ein neues Projekt als GitHub-Repository an. Ich nehme ein minimales Java-Projekt mit einer Zeile Code und einem dazu passenden Test. Gebaut und getestet wird per Gradle. (Beispielcommit)
2. Man geht in sein Travis-CI-Profil und aktiviert dort das GitHub-Repository (falls es neu ist, vorher einmal die Repository-Liste synchronisieren).
3. Jetzt legt man in seinem Repository eine .travis.yml-Steuerdatei an, damit Travis weiß, was er zu tun hat. Für ein Java-Gradle-Projekt reicht die Zeile language: java aus. (Beispielcommit)
4. Wenn man das eingecheckt hat, müsste auf der Travis-Webseite der Build loslaufen. Continuous Integration ist jetzt schon fertig! Wenn der Build oder ein Test fehlschlagen, wird der Travis-Status rot und es gibt eine Email. Bei jedem weiteren Commit baut Travis automatisch neu.
5. Um die Testabdeckung zu messen, kann man sich JaCoCo in seine build.gradle einbauen. Man kann dann per gradle jacocoTestReport einen Report erstellen lassen, der unter build/reports/tests/index.html landet. (Beispielcommit)
6. Der Travis-Build kann jetzt auch Testabdeckung messen, aber jedes Mal das Buildlog nach dem Ergebnis zu durchforsten ist umständlich. Um den Report nach CodeCov zu exportieren, ist lediglich die .travis.yml entsprechend anzupassen. (Beispielcommit)
7. Wenn das eingecheckt und der Travis-Job durch ist, müsste das Ergebnis mit kurzer Verzögerung auch auf CodeCov sichtbar sein. Continuous Inspection in der Variante „Testabdeckung“ ist jetzt ebenfalls fertig.

Nettigkeiten

Das ganz läuft und tut, hat aber noch weitere nette Nebeneffekte:

• Beide Dienste sind gut in GitHub integriert: In der Commit-Historie sieht man z.B., welche Commits gebaut wurden und ob der Build ok war oder fehlschlug. Und bei eingehenden Pull-Requests wird direkt mit angezeigt, ob der Build mit den vorgeschlagenen Änderungen durchläuft und wie sich dabei die Testabdeckung verändert.
• Man kann die lustigen kleinen Bäpperles für Buildstatus und Codeabdeckung überall einbinden und anzeigen. (Beispiel, Sourcecode)

That not all, folks!

Travis-CI und CodeCov können noch eine ganze Menge mehr: Erstmal unterstützen sie beide auch andere Sprachen als Java. Dann können sie über diverse Kanäle über Build- und Testergebnisse informieren (z.B. Slack-Channel). Travis kann nach erfolgreichem Build diverse Dinge anstoßen, z.B. automatische Deployments in Testumgebungen, Bereitstellen der Buildergebnisse zum Download oder was-weiß-ich. CodeCov kann auch für Code-Reviews genutzt werden. Genau wie bei GitHub kann man haufenweise andere Tools anflanschen - aber den ganzen Krams habe ich noch nicht benötigt :-)

Viel Spaß zum weiteren Experimentieren also. Der „Fall einfach“ ist wie hier gezeigt schnell umgesetzt. Und selbst wenn man keine Tests schreibt, lohnt sich zumindest der automatische Build per Travis. Denn wer hat zu Hause schon mehrere Perl-Versionen parallel installiert, mit denen er jede Änderung gegencheckt?

In eigener Sache: Abhängigkeitsanalyse

Ein weiteres Tool in dieser Richtung ist VersionEye: Es analysiert z.B. Gradle-Abhängigkeiten und meldet sich, wenn diese veraltet sind (z.B. „hey, Du hast junit-1.27 drin, die 1.28 ist verfügbar und stopft ein Sicherheitsloch“). Problematisch für mich: Die kostenlose Variante erlaubt zwar ein privates Projekt, aber nur vier öffentliche. Und das ist viel zu wenig.

Kennt jemand ein anderes Projekt, was sowas kann? Relevant für mich wäre hauptsächlich Java und vielleicht noch Perl. Ich bin über WhiteSource gestolpert, aber die geben explizite CI-Server an und da steht kein Travis-CI in der Liste. Außerdem gibt es keine direkte kostenlose Account-Anlage, sondern nur ein „contact us“ :-(