Bis 2011 betrieb das kleine Team von GitHub seine Infrastruktur aus dem Campfire-Chat heraus, und ihr Bot war „größer und unordentlicher“ geworden. Sie schrieben ihn von Grund auf neu und veröffentlichten ihn als Open Source unter dem Namen Hubot – ein Bot, der Code ausliefert, dem CI-Server vorgeschaltet ist und Ops-Befehle für das gesamte Unternehmen sichtbar macht.
Die Idee
Die Werkzeuge in den Chatraum bringen: ein Bot, der Code deployt, CI ausführt und den letzten Deployer anpingt, wenn Fehler in die Höhe schnellen – jede Aktion sichtbar, nachvollziehbar und für alle zugänglich.
Hubot lauscht auf Befehle wie „/deploy my-feature“; die Entwickler deployen aus dem Chat heraus, und wenn die Ausnahmeraten in die Höhe schnellen, pingt der Bot den letzten Deployer mit einem Link zum internen Haystack-Dashboard an und weist ihm damit implizit die Verantwortung zu. 2011 wurde er als Open Source veröffentlicht, und bis 2020 führte GitHub weiterhin 120–150 Produktions-Deployments pro Woche über ChatOps durch, mit Canary-Rollouts und Hunderten von Pull Requests, die pro Deployment gebündelt wurden.
Das Deployment bei GitHub wurde zu einem Chat-Befehl, den jeder ausführen und jeder sehen konnte: Bei gleichbleibender Zahl wöchentlicher Deployments werden heute weit mehr Änderungen ausgeliefert, die Rollbacks blieben niedrig genug, um eine „Kultur des Vertrauens“ aufzubauen, und der Begriff ChatOps verbreitete sich in der gesamten Branche, als Teams das Muster kopierten.
2011 war GitHub ein kleines Unternehmen, das einen sehr großen Dienst betrieb, und sein Team lebte im Campfire-Chat. Ihr Bot war „größer und unordentlicher“ geworden, also schrieben sie ihn von Grund auf neu und veröffentlichten ihn als Open Source: Hubot, „ein erstaunlicher Campfire-Bot“, der sie zum Lachen brachte, ihren Code auslieferte und als Schnittstelle zu ihrem CI-Server diente.
Aus dieser Praxis entwickelte sich, was GitHub ChatOps nannte: Entwickler führen „/deploy my-feature“ im Chat aus, und Hubot übernimmt Authentifizierung, Staging und Canary-Rollouts. Wenn die Ausnahmen nach einem Deployment in die Höhe schnellen, pingt Hubot den letzten Deployer mit einem Link zu Haystack an, GitHubs internem Ausnahme-Dashboard – „der unmittelbare Nutzen dieses Pings besteht darin, dass er implizit eine verantwortliche Partei festlegt“.
Bis 2020 war das Muster ausgereift: Das Deploy-Team von GitHub beschrieb Deployments, die mit „einer Reihe von Hubot-Befehlen“ angestoßen wurden, mit 120–150 Produktions-Deployments pro Woche für github.com, mit mehr als 400 Pull Requests, die in einer einzigen Woche ausgeliefert wurden, und mit genug Vertrauen in den Prozess, dass die Rollbacks niedrig blieben und Entwickler mergen und weitermachen konnten.
Es beseitigte den Engpass der Frage „wer darf die Produktion anfassen“ – jeder Entwickler konnte aus dem Chat heraus deployen, und die Aktion war für das gesamte Unternehmen sichtbar.
Der Bot machte Verantwortung implizit: Der letzte Deployer wird angepingt, wenn Fehler in die Höhe schnellen, sodass Probleme einen Verantwortlichen finden, statt auf die Triage zu warten.
Weil jeder Befehl in einem gemeinsamen Kanal lief, wurde das Deployment nachvollziehbar und lehrbar – neue Entwickler lernten Ops, indem sie den Chat beobachteten.
Die Open-Source-Veröffentlichung von Hubot verwandelte eine interne Bequemlichkeit in ein Branchenmuster und machte den Begriff ChatOps populär.
Ein internes Werkzeug gewinnt, wenn es die sozialen Kosten des Handelns senkt: Ops in den Chat zu verlegen machte Deployments sichtbar, nachvollziehbar und sicher zu delegieren – die Änderung der Schnittstelle ist das, was die Kultur veränderte.
Seitdem
ChatOps wurde zu einer weithin kopierten Praxis, und Hubot wuchs zu einem Community-Projekt mit Adaptern für Slack, Discord und Teams heran. Bei GitHub entwickelte sich die Deployment-Pipeline weiter – IssueOps und GitHub Actions bauten später auf derselben Idee auf –, während das zugrunde liegende Prinzip, Menschen die Infrastruktur aus den Werkzeugen heraus betreiben zu lassen, die sie ohnehin gemeinsam nutzen, zentral dafür blieb, wie GitHub ausliefert.
DEN BELEGEN FOLGEN
Die Quellen
- Say Hello to Hubot GitHub Blog · github.blog ·
- Exception Monitoring and Response GitHub Blog · github.blog ·
- DevOps best practices Q&A: Automated deployments at GitHub GitHub Blog · github.blog ·