Op trunk-gebaseerde ontwikkeling

Voordelen van op trunk-gebaseerde ontwikkeling

Trunk-gebaseerde ontwikkeling is een vereiste praktijk voor continue integratie. Als de build- en testprocessen geautomatiseerd zijn, maar ontwikkelaars werken aan geïsoleerde, langdurige feature branches die niet vaak worden geïntegreerd in een gedeelde branch, dan maakt continue integratie geen gebruik van de potentie.

Trunk-gebaseerde ontwikkeling vermindert de frictie van code-integratie. Wanneer ontwikkelaars klaar zijn met nieuw werk, moeten ze de nieuwe code samenvoegen in de hoofd-branch. Toch moeten ze wijzigingen niet samenvoegen met de trunk totdat ze hebben geverifieerd dat het een succesvolle build is. Tijdens deze fase kunnen er conflicten ontstaan als er wijzigingen zijn aangebracht sinds het begin van de nieuwe werkzaamheden. Deze conflicten worden steeds complexer naarmate de ontwikkelingsteams groeien en de codebasis schaalt. Dit gebeurt wanneer ontwikkelaars afzonderlijke branches aanmaken die afwijken van de bron-branch en andere ontwikkelaars tegelijkertijd overlappende code samenvoegen. Gelukkig vermindert op trunk-gebaseerde ontwikkeling deze conflicten.

Maakt continue code-integratie mogelijk

Met op trunk-gebaseerde ontwikkeling is er een repository met een gestage stroom van commits die naar de main-branch stroomt. De toevoeging van een geautomatiseerde testsuite en monitoring van de codedekking voor deze stroom van commits maakt continue integratie mogelijk. Wanneer nieuwe code wordt samengevoegd in de trunk, worden geautomatiseerde integratie- en codedekkingstests uitgevoerd om de kwaliteit van de code te valideren.

Zorgt voor een continue codebeoordeling

De snelle, kleine commits van op trunk-gebaseerde ontwikkeling maakt het beoordelen van code een efficiënter proces. Met kleine branches kunnen ontwikkelaars kleine wijzigingen snel zien en beoordelen. Dit is veel eenvoudiger vergeleken met een langlevende feature-branch waar een beoordelaar pagina's aan code leest of handmatig een groot gebied met codewijzigingen inspecteert.

Maakt opeenvolgende releases van productiecode mogelijk

Teams moeten regelmatig en dagelijks fusies maken naar de hoofdbranch. Op trunk-gebaseerde ontwikkeling streeft ernaar om de branche “groen” te houden, wat betekent dat deze klaar is om te worden geïmplementeerd bij iedere commit. Geautomatiseerde tests, code samenvoegen en code-beoordelingen bieden een op trunk-gebaseerde ontwikkelingsproject met de zekerheid dat het op elk moment klaar is voor productie. Dit geeft het team de flexibiliteit om regelmatig in productie te implementeren en verdere doelen te stellen met betrekking tot de dagelijkse productiereleases.

Op trunk-gebaseerde ontwikkeling en CI/CD

Naarmate CI/CD in populariteit toenam, werden branche-modellen verfijnd en geoptimaliseerd, dit leidde tot de opkomst van op trunk-gebaseerde ontwikkeling. Nu is op trunk-gebaseerde ontwikkeling een vereiste voor continue integratie. Bij continue integratie voeren ontwikkelaars trunk-gebaseerde ontwikkeling uit in combinatie met geautomatiseerde tests die na elke commit naar een trunk worden uitgevoerd. Dit zorgt ervoor dat het project altijd werkt.

Best practices voor trunk-gebaseerde ontwikkeling

Ontwikkeling op basis van trunks zorgt ervoor dat teams code snel en consistent vrijgeven. Hieronder volgt een lijst met beleid en praktijken die zullen helpen om de cadans van je team te verfijnen en een geoptimaliseerd releaseschema op te stellen.

Ontwikkel in kleine batches

Op trunk-gebseerde ontwikkeling volgt een snel ritme om code aan de productie te leveren. Als trunk-gebaseerde ontwikkeling zou lijken op muziek, zou het een snelle staccato zijn: korte, beknopte noten die elkaar snel achter elkaar volgen, waarbij de commits in het repository de noten zijn. Door commits en branches klein te houden, kan het tempo van fusies en implementaties sneller verlopen.

Kleine wijzigingen in een paar commits of aanpassingen van een paar regels code minimaliseren de cognitieve overhead. Het is veel gemakkelijker voor teams om zinvolle gesprekken te voeren en snel beslissingen te nemen bij het bekijken van een beperkt codegebied ten opzichte van een groot aantal wijzigingen.

Functiemarkeringen

Functievlaggen vormen een mooie aanvulling op trunk-gebaseerde ontwikkeling, omdat ontwikkelaars nieuwe wijzigingen in een inactief codepad kunnen verpakken en dit op een later moment kunnen activeren. Hierdoor hoeven ontwikkelaars geen aparte functiebranch meer aan te maken voor de repository en kunnen ze de nieuwe functiecode rechtstreeks naar de main-branch doorsturen binnen een functievlagpad.

Functievlaggen moedigen updates in kleine batches direct aan. In plaats van een functiebranch te maken en te wachten om de volledige specificatie uit te bouwen, kunnen ontwikkelaars in plaats daarvan een trunkcommit maken die de functievlag introduceert en nieuwe trunkcommits pusht die de functie-specificatie binnen de vlag uitbouwen.

Implementeer uitgebreide geautomatiseerde tests

Geautomatiseerde tests zijn noodzakelijk voor elk modern softwareproject dat gericht is op het behalen van CI/CD. Er zijn meerdere soorten geautomatiseerde tests die in verschillende stadia van de release pipeline worden uitgevoerd. Tijdens de ontwikkeling en bij het samenvoegen van de code worden kortlopende afdelings- en integratietests uitgevoerd. Langer lopende, volledige end-to-end stacktests worden uitgevoerd in latere fasen van de pipeline tegen een volledige stagen- of productieomgeving.

Geautomatiseerde tests helpen bij op trunk-gebaseerde ontwikkeling door een klein batchritme aan te houden wanneer ontwikkelaars nieuwe commits samenvoegen. De geautomatiseerde testsuite controleert de code op eventuele problemen en keurt deze automatisch goed of af. Dit helpt ontwikkelaars om snel commits te maken en deze aan geautomatiseerde tests te laten voldoen om te zien of ze nieuwe problemen introduceren.

Voer asynchrone code-beoordelingen uit

Bij de trunk-gebaseerde ontwikkeling moet de code onmiddellijk worden beoordeeld en niet in een asynchroon systeem worden geplaatst om later te worden beoordeeld. Geautomatiseerde tests zorgen voor een preventieve beoordeling van de code. Wanneer ontwikkelaars klaar zijn om de pull-aanvraag van een teamlid te beoordelen, kunnen ze eerst controleren of de geautomatiseerde tests geslaagd zijn en of de codedekking is toegenomen. Dit geeft de beoordelaar onmiddellijk de zekerheid dat de nieuwe code aan bepaalde specificaties voldoet. De beoordelaar kan zich dan concentreren op optimalisaties.

Heb drie of minder actieve branches in de coderepository van de applicatie

Zodra een branch wordt samengevoegd, is het het beste om deze te verwijderen. Een repository met een groot aantal actieve branches heeft enkele vervelende bijwerkingen. Hoewel het voor teams nuttig kan zijn om te zien wat er aan de hand is door actieve branches te onderzoeken, gaat dit voordeel verloren als er nog steeds verouderde en inactieve branches zijn. Sommige ontwikkelaars gebruiken Git-gebruikersinterfaces die lastig kunnen worden om mee te werken bij het laden van een groot aantal afgelegen branches.

Voeg de branches minstens één keer per dag samen met de trunk

Goed presterende ontwikkelingsteams op basis van trunks zouden alle openstaande en fusieklare branches moeten sluiten en samenvoegen, minstens dagelijks. Deze oefening helpt het ritme te behouden en stelt een cadans in voor releasetracking. Het team kan dan aan het eind van de dag de hoofdtrunk taggen als een release-commit, wat als bijkomend neveneffect heeft dat er iedere dag een agile release wordt gegenereerd.

Minder codebevriezingen en integratiefasen

Agile CI/CD-teams zouden geen geplande codebevriezingen of pauzes nodig moeten hebben voor integratiefasen -- hoewel een organisatie ze misschien om andere redenen nodig heeft. Het “continue” in CI/CD houdt in dat er voortdurend updates plaatsvinden. Ontwikkelingsteams op basis van trunk moeten blokkerende codebevriezingen proberen te voorkomen en te plannen om ervoor te zorgen dat de releasepijplijn niet vastloopt.

Snel bouwen en onmiddellijk uitvoeren

Om een snelle releasecadans te behouden, moeten de uitvoeringstijden voor builds en tests worden geoptimaliseerd. De tools voor CI/CD-builds zouden waar nodig cachelagen moeten gebruiken om dure berekeningen voor statische gegevens te vermijden. De tests moeten worden geoptimaliseerd om geschikte stubs te gebruiken voor externe services.

Conclusie...

Ontwikkeling op basis van trunks is momenteel de standaard voor goed presterende engineeringteams, aangezien dit een frequentie voor softwarereleases bepaalt en handhaaft door gebruik te maken van een vereenvoudigde Git-branchingstrategie. Bovendien biedt trunk-gebaseerde ontwikkeling technische teams meer flexibiliteit en controle over hoe ze software leveren aan de eindgebruiker.

Bitbucket van Atlassian heeft ingebouwde CI/CD-mogelijkheden die trunk-gebaseerde ontwikkeling mogelijk maken. Nu uitproberen.