# Vad är trunk based development? En operativ guide för SRE URL: https://upstreamapi.com/sv/journal/vad-ar-trunk-based-development Type: blog Locale: sv Published: 2026-10-10 Updated: 2026-10-10 --- > Trunk based development innebär att alla integrerar små ändringar i en delad branch varje dag. Så fungerar modellen, vad den kräver och när den är fel val. Klockan är tre på natten och release-branchen går inte att merga. Fyrtio commits, tre veckor gamla, som rör samma filer som main. Den smärtan är själva argumentet för trunk based development. Men vad är trunk based development, exakt? Det är en branch-modell där alla slår ihop små ändringar i en gemensam branch, kallad trunk eller main, minst en gång om dagen, och där den branchen hålls byggbar och redo att släppas hela tiden. Den här guiden riktar sig till plattformsingenjörer som redan kan Git. Den går igenom vad modellen kräver, vad den skyddar dig från och var den tyst brister. ## Vad är trunk based development, i praktiken? Plockar du isär definitionen får du fyra begränsningar. Alla utvecklare integrerar i en enda branch. Övriga branches lever i timmar, inte veckor. Trunken bygger och klarar testerna vid varje commit, så att den kan shippas när som helst. [DORA:s sida om trunk based development](https://dora.dev/capabilities/trunk-based-development/) sätter siffror på det: högst tre aktiva branches i repot, merge till trunk minst en gång per dag, inga kodfrysningar och en build- och testcykel som tar några minuter. Siffrorna är poängen. Modellen är en budget för återkopplingsslingor, inte en preferens för hur branches namnges. ![En mörk skrivbordsyta på natten med en laptop-terminal och en upplyst telefonnotis](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/6d43db-i1.webp) Små team committar ibland direkt till trunk. Större team använder kortlivade branches och pull requests för granskning och byggkontroller, men aldrig för att hålla tillbaka arbete från integration. [trunkbaseddevelopment.com](https://trunkbaseddevelopment.com/) beskriver båda varianterna och nämner Google, som kör cirka 35 000 utvecklare på en enda trunk i en monorepo. ## Varför långlivade brancher faller på ett förutsägbart sätt En feature-branch är ett lån. Räntan är merge-konflikter, och den växer för varje commit som landar på main medan du är borta. Ju längre branchen lever, desto större blir diffen, och ju större diffen är, desto mindre noggrant läser någon den. Så här påverkar det din change failure rate. En merge på 2 000 rader får en snabb blick och ett godkännande. En merge på 60 rader blir faktiskt läst. Granskare är inte slarviga, de rationerar uppmärksamhet. Små batchar är den enda mekanismen som skalar granskningskvalitet. Den andra kostnaden syns inte förrän vid release. Två brancher som båda går igenom CI kan ändå sabba varandra när de möts. Du upptäcker det vid integrationen, i värsta möjliga ögonblick och med en deadline bifogad. Att flytta till trunk utan stödjande rutiner är så team hamnar tillbaka i feature-branches inom ett kvartal. Fyra saker måste finnas på plats först: - En build och en testkörning som tar under cirka tio minuter. Tar CI 40 minuter batchar utvecklarna ändringar, och batchning slår ut hela modellen. - Tester som fallerar av riktiga skäl. En flaky svit lär folk att köra om och merga ändå. - En snabb och ärlig granskningsprocess. DORA listar tung och asynkron kodgranskning som ett vanligt hinder, eftersom den tvingar fram batchning. - Ett säkert sätt att skicka ofärdigt arbete. Det är nästa avsnitt. Hoppar du över något av dessa blir trunken platsen där fel ackumuleras, i stället för platsen där fel fångas. Det här syns tydligast vid en incident. Om en merge från i förmiddags ger en felspik klockan tre måste någon kunna avgöra på under en minut om ändringen är skyldig, och sedan återställa den utan att öppna tre repos och en pull request. Har du inte den rutinen är trunk based development bara ett snabbare sätt att skicka trasiga saker. ## Hur merger du ofärdigt arbete utan att skicka det? Det här är frågan varje skeptiker ställer, och svaret är tråkigt: du frikopplar deploy från release. Koden når produktion i mörker. En flagga avgör vem som ser den. `// checkout.ts import { flags } from "./flags"; export async function renderCheckout(user: User) { if (await flags.isEnabled("new-payment-flow", { userId: user.id })) { return renderNewPaymentFlow(user); // mergad till trunk, avslagen som standard } return renderLegacyCheckout(user); }`Det nya flödet mergas första dagen, bakom en flagga som är avslagen. Du slår på den för interna användare, sedan för 1 procent, sedan 10, med en SLO-gate vid varje steg. Om felfrekvensen passerar budgeten stängs flaggan av och ändringen är i praktiken återställd utan deploy. Team som utvärderar hostade flagg-tjänster börjar ofta med LaunchDarkly, men mönstret fungerar med vilken leverantör som helst eller med en egen config-store. Den andra tekniken är branch by abstraction, för stora refaktoreringar. Du inför ett interface, låter anropare gå genom det, bygger den nya implementationen bakom det och byter när den är redo. Ingen långlivad branch, ingen big-bang-merge. ![En rad vägbrytare, några på och några av, som feature flags](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/81ea3c-i3.webp) ## Den ärliga kostnaden: flaggor är skuld med halveringstid Ingen på konferenskretsen vill prata om det här. Varje flagga du lägger till är en villkorssats i produktion som någon måste ta bort. Vi har sett team på 80 ingenjörer bära flera hundra gamla flaggor, var och en en gren i koden som ingen kan testa uttömmande. Behandla flaggor som kortlivade per kontrakt. Ge varje flagga en ägare och ett utgångsdatum när den skapas. Larma på flaggor som är äldre än sitt utgångsdatum. Ta bort den döda kodvägen i samma pull request som tar bort flaggan. Kombinatorisk risk finns också. Tio oberoende boolska flaggor ger 1 024 möjliga konfigurationer, och du kommer aldrig att testa alla. Håll antalet flagg-interaktioner lågt, och håll release-flaggor åtskilda från långlivade driftsbrytare som kill switches. ## Releasestrategier ovanpå trunken Det finns två vanliga sätt att skära en release från trunk, och inget av dem kräver en långlivad branch. - Release direkt från trunk. Varje grön commit är en kandidat. Buggar åtgärdas framåt, med en ny commit, inte genom att patcha en gammal branch. Det passar team med starka automatiska tester och snabba deploys. - Skapa en release-branch precis i tid. Du branchar från en känd god trunk-commit, härdar den, släpper och tar bort den. Fixar landar på trunk först och plockas tillbaka med cherry-pick. Det passar team med långsammare release-grindar eller reglerad godkännandeprocess. Vilket du väljer beror på din detektionstid. Om du kan märka en dålig deploy inom fem minuter och återställa på två, fixa framåt. Om din mean time to detect är en timme ger en release-branch dig en plats att stå på. ![Korta sidospår som mynnar ut i en huvudjärnväg](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/67c259-i2.webp) ## Observability är den andra halvan av affären Trunk based development höjer din deploy-frekvens, vilket höjer antalet tillfällen då något kan gå fel. Modellen fungerar bara om du kan se en regression inom några minuter efter en merge. Det innebär felfrekvenser, latenspercentiler och mättnad kopplade till en specifik release, inte en dashboard som någon tittar på på måndag. Ett användbart test: kan du efter en merge svara på "flyttade den här ändringen p99 eller felfrekvensen?" utan att öppna fem flikar? Om inte är du inte redo att merga tio gånger om dagen. Oavsett stack är kravet detsamma. Deploy-markörer i graferna, SLO-larm på burn rate och en återställningsväg som en trött person kan köra klockan tre utan att tänka. ## Trunk based development mot GitFlow, GitHub Flow och DORA-måtten De tre blandas ihop ofta, så skilj dem åt med en egenskap: hur länge arbetet ligger utanför den delade branchen. - GitFlow håller en develop-branch, feature-branches, release-branches och hotfix-branches. Arbete kan vara isolerat i veckor. Det designades för versionerade, schemalagda releaser, och det syns när du försöker deploya tio gånger om dagen. - GitHub Flow ligger nära trunk. Kortlivade branches, pull requests, merge till main, deploy. Skillnaden som referenssidan lyfter fram handlar mest om varifrån releaserna kommer. - Trunk based development är den strängaste av de tre när det gäller branchens livslängd, och den förutsätter feature flags eller branch by abstraction för allt som inte kan släppas i en enda liten ändring. Den praktiska skillnaden mellan modellerna syns i vad som händer när något går sönder. I GitFlow är svaret ofta en patch på en release-branch som sedan ska föras tillbaka till develop. I trunk based development är svaret en ny commit på trunk eller en flagga som stängs av. Om ditt team redan kör GitHub Flow med branches som lever under två dagar är du närmare trunk än du tror. Gapet ligger oftast i flagg-disciplin och granskningslatens, inte i verktygen. Instrumentera dessa mått innan du börjar, annars argumenterar du i efterhand utifrån känsla. Deployment frequency och lead time for changes rör sig först, eftersom mindre batchar flyter snabbare genom pipelinen. Change failure rate och time to restore följer, och de beror mer på din observability och återställningsväg än på branch-modellen. Använd inte siffrorna som betyg på enskilda personer. De beskriver ett system. När lead time stiger, titta på granskningskön och CI-tiden innan du tittar på människorna. ## När trunk based development är fel val, och hur du startar utan big bang Hoppa över det, eller åtminstone skjut upp det, i några fall. Var ärlig om vilket du befinner dig i. - Din testsvit tar en timme och kan inte parallelliseras. Du kommer att batcha, och batchning bryter modellen. - Du levererar versionerade artefakter till kunder som stannar kvar på gamla versioner i flera år. Du behöver underhållsbranches. Det är legitimt, och du kan ändå integrera dagligen på trunk. - Du har inget flagg-system och ingen lust att bygga ett. Halvfärdigt arbete läcker in i releaser. - Ditt team litar inte på bygget. Fixa testerna först. Trunken gör det inte åt dig. Trunk based development är inte heller en garanti för något. DORA:s slutsats är en korrelation från data från 2016 och 2017, där team som följer de här metoderna visar bättre leveransprestanda och driftprestanda. Den säger inte att du fixar pipelinen genom att byta namn på branches. Annonsera inte en policy. Mät först, krymp sedan. - Registrera nuvarande branch-livslängd och storleken på medianpull requesten. Det är dina baslinjer. - Sätt ett tak, till exempel ingen branch äldre än två dagar, och gör det synligt på en dashboard. - Åtgärda den långsammaste delen av CI. Om bygget tar 30 minuter spelar inget annat någon roll ännu. - Inför en flagga för en verklig funktion. Shippa den mörkt. Ta bort flaggan inom en sprint. - Ta bort kodfrysningar sist, när din återställningsväg har testats på allvar. Titta igen om en månad. Siffrorna som rör sig först är oftast storleken på pull requests och tiden till merge. Change failure rate tar längre tid och kan till och med bli sämre innan den blir bättre, eftersom du äntligen ser fel tidigare. Vad kommer din post-mortem att säga? Den frågan är den användbara innan du shippar. Om din senaste incident spårades till en merge ingen kunde granska, en branch som divergerade i tre veckor eller en release som paketerade fyrtio ändringar, vet du redan var lånet förfaller. Titta på dina tre senaste driftstörningar. Hur många involverade en stor, sen integration? Det antalet är ditt business case. ## FAQ ### Vad är trunk based development i enkla termer? Det är en branch-modell där alla utvecklare slår ihop små ändringar i en gemensam branch minst en gång per dag. Trunken hålls alltid byggbar och redo att släppas. ### Hur ofta ska man merga till trunk? Minst en gång per dag enligt DORA:s kapacitetssida. Många team mergar flera gånger om dagen när CI går snabbt. ### Hur skiljer sig trunk based development från GitFlow? GitFlow använder develop-, feature-, release- och hotfix-branches som kan leva i veckor. Trunk based development håller brancherna korta och kräver feature flags för ofärdigt arbete. ### Behöver man feature flags för trunk based development? Inte alltid, men utan flaggor eller branch by abstraction läcker halvfärdigt arbete ut i releaser. Varje flagga bör ha en ägare och ett utgångsdatum. ### När är trunk based development fel val? När testsviten tar timmar utan parallellisering, när du levererar versionerade artefakter som kunder kör i flera år, eller när teamet inte litar på bygget.