Förstå förgrening

  • 8 minuter

När du skapar Bicep-mallar och arbetar på en Git-lagringsplats sammanfogas slutligen alla dina teamändringar i lagringsplatsens huvudgren. Det är viktigt att skydda huvudgrenen så att inga oönskade ändringar distribueras till produktionsmiljön. Men du vill också att dina deltagare ska kunna arbeta flexibelt, samarbeta med ditt team och enkelt prova idéer.

I den här lektionen får du lära dig om förgreningsstrategier och hur du skyddar huvudgrenen. Du får också lära dig hur du konfigurerar en granskningsprocess för dina grenar.

Varför vill du skydda huvudgrenen?

Huvudgrenen är källan till sanning för vad som distribueras till dina Azure-miljöer. För många lösningar har du flera miljöer, till exempel utveckling, kvalitetssäkring (QA)och produktion. I andra scenarier kanske du bara har en produktionsmiljö. Oavsett hur många miljöer du använder är huvudgrenen den gren som dina teammedlemmar bidrar till. Deras förändringar landar slutligen på huvudgrenen.

En typisk process kan vara följande:

  1. En gruppmedlem klonar din delade lagringsplats.
  2. De gör lokala ändringar på en gren i sin egen lokala kopia av lagringsplatsen.
  3. När de är klara med ändringarna sammanfogar de ändringarna i den lokala lagringsplatsens huvudgren.
  4. De skickar ändringarna till fjärrlagringsplatsens huvudgren.
  5. I vissa fall utlöser fjärrlagringsplatsens push-överföring en automatiserad pipeline för att verifiera, testa och distribuera koden. Du får lära dig mer om pipelines i andra Microsoft Learn-moduler.

Följande diagram illustrerar den här processen:

Diagram som visar processen att göra lokala ändringar, skicka ändringar till fjärrhuvudgrenen och utlösa en pipeline.

Anta att teammedlemmens ändringar introducerade en subtil bugg. Efter att hela processen har körts är problemet på huvudgrenen av projektet och distribueras till produktionsmiljön. Du kanske inte upptäcker det förrän du försöker distribuera det och får ett fel. Eller för andra typer av buggar kan distributionen lyckas, men orsaka subtila problem senare.

I ett annat scenario antar vi att en gruppmedlem arbetar med en funktion och skickar upp hälften av funktionens färdiga arbete till det delade förrådets huvudgren. Nu har du ändringar på huvudgrenen som inte är slutförda eller testade. Dessa ändringar bör förmodligen inte distribueras till din produktionsmiljö. Distributioner till produktion kan behöva blockeras tills funktionen är klar. Om nyligen färdiga funktioner finns på huvudgrenen kanske du inte kan distribuera dem till dina kunder.

Tips

Dessa problem är särskilt svåra för stora team, där flera personer bidrar till samma kod, men vägledningen i den här modulen är värdefull så snart du samarbetar med fler än en person. Vägledningen är värdefull även när det bara är du som arbetar med ett projekt och du arbetar med flera funktioner samtidigt.

Ett bättre sätt att arbeta är att hålla dina ändringar åtskilda medan du arbetar med dem. Du kan sedan låta en annan gruppmedlem granska eventuella ändringar innan de slås samman till huvudgrenen för teamets delade lagringsplats. Den här processen hjälper ditt team att fatta ett välgrundat beslut om en ändring innan du godkänner att den slås samman.

Funktionsgrenar

En funktionsgren anger ett nytt arbete som du startar. Arbetet kan vara en konfigurationsändring av en resurs som definierats i Bicep-filen eller en ny uppsättning resurser som du behöver distribuera. Varje gång du startar ett nytt arbete skapar du en ny funktionsgren.

Du skapar en funktionsgren från huvudgrenen. När du skapar en gren ser du till att du börjar från det aktuella tillståndet för din Azure-miljö. Sedan gör du alla nödvändiga ändringar.

Eftersom alla kodändringar har åtagits till funktionsgrenen stör de inte arkivets huvudgren. Om någon annan i ditt team behöver göra en brådskande ändring av huvudgrenen kan de göra det på en annan funktionsgren som är oberoende av din.

Du kan också samarbeta om funktionsgrenar. Genom att publicera och pusha din funktionsbranch till den delade lagringsplatsen kan du och dina teammedlemmar arbeta tillsammans med en förändring. Du kan också lämna över en funktion till någon annan att slutföra när du åker på semester.

Uppdatera dina funktionsgrenar

Medan funktionsgrenen pågår kan andra funktioner slås samman till lagringsplatsens huvudgren. Resultatet är att din funktionsgren och projektets huvudgren kommer att glida isär. Ju längre de skiljer sig åt, desto svårare blir det att sammanfoga de två grenarna igen vid ett senare tillfälle, och ju fler sammanslagningskonflikter du kan stöta på.

Du bör uppdatera funktionsgrenen regelbundet så att du införlivar ändringar som har gjorts i lagringsplatsens huvudgren. Det är också en bra idé att uppdatera funktionsgrenen innan du börjar slå samman funktionsgrenen igen till huvudgrenen. På så sätt ser du till att dina nya ändringar enkelt kan sammanfogas till huvudgrenen.

Tips

Slå ofta samman huvudgrenen till din funktionsgren.

Använd små, kortlivade grenar

Sikta på kortlivade funktionsgrenar. Den här metoden hjälper dig att undvika sammanslagningskonflikter genom att minska den tid som dina grenar kan bli osynkroniserade. Den här metoden gör det också enklare för dina kollegor att förstå de ändringar du har gjort, vilket är användbart när du behöver någon som granskar dina ändringar.

Dela upp stora delar av arbetet i mindre delar och skapa en funktionsgren för var och en. Ju större funktionalitet, desto längre tid behöver någon arbeta med den, och desto längre kommer funktionsgrenen att existera. Du kan distribuera de mindre ändringarna i produktionen när du sammanfogar varje funktionsgren och gradvis bygga upp det bredare arbetet.

Anta att du gör några ändringar i en uppsättning Bicep-kod. Du flyttar några resursdefinitioner till moduler. Du måste också lägga till några nya resurser i dina Bicep-filer. Det kan vara en bra idé att göra all din modulrefaktorisering först, på en separat gren. När modulerna har sammanfogats kan du börja arbeta med tilläggen till dina Bicep-filer. Genom att separera dina ändringar behåller du varje ändring – och dess gren – liten och lätt att förstå.

När du arbetar på det här sättet kan det vara bra att använda nyckelordet if för att inaktivera distribution av resurser tills de är klara. Följande exempelkod visar hur du använder nyckelordet if för att skapa en Bicep-fil som definierar ett lagringskonto men inaktiverar lagringskontots distribution tills du är klar med alla ändringar.

@description('Specifies whether the storage account is ready to be deployed.')
param storageAccountReady bool = false

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = if (storageAccountReady) {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Premium_LRS'
  }
}

Du kan använda parametrar för att ange olika värden för storageAccountReady variabeln i olika miljöer. Du kan till exempel ange parametervärdet till true för testmiljön och false för produktionsmiljön. På så sätt kan du prova det nya lagringskontot i testmiljön.

Notera

När det är dags att aktivera funktionen i produktion, kom ihåg att du måste vidta följande steg för att ändringen ska börja gälla:

  1. Ändra parametervärdet.
  2. Återdistribuera Bicep-filen.

Slå samman funktionsgrenar

När du är klar med att arbeta med en funktionsgren måste du slå samman den med lagringsplatsens huvudgren. Det är en bra idé att granska de ändringar som gjordes i funktionsgrenen innan de sammanfogades. Med pull-begäranden kan du granska koden. Du får lära dig mer om pull-begäranden senare i den här modulen.

Branchskydd

I GitHub kan du konfigurera grenskydd för den delade lagringsplatsens huvudgren. Grenskydd tillämpar regler som:

  • Ingen ändring kan sammanfogas till huvudgrenen förutom via en pull-begäran.
  • Ändringar måste granskas av minst två andra personer.

Om någon försöker pusha en commit direkt till en skyddad gren misslyckas pushen. Du får lära dig hur du tillämpar grenskydd i nästa lektion.

Grenprinciper

I Azure DevOps kan du konfigurera grenprinciper för den delade lagringsplatsens huvudgren. Grenprinciper tillämpar regler som:

  • Ingen ändring kan sammanfogas till huvudgrenen förutom via en pull-begäran.
  • Ändringar måste granskas av minst två andra personer.

Om någon försöker dra en commit direkt till en skyddad gren misslyckas pushen. Du får lära dig hur du tillämpar grenprinciper i nästa lektion.

Andra förgreningsstrategier

När du samarbetar med din Bicep-kod kan du använda olika förgreningsstrategier. Varje förgreningsstrategi har fördelar och nackdelar.

Den process du har lärt dig om hittills är en version av trunkbaserad utvecklingsstrategi. I den här förgreningsstrategin utförs arbete på kortlivade funktionsgrenar och sammanfogas sedan till en enda huvudgren. Du kan distribuera innehållet i den delade lagringsplatsens huvudgren automatiskt till produktion varje gång en ändring slås samman, eller så kan du samla ändringar och släppa dem enligt ett schema, till exempel en gång i veckan. Trunkbaserad utveckling är lätt att förstå och möjliggör samarbete utan större omkostnader.

Vissa team separerar det arbete som de har slutfört från det arbete som de har distribuerat till produktion. De använder en långlivad utvecklingsgren som mål för sammanslagning av sina funktionsgrenar. De sammanfogar grenen utveckling i sin huvudsakliga gren när de släpper ändringar i produktionen.

Vissa andra förgreningsstrategier kräver att du skapar versionsgrenar. När du har en uppsättning ändringar som är redo att distribueras till produktion skapar du en versionsgren med de ändringar som ska distribueras. Dessa strategier kan vara meningsfulla när du distribuerar din Azure-infrastruktur regelbundet eller när du integrerar dina ändringar med många andra team.

Andra förgreningsstrategier är Gitflow, GitHub Flow och GitLab Flow. Vissa team använder GitHub Flow eller GitLab Flow eftersom det gör det möjligt att separera arbete från olika team, tillsammans med att separera brådskande felkorrigeringar från andra ändringar. De här processerna kan också göra det möjligt att separera dina incheckningar i olika versioner av din lösning, som kallas körsbärsplockning. De kräver dock mer hantering för att säkerställa att dina ändringar är kompatibla med varandra. I den här modulens sammanfattningsavsnitt finns länkar till mer information om dessa förgreningsstrategier.

Den förgreningsstrategi som passar ditt team beror på hur ditt team arbetar, samarbetar och släpper sina ändringar. Det är en bra idé att börja från en enkel process, till exempel trunkbaserad utveckling. Om du upptäcker att ditt team inte kan arbeta effektivt med den här processen kan du gradvis introducera andra förgreningslager eller anta en förgreningsstrategi. men tänk på att när du lägger till fler grenar blir det mer komplext att hantera lagringsplatsen.

Tips

Oavsett vilken förgreningsstrategi du använder är det bra att använda grenprinciper för att skydda huvudgrenen och använda pull-begäranden för att granska dina ändringar. Andra förgreningsstrategier introducerar också viktiga grenar som du bör skydda.

I den här modulen använder vi trunkbaserad utveckling med funktionsgrenar eftersom det är enkelt att använda.