Een team waarmee we werken wilde sneller releasen. Een terechte ambitie, en de gebruikelijke reflex is iets kopen dat ontwikkelaars helpt sneller code te schrijven.
Dus voordat we iets veranderden, brachten we in kaart waar een wijziging haar leven doorbracht, van eerste commit tot draaiend in productie. Het grootste deel van dat leven was wachten. Wachten op een reviewer met tijd, omdat iedereen die senior genoeg was om te reviewen bezig was met eigen werk. Wachten op tests, die meestal na de review werden geschreven in plaats van ervoor. Wachten op het volgende releasevenster, omdat releasen handmatig genoeg was om ingepland te moeten worden.
Het schrijven was nooit het trage deel. De wachtrij was dat.
Wat we hebben veranderd
Zodra je het als een wachtrijprobleem ziet, schrijft het boodschappenlijstje zichzelf: zet hulp neer waar het werk wacht, en laat het toetsenbord met rust.
GitHub Copilot in de editor was er al, en eerlijk gezegd is dat het minst interessante deel van dit verhaal. Het maakt het schrijven sneller, en het schrijven ging al snel.
Claude reviewt elke pull request als eerste. Dit is de verandering die al het andere heeft terugverdiend. Op het moment dat een pull request opent, leest Claude Fable de diff en plaatst opmerkingen: de niet-afgevangen null, de ingeslikte exception, de functie die is gekopieerd en half aangepast. Het keurt niets goed. Tegen de tijd dat een menselijke reviewer de pull request opent, is die laag al afgehandeld, zodat die kan beginnen waar zijn oordeel telt: bij het ontwerp. Reviewen ging van een klus die mensen uitstelden naar een korte taak die ze tussendoor doen, en de wachtrij ervoor kromp navenant.
Playwright-tests opgesteld vanuit de diff. De testsuite was precies daar het dunst waar het product het meest veranderde, zoals dat meestal gaat. Nu gaan de diff en de specconventies van het team naar een model zodra een pull request opent, en dat stelt Playwright-tests op voor de paden die zijn veranderd. Een flink deel wordt bijgewerkt voor de merge en sommige gaan de prullenbak in. Dat is prima. Het opstellen was het deel dat niemand wilde doen, en het kost nu niets, dus dekking groeit waar het product beweegt. Regressies worden in CI gevangen in plaats van in een supportticket.
Dependabot en CodeQL, in een middag aangezet. Native GitHub, geen nieuwe leverancier, geen glamour. Een snellere pipeline levert ook sneller fouten op, en deze twee vangen een hele categorie daarvan af zonder dat iemand op een vrijdag scherp hoeft te zijn.
GitHub Actions voert de release uit. Builds draaiden eerst in Azure DevOps, en het team consolideerde toch al op GitHub. Met review, tests, scanning en deployment op één plek is er één audittrail. Die trail telt zwaarder zodra een model meedoet, want je wilt precies kunnen beantwoorden wat er heeft gedraaid en welke persoon heeft goedgekeurd.
Houd de merge menselijk
Een model kan hier code schrijven, code reviewen en tests opstellen. Het kan geen pull request goedkeuren en het kan niet deployen. Dat is afgedwongen als repositorypermissie, dus het hangt niet af van iemands discipline in een drukke week.
Alles voor de merge is een concept, en concepten zijn goedkoop om fout te hebben. Alles na de merge is productie. Die grens vasthouden betekent dat de snelheid landt waar fouten herstelbaar zijn, en dat elke release nog steeds terug te voeren is op een engineer met naam die ja heeft gezegd. Als security of een auditor vraagt wie heeft getekend, is er een naam.
Het resultaat
Releases zijn opgehouden gebeurtenissen te zijn. Ze gingen van een ingeplande gelegenheid naar iets dat meerdere keren per week gebeurt, wanneer een wijziging klaar is in plaats van wanneer de kalender het zegt.
Kwaliteit bewoog dezelfde kant op, wat de mensen verraste die een uitruil verwachtten. Meer regressies sneuvelen in CI omdat de tests nu bestaan, en rollbacks zijn zeldzaam geworden.
En de verandering die niemand had voorspeld: reviewen was niet langer de klus die iedereen voor het eind van de dag bewaarde. Kortere, interessantere taken worden eerder opgepakt. Een flink deel van de tempowinst zit waarschijnlijk gewoon daarin.
Hoe te beginnen
Meet waar een wijziging wacht voordat u iets koopt. Als reviewlatentie uw knelpunt is, raakt sneller typen dat niet. Begin met AI-review, omdat het goedkoop is om te proberen, makkelijk uit te zetten, en een mens leest de uitvoer toch. Laat een model uw tests opstellen, en behandel de concepten als concepten. En maak de merge vanaf dag één een menselijke permissie, want die grens is wat u in staat stelt op al het andere ja te zeggen.
Er is geen eenheidsaanpak voor de cloud. Daarom sluiten we aan waar u nu staat.
