Utforma en arbetsflödes- 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 har gjort i koden. Du får också lära dig hur du kan omfångsbegränsa dina arbetsflöden 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.
Arbetsflödet kan också automatiskt ange revisionsnumret. Arbetsflödets körningsnummer 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 Bicep-modul som någon annan har publicerat. Modulen har ett versionsnummer på 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 har skapat 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 kanske bestämmer dig för att behandla den som en viktig versionsuppdatering.
Du kan också välja att använda en enklare versionsstrategi, till exempel att bara använda arbetsflödets körningsnummer 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 arbetsflöden
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 ett automatiserat distributionsarbetsflöde måste du ändra din metod för att tilldela versionsnummer. Arbetsflödet 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 arbetsflöden?
Det är vanligt att bygga upp en samling mallspecifikationer och moduler. Ofta är det klokt att behålla dessa på samma Git-lagringsplats.
Genom att använda sökvägsfilter i GitHub Actions kan du skapa separata arbetsflöden 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 återanvändbara arbetsflöden för att definiera arbetsflödets steg i en centraliserad fil, vilket håller varje moduls och mallspecifikationens arbetsflöde enkelt.
Anta till exempel att du har en filstruktur som liknar den som illustreras tidigare. Du kan konfigurera tre separata arbetsflöden, ett för varje Bicep-fil. Välj varje flik för att se motsvarande arbetsflödesdefinition och dess sökvägsfilter:
name: 'publish-module-1'
on:
push:
branches:
- main
paths:
- 'module-1/**'
jobs:
publish:
uses: ./.github/workflows/publish-module.yml
with:
path: 'module-1/main.bicep'
Anta att du bara ändrar filen module-2/main.bicep . Endast arbetsflödet för modul 2 körs. Men om du ändrar flera filer i samma incheckning utlöses alla relevanta arbetsflöden.
Kommentar
Metoden att skapa ett arbetsflöde 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 arbetsflöden för varje modul och mallspecifikation.
Du kan också skriva skript i arbetsflödet 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-utbildningsmodulen.
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 du publicerar koden i en produktionsmiljö. I tidigare Microsoft Learn-utbildningsmoduler lärde du dig att arbeta med flera miljöer från ett distributionsarbetsflöde.
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. När de har loggat ut kan du sedan publicera modulerna i organisationens produktionsregister.
Precis som med vanliga distributioner kan du använda jobb och återanvändbara arbetsflöden för att definiera distributionssekvensen i dina miljöer. I den här Utbildningsmodulen för Microsoft Learn publicerar vi till en enda miljö för att hålla arbetsflödet enkelt.
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 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 ett distributionsarbetsflöde 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.