Utforma en pipeline- och versionsstrategi
När du börjar publicera återanvändbar Bicep-kod använder du förmodligen en manuell metod. Det är enkelt för dig att avgöra vilken Bicep-fil du behöver publicera, och du har förmodligen en manuell process för att öka versionsnumret.
När du automatiserar publiceringsprocessen måste du överväga hur du automatiserar de här stegen. I den här lektionen får du lära dig hur du använder ett versionshanteringssystem som kommunicerar de ändringar du gör i koden. Du får också lära dig hur du kan omfångsbegränsa dina pipelines för att publicera bara den kod som du förväntar dig.
Versionsnummer
I tidigare Microsoft Learn-utbildningsmoduler lärde du dig om vikten av versionshantering för mallspecifikationer och Bicep-moduler. Du kan välja mellan många olika versionshanteringsmetoder. I många situationer är det en bra idé att använda ett versionshanteringssystem för flera delar . Ett versionshanteringssystem för flera delar består av en huvudversion, delversion och revisionsnummer, ungefär som i följande exempel:
I föregående exempel är huvudversionen 1, delversionen är 4 och revisionsnumret är 106.
Ändringar i olika delar av versionsnummer förmedlar viktig information om typerna av ändringar i koden:
När du gör en icke-bakåtkompatibel ändring bör du öka huvudversionsnumret. Anta till exempel att du lägger till en ny obligatorisk parameter eller tar bort en parameter från Bicep-filen. Det här är exempel på icke-bakåtkompatibla ändringar eftersom Bicep kräver att obligatoriska parametrar anges vid distributionstillfället och inte tillåter inställningsvärden för icke-existerande parametrar. Så du skulle uppdatera huvudversionsnumret.
När du lägger till något nytt i koden, men det inte är en icke-bakåtkompatibel ändring, bör du öka delversionsnumret. Anta till exempel att du lägger till en ny valfri parameter med ett standardvärde. Valfria parametrar bryter inte mot ändringar, så du bör uppdatera delversionsnumret.
När du gör bakåtkompatibla felkorrigeringar eller andra ändringar som inte påverkar hur koden fungerar bör du öka revisionsnumret. Anta till exempel att du omstrukturerar din Bicep-kod för att bättre använda variabler och uttryck. Om refaktoreringen inte ändrar Bicep-kodens beteende alls uppdaterar du revisionsnumret.
Din pipeline kan också automatiskt ange revisionsnumret. Pipelinens versionsnummer kan användas som revisionsnummer. Den här konventionen säkerställer att versionsnumren alltid är unika, även om du inte uppdaterar de andra komponenterna i versionsnumren.
Anta till exempel att du använder en tidigare publicerad Bicep-modul med versionsnumret 2.0.496. Du ser att en ny version av modulen är tillgänglig med versionsnumret 2.1.502. Den enda betydande ändringen är det lägre versionsnumret, vilket indikerar att du inte bör förvänta dig en icke-bakåtkompatibel ändring när du använder den nya versionen.
Kommentar
Semantisk versionshantering är en formaliserad versionsstruktur som liknar versionshantering i flera delar. Semantisk versionshantering innehåller ytterligare komponenter i versionsnumret, tillsammans med strikta regler om när du ska ange eller återställa varje komponent. Vi länkar till mer information om semantisk versionshantering i sammanfattningen.
Ditt team måste bestämma hur de ska definiera en icke-bakåtkompatibel ändring för versionshantering. Anta till exempel att du skapar en Bicep-modul som distribuerar ett lagringskonto. Nu uppdaterar du Bicep-filen för att aktivera privata slutpunkter på ditt lagringskonto. Du lägger till en privat DNS-zon i Bicep-filen samtidigt.
I det exemplet kanske du kan göra ändringen utan att påverka Bicep-filens parametrar eller utdata. På så sätt kanske ingen som distribuerar filen märker att något är annorlunda. Men den här ändringen medför en betydande skillnad i beteendet för dina resurser, så du kan välja att behandla den som en viktig versionsuppdatering oavsett.
Du kan också välja att använda en enklare versionsstrategi, till exempel att bara använda pipelinens versionsnummer som versionsnummer. Även om den här metoden är enklare att implementera innebär det att du inte effektivt kan kommunicera skillnaderna mellan versioner till alla som använder din kod.
Versioner och pipelines
När du publicerar koden interaktivt, till exempel med hjälp av Azure CLI, tänker du förmodligen på versionsnumret som du tilldelar till mallspecifikationen eller modulen när du publicerar den. Men i en automatiserad distributionspipeline måste du ändra din metod för att tilldela versionsnummer. Din pipeline kan inte automatiskt identifiera icke-bakåtkompatibla ändringar, eller ge dig råd när du ska öka dina större eller mindre versionsnummer. Överväg noggrant versionshantering innan du publicerar mallspecifikationen eller modulen.
En metod är att lagra en metadatafil med din Bicep-kod, enligt följande diagram:
När du uppdaterar Bicep-koden uppdaterar du versionsinformationen i motsvarande metadatafil. Se till att du korrekt identifierar icke-bakåtkompatibla ändringar så att du kan öka versionsnumren korrekt.
Dricks
Om ditt team granskar din Bicep-kod med hjälp av pull-begäranden ber du granskarna att kontrollera om några ändringar i koden kräver att du ändrar huvud- eller delversionsnumren.
Du ser hur du kan använda en metadatafil i nästa övning.
Hur många pipelines?
Det är vanligt att bygga upp en samling mallspecifikationer och moduler. Ofta är det klokt att behålla den här koden på samma Git-lagringsplats.
Genom att använda sökvägsfilter i Azure Pipelines kan du skapa separata pipelines för varje modul eller mallspecifikation på lagringsplatsen. Den här metoden hjälper dig att undvika att publicera en ny version av varje Bicep-fil på lagringsplatsen varje gång du ändrar en fil. Du kan använda pipelinemallar för att definiera pipelinens steg i en centraliserad fil, vilket håller varje moduls och mallspecifikationens pipeline lätt.
Anta till exempel att du har en filstruktur som liknar den som illustreras tidigare. Du kan konfigurera tre separata pipelines, en för varje Bicep-fil. Välj varje flik för att se motsvarande pipelinedefinition och dess sökvägsfilter:
trigger:
batch: true
branches:
include:
- main
paths:
include:
- 'module-1/**'
stages:
- template: pipeline-templates/publish-module.yml
parameters:
path: 'module-1/main.bicep'
Anta att du bara ändrar filen module-2/main.bicep . Endast pipelinen för modul 2 körs. Men om du ändrar flera filer i samma incheckning utlöses alla relevanta pipelines.
Kommentar
Metoden att skapa en pipeline för var och en av dina återanvändbara Bicep-filer är enkel och flexibel. Men det kan bli besvärligt när du har ett stort antal Bicep-filer, eller om du inte vill underhålla separata pipelines för varje modul och mallspecifikation.
Du kan också skriva skript i pipelinen för att hitta koden som har ändrats och publicera bara dessa filer. Det här är en mer komplex metod och den ligger utanför omfånget för den här Microsoft Learn-modulen.
Miljöer för återanvändbar Bicep-kod
När du distribuerar till Azure med hjälp av Bicep är det vanligt att använda flera miljöer som hjälper dig att verifiera och testa koden innan den publiceras i en produktionsmiljö. I tidigare Microsoft Learn-utbildningsmoduler lärde du dig att arbeta med flera miljöer från en distributionspipeline.
Vissa organisationer tillämpar samma principer på Bicep-moduler och mallspecifikationer. Du kan till exempel först publicera nya versioner av dina moduler till ett icke-produktionsregister så att användarna av varje modul kan prova de nya versionerna. Sedan, när de har loggat ut på ändringarna, kan du publicera modulerna i organisationens produktionsregister.
Precis som med vanliga distributioner kan du använda jobb och pipelinemallar för att definiera distributionssekvensen i dina miljöer. I den här Microsoft Learn-modulen publicerar vi till en enda miljö för att hålla pipelinen enkel.
När du använder moduler från ett register eller använder en mallspecifikation som en Bicep-modul kan du använda alias. I stället för att ange registernamnet eller mallspecifikationens plats varje gång du definierar en modul använder du dess alias.
Med hjälp av alias kan du enkelt få distributionsprocessen att fungera i flera miljöer. När du till exempel definierar en modul kan du använda ett alias i stället för ett registernamn. Sedan kan du utforma en distributionspipeline för att konfigurera aliaset som ska mappas till:
- Ett register för utvecklingsmoduler när du distribuerar till en sandbox-miljö.
- Ett produktionsregister när du distribuerar till andra miljöer.
Kommentar
Alias gäller inte när du publicerar. De fungerar bara när du använder mallspecifikationer eller moduler i en Bicep-fil.