Der Fortschritt in der IT Systemtechnik zeigt sich nicht nur an immer leistungsfähigeren Systemen, sondern auch an immer kleineren.
Ein schöner Seiteneffekt des technologischen Fortschritts ist, dass diese Kleinstsysteme sehr sparsam im Energieverbrauch sind.
Ein junger Spross dieser Systeme ist der Raspberry Pi - Ein Minisystem so groß wie eine Zigarettenschachtel, und dennoch ein vollwertiger Rechner; aber energergiesparsam (ca. 5W) und preiswert (knapp 60€ inklusive Case, Stromkabel und SD-Karte).
CosmoCode verfügt über Erfahrung bei der Entwicklung von embedded Systemen, und so konnten wir nicht umhin, ihn auszuprobieren und einzusetzen: In unserem Fall als Thin Client, der eine Webapplikation an einen zentralen Monitor ausgibt.
Bei der Webanwendung handelt es sich um die Statusanzeige unserer Integrationssysteme. Diese haben wir nun dank des RPi zentral an der Wand.
Bei CosmoCode gibt es viele Projekte - langlebige, kurzlebige, kleine und wiederum sehr komplexe. Manchmal arbeiten ganze Teams an der Abarbeitung der Aufgaben, manchmal ist es aber auch nur ein/e Mitarbeiter/in. Bei allen allerdings ist es von Vorteil, wenn Entwicklungsstände schnell und ohne ständiges Eingreifen eines Admins auf eine Live-Umgebung oder einer Integrationsmaschine gespielt werden können, weil sich die Rechner der Entwickler untereinander stark unterscheiden können und niemand wahrhaftig mit einem Debian entwickeln möchte.
Dafür bietet sich natürlich das Prinzip Continuous integration an. Jeder noch so kleine Code-Schnipsel der Enwickler landet somit auf einer dem Live-Server ähnelnden Maschine und kann sofort unter „Live-Bedingungen“ getestet werden. Für diese Aufgabe nutzen wir bei CosmoCode den CI-Server Jenkins. Einmal eingerichtet, lässt er sich über unzählige Plugins an die eigenen Bedürfnisse anpassen.
Doch was passiert, wenn beim Deployment auf die Live- oder Integrationsumgebung Fehler auftreten? Die Verbindung zum Server kann nun nicht mehr hergestellt werden, das Debian-Paket wurde nicht ordentlich geschnürt und bringt dpkg zum Absturz, die neue Konfiguration für den nginx kann nicht gestartet werden, weil ein Semikolon fehlt, u.s.w.
Der Entwickler weiß in diesem Fall nicht, ob seine Software auf dem Server ordentlich angekommen ist, ob seine geschriebenen Tests ohne Probleme dem Testverfahren standgehalten haben.
Wir haben unseren Entwicklern dafür einen Monitor an die Wand gehängt, der nun für die aktiven Projekte der Mitarbeiter des Raumes alle wichtigen Informationen darstellt. Darüber ist zum Beispiel ersichtlich, wer am aktuellen Build-Prozess beteiligt war und wann dieser Build voraussichtlich beendet sein wird.
Wenn Fehler auftreten, kann so schnell identifiziert werden, wessen Code zum Fehler führte - ohne zuerst den Schuldigen suchen zu müssen.
Soviel zur Software, nun die Hardware: Ein ausrangierter 4:3 Monitor und ein sehr umweltfreundlicher, da energiesparender Raspberry Pi reichten für dieses Vorhaben. Einmal mit Strom versorgt, bootet er zur Darstellung eines Browsers und meldet sich an Jenkins' Monitoring-Plugin an. Als Browser lassen wir Chromium (http://www.chromium.org/) im Kiosk-Mode auf dem Raspberry laufen; nun noch schnell den Mauszeiger versteckt, denn wir wollen den Platz ja für wichtige Informationen haben.
Das mitgelieferte Plugin eXtreme Feedback Panel (https://wiki.jenkins-ci.org/display/JENKINS/eXtreme+Feedback+Panel+Plugin) lädt alle 10 Sekunden die Informationen vom Jenkins-Server ab. Leider kam es dabei zu störendenden flackernden Darstellungen, da der gesamte Seiteninhalt neu geladen wird. Unser Entwickler Oliver hat das Plugin dahingehend angepasst, dass nicht der gesamte Inhalt neugeladen, sondern nur die Teile der Seite per AJAX nachgeladen werden, die sich auch tatsächlich verändert haben. Offensichtlich gefällt das auch Anderen, denn Olis Code findet sich inzwischen auch im offiziellen Plugin wieder.
Kommentare