En CI/CD-pipeline på 45 minuter kostar mer än ni tror: kontextbyten, väntan och tappad flow. Här är den systematiska metoden vi använder för att få ner build-tider - med konkreta åtgärder och vad var och en gav.
En pipeline som tar 45 minuter känns inte som ett akut problem - den fungerar ju. Men räkna: tio utvecklare som väntar på pipelinen flera gånger om dagen tappar tillsammans timmar, varje dag. Och det verkliga priset är inte minuterna, utan kontextbytena. Här är hur vi tog en pipeline från 45 till 8 minuter, steg för steg.
Mät först - gissa aldrig
Den första regeln i all optimering: mät innan du rör något. Vi instrumenterade pipelinen och delade upp de 45 minuterna per steg. Fördelningen var avslöjande:
- Dependency-install: 12 min - ingen caching.
- Tester: 18 min - kördes seriellt, ett test-suite i taget.
- Build: 9 min - byggde om allt, varje gång.
- Deploy + diverse: 6 min.
Utan den här uppdelningen hade vi gissat - och förmodligen optimerat fel sak. Pareto styr: 67 % av tiden låg i install och tester.
Vinst 1: Caching av dependencies (12 → 1 min)
Den enklaste vinsten. Pipelinen laddade ner och installerade alla beroenden från noll vid varje körning. Med korrekt cache-nyckel (baserad på lockfilen) hämtas de bara om när beroenden faktiskt ändras. 11 minuter sparade på en konfigurationsändring.
Vinst 2: Parallellisera testerna (18 → 6 min)
Testerna kördes seriellt. Moderna test-runners (vi använde sharding) delar upp suiten över flera parallella jobb. Med fyra shards gick 18 minuter till runt 6. Här ligger ofta den största enskilda vinsten - och den kräver noll ändring i själva testerna.
Vinst 3: Inkrementell build (9 → 3 min)
Byggsystemet byggde om hela monorepot även när bara ett paket ändrats. Med ett build-system som förstår beroendegrafen (Turborepo i det här fallet) plus remote caching byggs bara det som faktiskt påverkats. Oförändrade paket hämtas från cachen.
Vinst 4: Rätt ordning och fail-fast
Sist flyttade vi de snabbaste, mest sannolika att fela stegen (lint, typecheck) först - så att en trasig commit faller på 30 sekunder i stället för efter 8 minuter. Det sänker inte den gröna pipelinens tid, men det sänker den genomsnittliga tiden till feedback dramatiskt.
Resultatet - och varför det spelar roll
45 → 8 minuter. Men den verkliga vinsten syntes i beteendet: när pipelinen blev snabb började teamet deploya oftare och i mindre steg. Mindre deploys = mindre risk per deploy = färre incidenter. Snabb CI är inte en bekvämlighet, det är en säkerhetsmekanism.
Vanligaste misstaget
Att optimera build-steget först för att det "känns" tungt. Mät. Nästan alltid ligger den enklaste vinsten i caching och parallellisering av tester - inte i bygget.
“Snabb CI är inte en bekvämlighet, det är en säkerhetsmekanism. När pipelinen blev snabb deployade teamet oftare och i mindre steg - färre incidenter blev följden.”
- Simon Axelsson
Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.
Fler artiklar
