Wenn der Build auf dem CI Server fehl schlägt, sollte sofort gehandelt werden. Unser Team hat sich dafür entscheiden, den CI Status zu visualisieren, um besser über den Status informiert zu sein und somit schneller handeln zu können.
In diesem Beitrag werde ich erläutern, wie ich die Visualisierung umgesetzt habe. Direkt im BLOG weiterlesen Bei Jenkins kann man sich im Fall von Fehlern beim Builden via E-Mail notifizieren lassen. Dieser Mechanismus funktioniert gut, solange man am Status von einzelnen Builds interessiert ist. Bei uns werden mehrere voneinander abhängige Projekte gleichzeitig entwickelt und jedes Projekt hat mehrere Build Jobs. Wenn man über den Status all dieser Builds informiert sein will, erhält man ständig E-Mails und es ist sehr schwierig den Überblick über den Gesamtzustand zu behalten. Um den Build Zustand auf einen Blick ersichtlich zu machen und uns von dieser E-Mail-Flut zu bewahren , haben wir uns entschieden den Build zu visualisieren. Als Visualisierungsmedium habe ich mich für Philips Hue entschieden. Philips Hue sieht aus wie eine normale Glühbirne, deren Farbe und Helligkeit kann jedoch kabellos über die Philips Hue Bridge gesteuert werden.
Hue-light ist ein Jenkins Plugin welches je nach Build Status die Farbe einer Hue Glühbirne anpasst. Um die Farbe anzupassen, macht hue-light einen Aufruf auf das REST Interface der Hue Bridge, welche dann die Glühbirne kabellos ansteuert. In unserem Fall ist dies nicht möglich, da die Bridge nicht ans Firmennetzwerk angeschlossen werden kann und somit das hue-light Plugin das REST Interface der Bridge nicht erreichen kann. Um unser Ziel trotzdem zu erreichen, habe ich ein Python Skript erstellt, welches regelmässig den Status von Jenkins Builds abfragt und die Hue Glühbirnen dementsprechend färbt. Das Skript läuft auf einem Laptop, der mit dem Firmennetzwerk (für den Zugriff auf Jenkins) und der Hue Bridge (für die Steuerung der Glühbirnen) verbunden ist. Für die Kommunikation mit Jenkins und der Hue Bridge habe ich die Libraries jenkinsapi und studioimaginaire eingesetzt.
Jede der bei uns entwickelten Applikationen hat mehrere Jenkins Builds (continuous und nightly für Back-End und Front-End?). Die Visualisierung von mehreren Builds pro Applikation braucht viele Glühbirnen und ist unnötig detailliert, deshalb wird ein Status pro Applikation visualisiert. Dieser Applikationsstatus entspricht dem schlechtesten Status aller Builds der Applikation.
Unmittelbar nach der Inbetriebnahme der Visualisierung haben wir gemerkt, dass es sehr hilfreich ist auf einen Blick den Status der gesamten Applikationslandschaft zu sehen. In den folgenden Tagen hat sich herausgestellt, dass man durch die Visualisierung vom Applikationsstatus schneller auf Build Fehler aufmerksam wird und diese zeitnäher behebt. Die Tatsache, dass jeder im Grossraumbüro den Applikationsstatus sieht, ist eine zusätzliche Motivation, Fehler möglichst schnell zu beheben. Da der Status der gesamten Applikationslandschaft visualisiert wird, ist bei Fehlern ersichtlich ob auch andere Applikationen Probleme aufweisen. Wenn die eigene Applikation und eine andere, von der man abhängig ist, gleichzeitig fehlerhaft sind, haben die Fehler in den beiden Applikationen möglicherweise einen Zusammenhang. Mit diesen Informationen geht man auf die Entwickler der anderen Applikation zu und kann somit die Fehler schneller beheben. In den Wochen nach der Inbetriebnahme der Applikationsstatusvisualisierung wurden der teamübergreifende Zusammenhalt und die Zusammenarbeit deutlich besser. Möglicherweise hat das etwas damit zu tun, dass man dank der Visualisierung weniger oft unf lange die Ursache eines Fehlers sucht - und diese schlussendlich in der Applikation eines Arbeitskollegen oder einer Arbeitskollegin findet. Mehr Beitrge von Zhlke
