Vad är trunk based development? En guide för solo-utvecklare

Vad är trunk based development? Det är en branch-modell där alla slår ihop små ändringar i en gemensam gren, oftast kallad main eller trunk, minst en gång om dagen. Grenar du ändå använder lever i timmar, inte veckor. Halvfärdigt arbete släpps bakom en flagga, så att trunk går att släppa vid varje commit. Det är hela idén, och den är mindre exotisk än namnet antyder.

Så här brukar det se ut. Du öppnar ett sidoprojekt som du lämnade för tre veckor sedan. Feature-grenen ligger 41 commits efter main, två filer har konflikter, och det du byggde stämmer inte längre med koden runt omkring. Trunk based development är vanan som gör att den scenen aldrig uppstår.

Vad trunk based development faktiskt betyder

Referenssajten trunkbaseddevelopment.com beskriver det som en källkodsmodell där utvecklare samarbetar i en gemensam gren och undviker andra långlivade utvecklingsgrenar. Direkta commits till trunk duger för mycket små team. Pull requests fungerar också, så länge feature-grenarna är kortlivade och kommer från en utvecklares arbete.

Tre regler bär större delen av vikten.

• Slå ihop till trunk minst en gång var 24:e timme.

• Håll trunk grön: ett trasigt bygge på main är högsta prioritet för alla.

• Göm ofärdigt arbete bakom feature flags i stället för att hålla det på en sidogren.

Lägg märke till vad som saknas. Det finns ingen develop-gren, ingen lång release-gren per funktion och ingen integrationsfas i slutet där alla upptäcker att koden inte passar ihop. I de äldre modellerna sparas smärtan upp och betalas på en gång.

Varför det slår långlivade grenar i de flesta små team

Långlivade grenar är ett lån. Varje dag som en gren lever glider den lite längre från main, och räntan syns som merge-konflikter, gamla antaganden och granskningar som ingen hinner avsluta eftersom diffen rör 60 filer.

DORA:s sida om trunk based development kopplar tre praktiker till bättre leveranshastighet, stabilitet och tillgänglighet, baserat på deras forskning i State of DevOps. Ha tre eller färre aktiva grenar i repot. Slå ihop till trunk minst en gång om dagen. Undvik kodfrysningar och integrationsfaser. Det är konkreta, mätbara mål, vilket är ovanligt i det här området.

För en solo-utvecklare eller ett team på tre är argumentet ännu enklare. Små merges är lätta att granska, lätta att backa och lätta att förstå sex månader senare, när du läser git blame klockan 22 och undrar vad din tidigare jag tänkte.

Tre skäl att göra det, ett skäl att inte göra det. Skälen: mindre diffar, snabbare feedback från CI och en main-gren som du kan deploya en fredag utan att svettas. Skälet emot: om dina tester är tunna sprider daglig merge bara trasigheten snabbare. Vi kommer till det nedan.

Korta grenar eller direkt till main?

Båda räknas som trunk based development. Skillnaden är hur mycket säkerhet du vill ha innan koden landar.

Att committa direkt till main fungerar när du jobbar ensam eller i par, ditt lokala bygge körs på under en minut och du litar på dina tester. Det är snabbaste loopen som finns. De flesta solo-byggare gör redan så utan att kalla det för något.

Korta grenar med pull request blir rimliga när en andra eller tredje person kommer med, eller när du vill att CI ska köra på en ren checkout innan merge. Disciplinen sitter i ordet kort. En gren som överlever förbi nästa dag är redan på väg mot den modell du försöker lämna.

En praktisk rutin som håller:

• Hämta main och skapa en gren med ett namn som säger vad ändringen är.

• Gör minsta möjliga ändring som för saker framåt, och kör hela bygget lokalt.

• Öppna PR:en, låt CI köra och slå ihop samma dag.

• Ta bort grenen. Låt dem inte samlas.

Om en ändring inte går att göra på en dag är svaret inte en längre gren. Svaret är att skära ändringen tunnare.

Hur skeppar du halvfärdigt arbete utan att bryta main?

Det här är frågan som stoppar de flesta. Om du slår ihop varje dag kommer du att slå ihop kod för funktioner som ännu inte finns. Två tekniker hanterar det.

Den första är feature-flaggan. Den nya kodvägen slås ihop men är avstängd, så användarna aldrig ser den. En flagga kan vara lika enkel som en boolean i en miljövariabel:

const showNewCheckout = process.env.FEATURE_NEW_CHECKOUT === "true";

export function Checkout() {
  return showNewCheckout ? <NewCheckout /> : <OldCheckout />;
}

Det räcker för ett sidoprojekt. När du behöver målgrupper, gradvisa utrullningar eller en nödbrytare utan omdeploy är en hanterad tjänst värd sin plats.

Den andra tekniken är branch by abstraction, för större ändringar som att byta databasklient eller betalningsleverantör. Du lägger ett gränssnitt framför den gamla implementationen, bygger den nya bakom samma gränssnitt, flyttar anropen bit för bit och tar sedan bort den gamla. Varje steg är en liten merge till trunk, och inget ligger på en lång gren.

En ärlig reservation om flaggor: de är skuld. En flagga som ligger kvar i koden i ett år är en gren i förklädnad. Ge varje flagga en ägare och ett borttagningsdatum, och ta bort den när funktionen är fullt utrullad.

Vad din CI behöver innan du prövar det

Trunk based development utan skyddsnät är bara snabb trasighet. Tre saker behöver finnas på plats innan du förbinder dig till en daglig merge-vana.

• Ett bygge som körs vid varje push och blir klart på minuter, inte på en halvtimme.

• Tester som faller när något verkligt går sönder. Kodtäckning säger mindre än om en dålig ändring fångas.

• Ett snabbt sätt att backa: en revert av commit eller en avstängd flagga.

Statisk analys är ett billigt extra lager. Den fångar en klass av problem, som uppenbara buggar, säkerhetslukt och duplicerad kod, innan en människa läser diffen.

Om du är den enda granskaren hjälper verktyg som pekar på riskfyllda hotspots ännu mer, eftersom ingen annan säger att filen du hela tiden ändrar håller på att bli en röra.

Hoppa över idén att du behöver en tung pipeline första dagen. En enda workflow-fil som installerar, lintar, testar och deployar main är en fullt god start. Den är inte optimal, men den är värd att göra ändå. Det är första versionen som fungerar, och du kan skärpa den senare.

Release-grenar, hotfixar och sådant som ändå kräver omsorg

Trunk based development förbjuder inte release-grenar. Vissa team skär en gren från trunk precis före en release, härdar den, släpper den och tar bort den. Andra släpper direkt från trunk och fixar framåt när en bugg dyker upp. För en webbapp som deployas flera gånger i veckan är framåtfix nästan alltid enklast.

Mobilappar och allt med en långsam granskningscykel i en appbutik är en annan historia. Där kan du ha en kortlivad release-gren per version, så att du kan patcha det som redan finns hos användarna. Även då gäller regeln: fixar landar på trunk först och plockas sedan över med cherry-pick, aldrig tvärtom.

Hotfixar följer samma logik. Fixa på trunk, deploya, klart. En separat hotfix-gren som aldrig slås ihop tillbaka är hur team hamnar med två historier som glider isär.

En realistisk första vecka

Dag ett: kolla hur ditt repo grenar sig i dag. Lista de öppna grenarna och notera åldern på varje. Allt som är äldre än några dagar är kandidat för merge eller borttagning. Det här visar ofta var friktionen sitter.

Dag två: lägg till flaggmekanismen. Även en miljövariabel duger. Välj en pågående funktion, lägg dess ingångspunkt bakom flaggan och slå ihop det du har.

Dag tre till fem: ändra vanan. Dela upp varje uppgift i bitar som kan landa på en dag och slå ihop varje bit när CI är grön. De första bitarna kommer att kännas för små. De är inte det. En commit som lägger till en vilande databaskolumn eller en oanvänd funktion är en fullt god enhet framsteg, eftersom den är säker, granskad och redan integrerad.

I slutet av veckan vet du två saker: om dina tester är tillräckligt pålitliga, och vilka delar av koden som motsätter sig små ändringar. Båda är användbara, och ingen av dem syns när du arbetar på långa grenar.

Du behöver ingen dashboard för att se det. Titta på hur länge dina grenar lever, hur ofta main är röd och hur lång tid en ändring tar från första commit till produktion. Om grenåldern krymper och deployerna blir tråkiga ger vanan resultat.

Vill du ha siffror på hur det du skickar bakom flaggor påverkar användarna kan ett experimentverktyg koppla en utrullning till riktiga mätvärden i stället för magkänsla.

Om du är ensam utvecklare duger en vanlig anteckningsbok. Skriv ned tiden från merge till deploy varje vecka under en månad. Trenden säger dig mer än någon enskild siffra.

Ska du byta, eller vänta?

Byt om du jobbar ensam, i par eller i ett litet team med tester du halvt litar på och en CI du kan förbättra. Kostnaden för att prova är en vecka med lite obekväma små commits. Kostnaden för att stanna kvar på långa grenar betalas i konflikter och långsamma granskningar, och den växer med varje medarbetare.

Vänta om du inte har några automatiska tester alls och inget sätt att backa. Åtgärda det först, eftersom dagliga merges till en otestad trunk bara flyttar smärtan.

Det är ingen perfekt metod. Det är en fungerande. Välj nästa lilla ändring i ditt nuvarande projekt, slå ihop den i dag och se hur det känns. Vad är den minsta biten av din nuvarande funktion som du kan skicka innan ikväll?