Ett team vi arbetar med ville släppa snabbare. En rimlig ambition, och den vanliga reflexen är att köpa något som hjälper utvecklare skriva kod snabbare.
Så innan vi ändrade något kartlade vi var en ändring faktiskt tillbringar sitt liv, från första commit till drift i produktion. Det mesta av det livet var väntan. Väntan på en granskare med tid, eftersom alla som var seniora nog att granska var upptagna med eget arbete. Väntan på tester, som tenderade att skrivas efter granskningen i stället för före. Väntan på nästa releasefönster, eftersom releaser var manuella nog att behöva schemaläggas.
Skrivandet var aldrig den långsamma delen. Kön var det.
Vad vi ändrade
När man väl ser det som ett köproblem skriver inköpslistan sig själv: placera hjälpen där arbetet väntar, och låt tangentbordet vara.
GitHub Copilot i editorn fanns redan, och ärligt talat är det den minst intressanta delen av den här historien. Det gör skrivandet snabbare, och skrivandet gick redan snabbt.
Claude granskar varje pull request först. Det är förändringen som betalade för allt annat. I samma stund som en pull request öppnas läser Claude Fable diffen och lämnar kommentarer: den ohanterade nullen, det nedsvalda undantaget, funktionen som kopierats och redigerats till hälften. Den godkänner ingenting. När en mänsklig granskare öppnar pull requesten är det lagret redan avklarat, så hen kan börja där omdömet spelar roll: vid designen. Granskning gick från en syssla folk sköt upp till en kort uppgift de får in mellan annat, och kön framför den krympte i motsvarande grad.
Playwright-tester utkastade från diffen. Testsviten var tunnast precis där produkten ändrades mest, som det brukar bli. Nu går diffen och teamets speckonventioner till en modell när en pull request öppnas, och den skissar Playwright-tester för de vägar som ändrats. En hel del redigeras före merge och en del kastas. Det är i sin ordning. Att skissa var delen ingen ville göra, och den kostar nu ingenting, så täckningen växer där produkten rör sig. Regressioner fångas i CI i stället för i ett supportärende.
Dependabot och CodeQL, påslagna på en eftermiddag. Inbyggt i GitHub, ingen ny leverantör, ingen glans. En snabbare pipeline levererar också misstag snabbare, och dessa två fångar en hel kategori av dem utan att någon behöver vara skärpt en fredag.
GitHub Actions kör releasen. Byggen låg tidigare i Azure DevOps, och teamet konsoliderade ändå på GitHub. Med granskning, tester, skanning och driftsättning på ett ställe finns ett enda spårbarhetsunderlag. Det underlaget väger tyngre när en modell deltar, eftersom man vill kunna svara exakt på vad som kördes och vilken person som godkände.
Håll mergen mänsklig
En modell kan här skriva kod, granska kod och skissa tester. Den kan inte godkänna en pull request och den kan inte driftsätta. Det är framtvingat som en behörighet i repot, så det hänger inte på någons disciplin under en hektisk vecka.
Allt före mergen är ett utkast, och utkast är billiga att ha fel. Allt efter mergen är produktion. Att hålla gränsen där betyder att snabbheten landar där misstag går att återställa, och att varje release fortfarande går att spåra till en namngiven ingenjör som sa ja. När säkerhet eller en revisor frågar vem som godkände finns det ett namn.
Resultatet
Releaser slutade vara händelser. De gick från ett schemalagt tillfälle till något som sker flera gånger i veckan, när en ändring är klar snarare än när kalendern säger till.
Kvaliteten rörde sig åt samma håll, vilket överraskade de som väntade sig en avvägning. Fler regressioner dör i CI eftersom testerna nu finns, och rollbacks har blivit sällsynta.
Och förändringen ingen förutsåg: granskning slutade vara jobbet alla sparade till slutet av dagen. Kortare, mer intressanta uppgifter plockas upp tidigare. En rejäl del av takthöjningen ligger antagligen just där.
Hur ni kommer igång
Mät var en ändring väntar innan ni köper något. Om granskningslatens är er flaskhals hjälper snabbare skrivande inte. Börja med AI-granskning, eftersom den är billig att pröva, lätt att stänga av, och en människa läser utdata ändå. Låt en modell skissa era tester, och behandla utkasten som utkast. Och gör mergen till en mänsklig behörighet från dag ett, för det är den gränsen som låter er säga ja till allt annat.
Det finns ingen universallösning för molnet. Därför möter vi er där ni är.
