Shiny Adventures

Shiny Adventures

of a software developer, @jhipster board member, @jugpaderborn organizer and father

Frederik Hahne

Jeder kennt vermutlich GitHub und hat bestimmt schonmal gedacht, wie es vor GitHub gewesen ist und warum GitHub die Softwareentwicklung verändert hat. Es gab schon vor GitHub eine Reihe von Anbietern, die Versionskontrolle für OSS Projekte kostenos zur Verfügung gestellt haben, wie Googlecode, Sourceforge und Bitbucket. Der größte Unterschied meiner Meinung nach ist die Tatsache, dass GitHub von Beginn an eine Api angeboten hat um Drittanbietern die Interaktion mit einem Projektrepository zu ermöglichen. Dadurch hat sich ein großes Ökosystem von Tools rund um GitHub gebildet, die es einem möglich machen nahezu ausschließlich auf kostenlose Services zu setzen um z.B. sein Projekt mit per continuous integration zu bauen.

Folgende Tools sollte man sich als (Java)entwickler auf jedenfalls mal näher anschauen:

Travis CI, Drone.io

Travis CI ist ein Cloudservice, der eigentlich nichts anderes macht als ein Projekt zu bauen. Mit Hilfe einer kleinen Konfigurationsdatei kann man allerhand Einstellungen vornehmen, sodass sehr viele (Sonder)fälle abgedeckt werden können. Es ist zum Beispiel auch sehr einfach möglich eine gebaute Anwendung direkt auf Heroku zu deployen. Da jeder Build in einer eigenen VM abläuft kann man im Notfall, falls die Konfigurationsmöglichkeiten nicht ausreichen auch ein Shell-Script ausführen, dass mache ich zum Beispiel um die Mensa-UPB App zu bauen, da die Standardkonfiguration für Android-Projekte immer etwas hinter der aktuellsten Version der Build-Tools hinterherhinkt.

Durch die enge Integration von Travis in GitHub wird jeder push automatisch gebaut. Jeder Pull-Request wird von Travis gemerged und dann gebaut, das Result wird dann in den Thread des PRs auf GitHub publiziert, sodass der Autor des PRs und der Besitzer transparent und zeitnah über einen möglicherweiße fehlerhaften PR informiert werden.

Pull-Request während eines Builds
Pull-Request nach erfolreichem Build

Drone.io ist sehr ähnlich zu Travis, unterstützt aber auch Bitbucket. Drone.io verfolgt einen sehr minimalistischen Ansatz. Es ist für ein Standardprojekt (z.B. Gradle oder Maven) keine weitere Konfiguration nötig. Wie bei Travis kann der eigentliche Befehl zum Build angepasst werden (direkt in der Weboberfläche) und z.B. durch ein shell script implementiert werden. Drone integriert sich nicht so tief in GitHub, daher bevorzuge ich Travis, wenn man sowieso schon seinen Source-Code auf GitHub liegen hat. Drone.io reagiert auf push-events sehr viel schneller als Travis, allerdings vermute ich, dass es daran liegt, dass drone.io noch nicht so stark benutzt wird wie travis und daher einfach mehr Kapazitäten (noch) frei sind.

Coveralls

Coveralls aggregiert die während des Builds erstellten Code Coverage Reports in einer übersichtlichen Art und Weise. Die Daten müssen durch das Buildwerkzeug bereits erstellt worden sein, Coveralls ist nur ein “Frontend” zur Darstellung der Coverage. Ähnlich wie bei Travis ist die Integration in GitHub sehr tief. Bei jedem Pull Request trägt Coveralls das Resultat in den PR ein.

Änderung der Coverage

Waffle.io

Und für eine schicke Ticketverwaltung kann man waffle.io mal ausprobieren. Ein Waffle Board ist ein kleines, digitale Scrum/Kanban Board. Jede Änderung in GitHub ist direkt in Waffle sichtbar und umgekehrt, sehr praktisch.

Waffle Kanban Style Board

Recent posts

See more

About