Bender is de interne Slackbot waarmee het engineeringteam van Join pull requests, tests en deployments bestuurt. Staff engineer Omar El-Khatib werkte aan de workflow en beschrijft hier waarom het team niet koos voor nog een los dashboard.
Meldingen zonder samenhang vertraagden de release
Onze releaseketen gebruikt onder meer GitHub, GitHub Actions, CircleCI, Google Cloud, Kubernetes en Jira. Elk onderdeel kan zijn eigen taak uitvoeren. De vertraging ontstond bij de overdracht: melden dat een pull request klaarstaat, de juiste reviewer vinden, een mislukte test terugkoppelen, services in een wachtrij zetten en tickets bijwerken.
Bender begon op basis van de opensourcebot Hubot. Later migreerden we naar een Slackapp met Bolt for JavaScript. Webhooks en publieke API’s verbinden de bot met de rest van onze stack; een datastore in Google Cloud bewaart de status die nodig is om een release te volgen.
Eén Slackthread volgt de hele release
Een ontwikkelaar plaatst een pull request in het code-reviewkanaal. Bender noemt de reviewers, koppelt GitHub-reacties terug en toont of GitHub Actions is geslaagd. Staat er een geldige Jira-code in de titel, dan verplaatst de bot het ticket naar code review.
Na het samenvoegen bouwt GitHub de image. Bender zet de service in de deploymentwachtrij en laat CircleCI de end-to-endtests uitvoeren. Bij een fout krijgt de auteur de mislukte scenario’s met links te zien; de bot beheert de herstart. Een geslaagde service gaat naar staging voor handmatige QA, waarna ook het Jira-ticket naar de volgende status verhuist.
Productie blijft bewust een menselijke beslissing. Bender vergelijkt staging met productie, noemt iedereen met een wijziging en telt de benodigde goedkeuringen in dezelfde thread. Pas wanneer die mensen akkoord geven, voert een ontwikkelaar het productiecommando uit.
De bot bewaart ook de laatste tien versies van een service, zodat het team naar een bekende versie kan terugrollen. Tijdelijke wijzigingen aan omgevingsvariabelen kunnen zonder volledige code-release worden aangebracht. Daar zit een prijs aan: code en Bender kunnen dan tijdelijk twee bronnen van waarheid worden. Daarom ruimt het team deze overrides periodiek op en schrijft de definitieve waarde terug naar de configuratie in de repository.
De kosten zijn eigenaarschap
Een eigen bot vermijdt handmatige overdrachten, maar is geen gratis laag. Het team onderhoudt de repository, API-koppelingen en datamodellen zelf. Wanneer Slack, GitHub of Jira een interface wijzigt, ligt het herstelwerk bij ons. Dat is alleen verantwoord omdat de bot een workflow bedient die we iedere dag gebruiken en waarvan we de uitzonderingen zelf kennen.
De gemiddelde frontendrelease uit het oorspronkelijke engineeringverslag had ongeveer 35 minuten nodig: review, imagebouw en end-to-endtests. Tijdens die periode hoefde de ontwikkelaar alleen de pull request samen te voegen en later de productie-uitrol te starten. Dat cijfer is een interne waarneming uit de beschreven workflow, geen algemene CI/CD-benchmark.
De nuttigste les is daarom niet dat ieder bedrijf een Slackbot moet bouwen. Een eigen automatisering verdient het onderhoud pas wanneer ze meerdere dagelijkse overdrachten uit één proces haalt en het team de verantwoordelijkheid voor die laag ook echt wil dragen.
