Vad är Trunk-Based Development? En Guide för DevOps Teams
Summary
Trunk-based development är en branching-strategi där varje utvecklare integrerar kod till main dagligen utan långa feature branches. I stället för isolering använder team feature flags för att dölja opublicerad kod från slutanvändare. Elite-presterande team enligt DORA-forskning deployar flera gånger per dag med denna metod. Det minskar merge-konflikter, ökar deployment-frekvens, förbättrar kodkvalitet och möjliggör snabb rollback genom att enkelt slå av feature flags.
Vad är trunk-based development? Det är en branching-strategi där varje utvecklare mergar till en enda delad branch, oftast kallad main eller trunk, minst en gång per dag. Det finns inga långlivade feature branches. Koden är i produktionsklar tillstånd hela tiden. Om en funktion inte är klar skyddar en feature flag den från användare, inte en branch som isolerar den från teamet.
Det var den korta versionen. Den längre versionen handlar om varför ditt nuvarande arbetsflöde kan generera mer risk än du inser.
Varför långlivade branches blir en börda
De flesta team lär sig versionskontroll genom feature branches: en branch per ticket, merga efter granskning. Det känns organiserat.
När en branch lever mer än 24 timmar är varje commit dina kollegor gör till main en framtida konflikt du inte har sett än. I ett team på åtta utvecklare där var och en håller en två veckor lång branch kör du inte en integration. Du hanterar åtta parallella världar som divergerar lite mer varje dag. Merge-dagen är inte en uppgift. Det är en förhandling.
DORA-forskningen, den största longitudinella studien av prestanda för mjukvaruexpeditionen genomförd över tusentals team, drar en hård gräns här: branches som lever längre än 24 timmar är en prediktiv signal för lägre deployment-frekvens och högre förändringsfelsfrekvenser. Elite-presterande team integrerar flera gånger om dagen. Resten mergar när funktionen är "klar", vilket ofta betyder aldrig rent.
Den dolda kostnaden är inte själva merge-konflikten. Det är kontextbyte som krävs för att lösa det tre veckor efter att koden skrevs. Ingen kommer ihåg vad avsikten var.
Hur trunk-based development faktiskt fungerar
Mekaniken är enkel. Du pullar main. Du gör en liten, sammanhängande förändring. Du kör testsviten. Du pushar till main. Allt detta händer före lunch.
För en solo-bidragsgivare i ett litet repo fungerar det redan så här. För ett team på tjugo i ett 300K-LOC monorepo krävs tre praktiker som fungerar tillsammans:
Kortlivade branches (valfritt men vanligt): Vissa team tillåter branches upp till två dagar innan de tvingas merga. Detta bevarar granskningskultur utan att skapa multi-vecka divergens. Branchen är ett granskningsmedel, inte en isoleringskäl.
Kontinuerlig integration vid varje push: Varje commit till main utlöser en fullständig build och testsvit. Om det går sönder går det sönder på minuter, inte efter en två veckor lång feature branch landar fredags 16.
Feature flags för ofullständigt arbete: Oavslutade funktioner skeppas till produktion bakom en flagga. Användare ser ingenting. Teamet integrerar allt. Det här är delen de flesta team hoppas över, vilket är varför deras första TBD-experiment misslyckas.
Ingen av dessa praktiker är exklusiv för trunk-based development. Skillnaden är att TBD gör alla tre obligatoriska snarare än valfria.
Feature flags: mekanismen som gör TBD möjlig
En feature flag är ett villkor i din kod som utvärderas vid körning. När en flagga är av körs den nya kodvägen inte. När den är på, för en specifik användare, en procentandel av trafiken, eller hela användarbasen, gör den det.
Det låter trivialt. Implikationen är det inte: du kan separera deployment från release. Koden skeppas till produktion kontinuerligt. Funktioner lanseras när de är klara, eller inte alls om rollout går fel och du behöver döda det på tio sekunder snarare än rulla tillbaka tre veckors commits.
Minimumet för livskraftig setup kräver tre saker: ett sätt att definiera flaggor, ett sätt att utvärdera dem vid körning och ett sätt att ändra dem utan att deployera om. En platt JSON-konfigfil fungerar för ett team på tre. En dedikerad feature management-tjänst tjänar sin komplexitet någonstans omkring tio utvecklare eller när flaggor börjar behöva riktningsregler som "aktiverad för användare i betakohorten i Tyskland".
En sak att spåra: flagg-skuld. Flaggor som aldrig rengörs efter att funktionen skeppas blir betingat spagetti. Ett team som kör TBD korrekt pensionerar varje flagga inom en sprint från att funktionen helt har rullats ut. Behandla flaggor som tillfällig stödverkning, inte permanent konfiguration.
TBD vs Gitflow: en direkt jämförelse för 2026
Gitflow designades 2010 för boxad programvara skeppad på ett kvartalsvis cykel. Det modellerar utgåvor som långlivade branches. För team som deployar varje dag eller varje timme kartlägger den modellen inte längre.
Här är hur jämförelsen ser ut för ett team som kör CI/CD:
Branch-livslängd: Gitflow kör dagar till veckor. TBD kör timmar till max 1-2 dagar.
Merge-konflikter: Gitflow producerar ofta, högseveritets-konflikter. TBD producerar sällsynta, lågseveritets-konflikter eftersom integrationsgap är timmar, inte veckor.
Deploy-frekvens: Gitflow knyter distribution till en release branch. TBD separerar distribution från release helt.
Rollback-mekanism: Gitflow rullar tillbaka genom att verta en branch-merge. TBD rullar tillbaka genom att stänga av en feature flag.
Onboarding-komplexitet: Gitflow kräver att förstå develop/main/hotfix-konventioner. TBD har en branch: main.
Erforderlig CI-investering: Gitflow är låg (branches absorberar risken). TBD är höga (main måste hålla grön hela tiden).
Gitflow är inte fel i varje sammanhang. Om du skeppat en mobil app till en App Store och inte kan push hotfixes på minuter är en release branch-modell vettig. Om du kör en SaaS där du kontrollerar deployments är den extra branchstrukturen overhead som lägger till samordningskostnad utan att lägga till säkerhet.
Vad DORA-metriker säger om branching-strategier
DORA State of DevOps-forskningen har spårat prestanda för mjukvaruexpeditionen sedan 2014. Två fynd från data är direkt relevanta här.
Först är trunk-based development en av de 24 funktionerna som förutsäger prestanda för mjukvaruexpeditionen i DORA-modellen. Det sitter under "continuous delivery"-klustret, vilket betyder DORA behandlar det som infrastrukturpraxis, inte teampreferens.
För det andra deployar elite-presterande team flera gånger om dagen. Låga presterare deployar en gång per vecka eller en gång per månad. Långlivade branches och sällan integration dyker upp i den långsammare änden av den fördelningen över flera år av data.
Vad forskningen inte hävdar: att TBD orsakar elite-prestanda. Team som antar TBD framgångsrikt tenderar redan att ha automatiserad testning, en arbetande CI-pipeline och en vana att skapa små commits. Trunk-based development avslöjar dessa luckor omedelbar om de saknas. Ett team utan CI och 40% testbristfällighet kommer inte att dra nytta av att byta till TBD. De kommer bara att bryta main oftare.
Där trunk-based development slutar bli vettig
Tre scenarier där TBD skapar mer problem än det löser:
Starkt reglerade miljöer med obligatoriska godkännandegrindar före release: Om varje release behöver ett compliance-godkännande före skeppning är kontinuerlig distribution till produktion blockerad ändå. Branching-modellen blir sekundär. Du kommer att batch-ändringar oavsett branching-strategi.
Under-kraftiga testsviter: TBD kräver en snabb, tillförlitlig CI-pipeline. Om builds tar 45 minuter och har 20% brisflällighet kommer utvecklare att batch-commits för att undvika att vänta. Det motverkar modellen. Begränsningen är testinfrastrukturen, inte branching-konventionen.
Mycket stora team med inkonsistent kodägande: I team på 50+ där varje skild service ägs av ett distinktvyskilda team fungerar TBD väl på servicenivå. Att tillämpa det över ett delat monorepo där alla rör allting kräver strikt lintning-konventioner och CI-ägarskapsregler för att hålla main ren.
I alla tre fall är fixet inte en annan branching-strategi. Fixet är det underliggande infrastrukturproblemet. TBD gör bara det problemet synligt snabbare.
Hur du migrerar utan att stoppa leveranser
Migreringen de flesta team gör fel: de annonserar TBD, raderar feature branch-konventionen och ser main bryta i första veckan.
En säkrare väg:
Behåll befintliga branches, lägg till en livslängdsregel: Ingen branch lever mer än 3 dagar. Detta tvingar trycket av frekvent integration utan att stänga av ljusen.
Instrumentera din CI först: Innan merging går snabbt måste merging vara säkert. Se till att testsviten är grön, körs på mindre än 15 minuter och blockerar main-branchen vid fel.
Plocka en funktion att grind med en flagga: Bygg feature flag-muskelminne innan du behöver det för varje ofullständig funktion.
Krympa branch-livslängd vecka för vecka: Från 3 dagar till 2 dagar till 1 dag över sex veckor. Spåra merge-konfliktfrekvens som en ledande indikator. När det sjunker fungerar modellen.
Dra tillbaka den gamla konventionen bara när den nya fungerar: Gitflow-konventioner stannar på plats för allt utanför piloten. Att köra båda modellerna i 6-8 veckor är okej.
Vanorna som förutsäger om TBD kommer att hålla
Trunk-based development misslyckas inte för att team inte kan merga till main. Det misslyckas för att utvecklare inte har vanor att begränsa arbete litet nog för att leverera på en dag.
Den underliggande förskjutningen är inte teknisk. Det är hur arbete definieras i planering. En historia som säger "implementera det nya betalningsflödet" är en två veckor lång branch i väntan. En historia som säger "lägg till väghanteraren och returnera 501 bakom flagga payment-v2" är ett halvdags-commit.
Det här kräver PM-inblandning och backlog-hygien som de flesta team inte har byggd. Branching-strategi ändringen tar en dag att annonsera. Omfattningsväxlingen tar sex månader att bygga.
Om ditt team redan levererar fungerande programvara till produktion dagligen formaliserar TBD vad du redan gör. Om ditt team levererar var två vecka med en stor-knall-merge i slutet kommer TBD inte att vara bekvämt tills leverans-vanorna under det ändras.
Team som håller fast vid TBD är de som investerade i tre saker innan bytet: en sub-15-minuters CI-pipeline, en fungerande feature flag-tjänst och sprint-ceremonier som producerar historier små nog att stänga inom en dag. Utan dessa tre är branching-konventionen den felaktiga spaken.
Verktyg som hjälper team att köra TBD-arbetsflöden
Att köra trunk-based development på teamnivå betyder mer synkron inriktning: snabba standups för att fånga integrationsdrift, dokumenterade konventioner för flaggor och CI-regler, och samtal för parpgranskning på kritiska vägar.