© Excellent backgrounds/Shutterstock.com
Bot-basierte Kommunikation

DevOps mit ChatOps


Viele Softwareunternehmen versuchen zurzeit, DevOps zu implementieren und ihre Prozesse und Abläufe entsprechend zu optimieren. Im Zuge dieses Hypes halten verschiedene neue und wiederentdeckte Techniken Einzug in den Arbeitsalltag, eine davon ist ChatOps.

Kommunikation ist der Austausch oder die Übertragung von Informationen [1]. Übertragung heißt, dass dabei Distanzen überwunden werden können. In diesen zwei Sätzen stecken mehrere essenzielle Informationen und Herausforderungen, mit denen wir im alltäglichen Geschäft von Softwareentwicklung und -betrieb konfrontiert werden. Grundlegend bedarf jeder Schritt der zwischenmenschlichen Kommunikation, wenn mehr als eine Person an der Lösung einer Aufgabe beteiligt ist. Nicht jeder Informationsaustausch kann zwischen zwei Personen im gleichen Raum stattfinden. Absprachen finden auch mit entfernten Kunden und zunehmend in verteilten Teams statt. Sowohl im kommerziellen als auch im Open-Source-Umfeld soll natürlich auch jede wichtige Information dokumentiert werden, ohne gleichzeitig einen übermäßigen Aufwand zu erzeugen.

Klassisch fand diese Kommunikation per Telefon und Fax statt, mittlerweile benutzen die meisten Firmen ­E-Mail oder Ticketsysteme. Für interdisziplinäre Teams, die teils räumlich verteilt zusammenarbeiten, ist das zu zeitaufwendig und kompliziert. Um Informationen schneller und transparenter zu verteilen, haben sich in vielen Projekten Chatsysteme etabliert, in denen offene Fragen für alle Teilnehmer sofort ersichtlich sind, sodass dem Autor direkt geantwortet oder geholfen werden kann. Zusätzlich ist klar, ob die Frage bereits beantwortet wurde oder die Antwort noch erweitert oder korrigiert werden sollte. Beispiele dafür sind: IRC (Internet Relay Chat, Text-only), Slack, HipChat, Mattermost, Rocket.Chat (Browserclient mit bunten Bildern) oder die Integrationen in anderen Kommunikationstools (Skype, Google Hangouts, Jabber/XMPP).

Im Chat geschriebene Kommunikation können auch Teammitglieder nachlesen, die erst zu einem späteren Zeitpunkt aktiv werden, da sie andere Arbeitszeiten haben oder sich in einer anderen Zeitzone aufhalten. Natürlich ist das auch bei E-Mail und Ticketsystemen gegeben, doch in einem Chatroom lassen sich unserer Erfahrung nach Informationen einfacher kontextbezogen austauschen. Zusätzlich gibt es hier oft schnelleres Feedback, weil Chatteilnehmer Fragen oder Anforderungen möglicherweise direkt beantworten können, wenn die adressierte Person gerade nicht verfügbar ist.

ChatOps: Was ist das denn nun?

Da sich viel Kommunikation im Chat abspielt, entstand die Idee, den Chat auch als Interface und Steuerungsmechanismus für andere Systeme zu nutzen. Der Vorteil besteht darin, dass man nicht erst im Chat über einen bevorstehenden Arbeitsschritt informieren muss, sondern diesen Schritt auch ausführt und das entsprechende Feedback automatisch im Chat persistiert wird, sodass andere Teilnehmer informiert sind und reagieren oder unterstützen können.

Die heute verbreitete Ausprägung von ChatOps wurde maßgeblich von GitHub vorangetrieben, dort wurde 2011 der interne Chatbot unter dem Namen Hubot neu implementiert, als Open-Source-Projekt bereitgestellt und aktiv für diese Arbeitsweise geworben [2]. Die Grundidee ist, einen Bot im Chat bereitzustellen, der auf bestimmte Keywords und Parameter lauscht und entsprechende Aktionen ausführt. Der Bot kann als eine geteilte Shell gesehen werden, in die alle Chatteilnehmer Befehle eingeben können (Abb. 1).

kuehn_chatops_1.tif_fmt1.jpgAbb. 1: Der Bot sagt hallo

Es besteht die Möglichkeit, einem Bot einen Befehl zu geben, dessen Ausführungszeitpunkt, Syntax und Rückgabewert alle Chatteilnehmer sehen können. Der Chat wird damit zur Middleware zwischen verschiedenen Diensten, die alle zentral gesteuert werden können. Mit der Ausführung der Befehle oder Aktionen mittels Chat ist automatisch sichergestellt, dass alle Teammitglieder sehen können, was genau passiert ist.

Einfache Kommunikation, wenige Missverständnisse

Ein Beispiel ist ein Projekt, für das zu einem bestimmten Zeitpunkt händisch ein Release getriggert werden soll. Je nach Aufbau einer vorhandenen CI/CD-Pipeline könnte man sich das folgendermaßen vorstellen:

  • Eine neue Versionsnummer wird in eine Konfiguration wie Maven pom.xml eingetragen.

  • Es wird ein Git-Tag mit dieser Versionsnummer angelegt und ins Code-Repository gepusht.

  • Jenkins [3] wird benachrichtigt und beginnt mit dem jeweiligen Build.

  • Das entstandene Artefakt wird in ein passendes Artefakt-Repository gespeichert. Wir benutzen hier abhängig vom Projekt Nexus [4] oder Artifactory [5].

  • Das Artefakt wird von seinem Speicherort auf einen Server deployt.

Dieser komplette Ablauf ist typischerweise schon automatisiert, z. B. in einer Jenkins-Pipeline, und muss nur noch ausgelöst werden. Das kann auf verschiedene Arten passieren, je nach Ausbau der Automatisierung händisch, als Skript oder beispielsweise als Post-Receive Hook in Git. Der Aufruf dieser Releasepipeline mithilfe eines Chatbots könnte wie in Abbildung 2 aussehen.

kuehn_chatops_2.tif_fmt1.jpgAbb. 2: Aufruf der Releasepipeline

Die ausgeführte Funktion ist für das ganze Team und sonstige Chatteilnehmer leicht zu erkennen: Der Benutzer chris hat um 10:19 Uhr eine Funktion release mit den Parametern DemoProjekt und 1.0 ausgeführt. Der Bot hat sofort angezeigt, dass die Eingabe erkannt wurde. Nach Beendigung des Jobs zwei Minuten später hat er eine positive Rückmeldung in den Chat geschrieben. Zusätzlich lässt sich diese Meldung natürlich auch in weitere Chatrooms schreiben.

Hätte der Benutzer die Pipeline händisch auf seinem Rechner gestartet, wäre es nötig gewesen, die anderen Teammitglieder von dieser Aktion in Kenntnis zu setzen. Er hätte also neben der eigentlichen Aktion in den Chat schreiben müssen, wann er diese Aufgabe erledigt hat und möglicherweise auch den jeweiligen Return-Wert oder die Fehlermeldung. So hat der Benutzer nicht nur seine eigene Z...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang