Vad är trunk based development? En komplett guide för team

Vad ar trunk based development? Alla utvecklare i teamet committar kod till en enda gemensam gren - vanligen kallad main - minst en gång om dagen. Inga långlivade feature-grenar. Kortlivade grenar lever i timmar, mergas snabbt och raderas. Kodbasen är alltid i ett releasbart skick. Google kör 35 000 utvecklare på det här sättet. Här är hur det fungerar, när det passar och när det inte gör det.

Problemet med rapport_v2_FINAL_use_this_one.xlsx - fast för kod

Har du någonsin öppnat en delad mapp och hittat rapport_v1.xlsx, rapport_v2_FINAL.xlsx och rapport_ANVAND_DENNA_greg_andringar.xlsx sida vid sida? Då förstår du redan exakt vilken smärta trunk-based development försöker lösa.

Den situationen uppstår i kodbaser när team använder långlivade feature-grenar. Någon startar en feature i vecka ett. Resten av teamet fortsätter att shipa. I vecka tre ligger den grenen dussintals commits efter main. Att merga den blir ett helgprojekt som ingen vill äga. Konflikter hopar sig. Utvecklaren som skrev koden har glömt varför hälften av den finns. Det kallas merge-helvetet.

Gitflow - det mest undervisade alternativet - löser detta med formell struktur: separata grenar för features, releaser och hotfixar, var och en med en definierad livstid. Strukturen ser ren ut på papper. I praktiken samlas grenar som kalkylbladsversioner på en delad server, och integrationsdagen förvandlas till integrationsveckan.

Trunk-based development tar den motsatta ståndpunkten: sluta samla på integrationsskuld. Committa till main. Idag.

Alla committar till main varje dag - det är hela modellen

Kärnregeln är rakt på sak: alla utvecklare pushar ändringar till main minst en gång var 24:e timme. Inga undantag för "jag är inte klar" - du committar det du har och ser till att det inte bryter bygget.

Det låter alarmerande tills du förstår mekanismerna som gör det säkert:

• Kortlivade grenar: Du kan fortfarande använda grenar, men de lever i timmar, inte veckor. En gren som är mer än två dagar gammal är ett varningssignal värt att undersöka.

• Automatiserad testning vid varje commit: Din CI-pipeline kör testsviten omedelbart. Om något går sönder vet du det inom minuter, inte vid sprintens slut.

• Feature flags: Halvfärdiga features döljs bakom en toggle tills de är redo att shippa. Användarna ser aldrig ofärdigt arbete, även om det redan finns i produktionskoden.

Resultatet är en kodbas som alltid är releasbar - inte releasbar efter att vi mergat feature-grenen och kört QA i en vecka, utan releasbar just nu om det behövs. Det är det grundläggande löftet.

Kortlivade grenar: mät dem i timmar, inte veckor

I trunk-based development är du inte förbjuden från grenar. Du är förbjuden från långa grenar.

En gren du öppnar kl 9, jobbar på under förmiddagen, låter granskas efter lunch och mergar till main innan kl 17 är precis rätt typ. Den ger kollegorna chansen att granska arbetet innan det hamnar på main. Den är liten nog att förstå i en enda genomläsning. Konflikter, om sådana finns, löser sig på minuter.

En gren som lever tre veckor medan en enskild utvecklare bygger ett helt autentiseringssystem i isolering är problemet. När det äntligen är dags att merga spenderar teamet mer tid på att lösa konflikter än på att bygga den faktiska funktionen.

Den praktiska gränsen de flesta trunk-based team använder: om en gren inte har mergats inom två dagar behöver något förändras. Antingen är funktionen för stor och behöver delas upp i mindre delar, eller behöver den en feature flag så att partiellt arbete kan landa säkert.

Att dela upp arbete i mindre bitar är kärnkompetensen som trunk-based development faktiskt odlar. Istället för "bygg hela dashboarden" shippar du "lägg till datalagret", sedan "lägg till det första diagrammet", sedan "koppla filtren". Varje del mergas till main, testas och shippar oberoende. Den fullständiga funktionen framträder inkrementellt över flera commits.

Det låter långsammare. I praktiken är det snabbare, för du hittar problem medan kontexten är färsk och ytan fortfarande är liten.

Jämför det med det alternativa scenariot: en stor feature-gren med tre veckors arbete som ska mergas. Varje dag som går ökar risken för att konflikterna ska bli omöjliga att lösa utan att förstöra något. Kontexten är urblekt. Det som borde vara en rutinmässig operation förvandlas till en forensisk utredning av vems kod som har rätt.

Feature flags: hur du shippar ofärdig kod utan att krasha något

Feature flags - också kallade feature toggles - är mekanismen som gör trunk-based development praktiskt när en funktion inte kan färdigställas i en enda kortlivad gren.

Idén är enkel: omslut ny funktionalitet i ett villkor som bara aktiveras när en specifik flagga är påslagen.

if (featureFlags.newReportingDashboard) {
  renderNewDashboard();
} else {
  renderOldDashboard();
}

Den nya koden är driftsatt i produktion. Den körs bara inte för användare förrän du flippar togglen. Det innebär:

• Utvecklare kan committa pågående arbete till main utan att det påverkar någon

• QA kan testa funktionen i produktion genom att aktivera flaggan för en specifik användare eller miljö

• En lansering blir en konfigurationsändring, inte en deployment-händelse

• Om något går sönder stänger du av flaggan utan rollback eller hotfix-gren

Feature flag-infrastruktur skalas från en enkel miljövariabel som kontrolleras vid uppstart till dedikerade feature flag-plattformar. För ett team som precis börjat räcker en konfigurationsfil eller per-miljö-variabel. Poängen är kapaciteten, inte verktygskomplexiteten.

När trunk-based development inte är rätt val

Trunk-based development är inte universellt bättre. Det passar specifika sammanhang.

Hoppa över det om:

Din CI/CD-pipeline inte är redo. TBD utan automatiserade tester vid varje commit är ingen förgreningsstrategi - det är en trasig kodbas som samlar fel i snabb takt. Testinfrastrukturen måste vara på plats innan förgreningsmodellen kan fungera.

Teamet inte kan committa frekvent av naturen. Distribuerade team med asynkrona bidragsgivare över tidszoner, eller open source-projekt med ovanliga inlämningsbatchar, kommer att kämpa med den dagliga commit-takten.

Du är i en reglerad miljö med obligatoriska releasefönster. Vissa branscher kräver externt godkännande, långa QA-cykler och formella revisionsspår per releasegren. Gitflows strukturerade releasegrenar passar bättre den typen av arbetsflöde.

Teamdisciplinen inte är på plats ännu. TBD kräver att varje commit till main antingen passerar alla tester eller åtgärdas omedelbart. Om ditt team tolererar trasiga byggen blir den gemensamma main-grenen allas gemensamma problem.

Gitflow är ett rimligt val för team med kvartalsvisa releasescheman, flera parallella features som utvecklas av separata squads, eller efterlevnadskrav som kräver grenbaserad isolering. Frågan är ärlig matchning, inte vilket tillvägagångssätt som vinner i princip.

Hur du byter från Gitflow till trunk-based development utan kris

Om ditt team är på Gitflow och vill prova trunk-based development behöver migreringen inte vara en hård övergång.

Börja med att sluta skapa nya långlivade grenar. Features som startas efter beslutet får kortlivade grenar. Features som redan pågår på långa grenar avslutas under den gamla modellen. De två tillvägagångssätten samexisterar tillfälligt.

Innan du committar ofärdigt arbete till main behöver du feature flags på plats. Att sätta upp ens ett grundläggande feature flag-system är förutsättningen för allt annat. Utan det innebär TBD att du shippar ofärdig UI till produktionsanvändare.

Inför sedan CI på main-grenen: automatiserade tester körs vid varje push, misslyckade tester blockerar mergen och ingen mergar utan ett godkänt bygge. Det är den icke-förhandlingsbara delen.

Definiera slutligen tvådagarsregeln explicit: varje gren äldre än två dagar får ett samtal om vad man ska göra med den. Dela funktionen i mindre bitar, lägg till en flagga eller shipa det som redan är klart. Gör detta synligt i din pull request-process.

Den obekväma justeringen de flesta team möter: att acceptera att delvis färdigt är en giltig sak att committa, så länge det är dolt bakom en flagga och inte bryter befintliga tester.

Vad DORA-rapporten säger om leveranshastighet

DORA-rapporterna (DevOps Research and Assessment) är det närmaste mjukvaruutveckling har storskalig empirisk forskning om teampraxis. 2021 års DORA-rapport visade att elitpresterande team är 2,3 gånger mer benägna att använda trunk-based development jämfört med lägre presterande team.

Elitpresterare i DORA-ramverket deployar flera gånger om dagen, med ledtider från commit till produktion mätta i timmar snarare än veckor. Trunk-based development korrelerar konsekvent med dessa utfall.

Det viktiga förbehållet: korrelation är inte kausalitet. Högpresterande team antar TBD för att de redan har investerat i den underliggande disciplinen - automatiserad testning, solid CI/CD-infrastruktur, ingenjörer som skriver små, fokuserade ändringar. De grunderna kommer först. TBD är förgreningsmodellen som passar det sammanhanget, inte det som skapar det.

Biscuit listar ut det här snabbt: en bra retriever försöker inte bära tre bollar på en gång. En commit, en granskning, en merge. Good boy.

Är trunk-based development värt att byta till?

Om ditt team spenderar meningsfull tid varje sprint på merge-konflikter, försenar releaser för att "feature-grenen inte är klar", eller har grenar öppna så länge att ingen minns vad de var till för - är trunk-based development värt en seriös utvärdering.

Den dagliga commit-takten är krävande. Feature flag-infrastrukturen kräver setup. Det kulturella skiftet tar några veckor. Men resultatet - en kodbas som alltid är releasbar, merge-konflikter mätta i rader inte filer, och releaser som är rutinmässiga snarare än kriser - är en meningsfull förbättring av hur teamet arbetar.

Börja smått: ett team, en sprint, CI som körs vid varje push och feature flags på plats. Se vad som förändras på fyra veckor.