Návrh kanálu a strategie správy verzí
Když začnete publikovat opakovaně použitelný kód Bicep, pravděpodobně použijete ruční přístup. Je snadné určit, který soubor Bicep potřebujete publikovat, a pravděpodobně máte ruční proces pro zvýšení čísla verze.
Při automatizaci procesu publikování je potřeba zvážit, jak tyto kroky automatizovat. V této lekci se dozvíte, jak přijmout systém správy verzí, který oznamuje změny provedené v kódu. Dozvíte se také, jak můžete nastavit obor kanálů tak, aby se publikoval jenom očekávaný kód.
Čísla verzí
V předchozích výukových modulech Microsoft Learn jste se dozvěděli o důležitosti správy verzí pro specifikace šablon a moduly Bicep. Můžete si vybrat z mnoha různých přístupů ke správě verzí. V mnoha situacích je vhodné použít vícedílný systém správy verzí. Systém s více částmi správy verzí se skládá z hlavní verze, podverze a čísla revize , podobně jako v následujícím příkladu:
V předchozím příkladu je hlavní verze 1, podverze je 4 a číslo revize je 106.
Změny v různých částech čísel verzí sdělují důležité informace o typech změn v kódu:
Kdykoli provedete zásadní změnu, měli byste zvýšit číslo hlavní verze. Předpokládejme například, že přidáte nový povinný parametr nebo odeberete parametr ze souboru Bicep. Jedná se o příklady zásadních změn, protože Bicep vyžaduje, aby byly v době nasazení zadány povinné parametry a neumožňují nastavení hodnot pro neexistující parametry. Proto byste aktualizovali číslo hlavní verze.
Kdykoli do kódu přidáte něco nového, ale nejedná se o zásadní změnu, měli byste zvýšit číslo podverze. Předpokládejme například, že přidáte nový volitelný parametr s výchozí hodnotou. Volitelné parametry nejsou zásadními změnami, proto byste měli aktualizovat číslo podverze.
Kdykoli provedete opravy chyb kompatibilní se zpětnou kompatibilitou nebo jiné změny, které nemají vliv na fungování kódu, měli byste zvýšit číslo revize. Předpokládejme například, že refaktorujete kód Bicep tak, aby lépe využíval proměnné a výrazy. Pokud refaktoring vůbec nezmění chování kódu Bicep, aktualizujete číslo revize.
Kanál může také automaticky nastavit číslo revize. Číslo buildu kanálu se dá použít jako číslo revize. Tato konvence pomáhá zajistit, aby čísla verzí byla vždy jedinečná, i když neaktualizujete ostatní součásti čísel verzí.
Předpokládejme například, že používáte dříve publikovaný modul Bicep s číslem 2.0.496verze . Uvidíte, že je k dispozici nová verze modulu s číslem 2.1.502verze . Jedinou významnou změnou je číslo podverze, které značí, že byste při použití nové verze neměli očekávat změnu způsobující chybu.
Poznámka:
Sémantická správa verzí je formalizovaná struktura správy verzí, která se podobá správě verzí s více částmi. Sémantická správa verzí obsahuje další komponenty v čísle verze spolu s přísnými pravidly o tom, kdy byste měli nastavit nebo resetovat jednotlivé komponenty. Odkazujeme na další informace o sémantické sémantické správě verzí v souhrnu.
Váš tým se musí rozhodnout, jak definovat zásadní změnu správy verzí. Předpokládejme například, že vytvoříte modul Bicep, který nasadí účet úložiště. Teď aktualizujete soubor Bicep, abyste povolili privátní koncové body ve vašem účtu úložiště. Do souboru Bicep přidáváte současně privátní zónu DNS.
V tomto příkladu můžete být schopni provést změnu, aniž by to ovlivnilo parametry nebo výstupy souboru Bicep. Každý, kdo soubor nasadí, si tak nemusí všimnout, že se něco liší. Tato změna ale představuje významný rozdíl v chování vašich prostředků, takže se můžete rozhodnout, že se s nimi budete chovat jako s aktualizací hlavní verze bez ohledu na to.
Můžete také použít jednodušší strategii správy verzí, jako je například použití čísla buildu kanálu jako čísla verze. I když je tento přístup jednodušší implementovat, znamená to, že nemůžete efektivně komunikovat rozdíly mezi verzemi komukoli, kdo používá váš kód.
Verze a kanály
Když publikujete kód interaktivně, například pomocí Rozhraní příkazového řádku Azure, pravděpodobně si při publikování myslíte na číslo verze, které přiřadíte ke specifikaci šablony nebo modulu. V kanálu automatizovaného nasazení ale musíte změnit přístup k přiřazování čísel verzí. Kanál nedokáže automaticky rozpoznat zásadní změny nebo vám poradit, kdy byste měli zvýšit čísla hlavních nebo podverze. Před publikováním specifikace šablony nebo modulu pečlivě zvažte správu verzí.
Jedním z přístupů je uložení souboru metadat s kódem Bicep, jak je znázorněno v následujícím diagramu:
Pokaždé, když aktualizujete kód Bicep, aktualizujete informace o verzi v odpovídajícím souboru metadat. Ujistěte se, že správně identifikujete změny způsobující chybu a přerušení, abyste mohli čísla verzí správně zvýšit.
Tip
Pokud váš tým zkontroluje kód Bicep pomocí žádostí o přijetí změn, požádejte revidujícím, aby ověřili, jestli změny kódu vyžadují změnu hlavního nebo podverze.
V dalším cvičení se dozvíte, jak můžete použít soubor metadat.
Kolik kanálů?
Je běžné vytvořit kolekci specifikací šablon a modulů. Často je vhodné tento kód uchovávat ve stejném úložišti Git.
Pomocí filtrů cest ve službě Azure Pipelines můžete vytvořit samostatné kanály pro každý modul nebo specifikaci šablony v rámci úložiště. Tento přístup vám pomůže vyhnout se publikování nové verze každého souboru Bicep v úložišti při každé změně jednoho souboru. Pomocí šablon kanálů můžete definovat kroky kanálu v centralizovaném souboru, který udržuje kanál jednotlivých modulů a specifikací šablon odlehčeného kanálu.
Předpokládejme například, že máte strukturu souborů podobnou té, která je znázorněna dříve. Můžete nakonfigurovat tři samostatné kanály, jeden pro každý soubor Bicep. Výběrem každé karty zobrazíte odpovídající definici kanálu a její filtr cesty:
trigger:
batch: true
branches:
include:
- main
paths:
include:
- 'module-1/**'
stages:
- template: pipeline-templates/publish-module.yml
parameters:
path: 'module-1/main.bicep'
Předpokládejme, že změníte pouze soubor module-2/main.bicep . Spustí se jenom kanál pro modul 2. Pokud ale změníte více souborů ve stejném potvrzení, aktivuje se každý z příslušných kanálů.
Poznámka:
Přístup k vytvoření kanálu pro každý z opakovaně použitelných souborů Bicep je jednoduchý a flexibilní. Může se ale stát těžkopádným, pokud máte velký počet souborů Bicep nebo pokud nechcete udržovat samostatné kanály pro každý modul a specifikaci šablony.
Můžete také napsat skripty v kanálu, abyste našli změněný kód a publikovali jenom tyto soubory. Jedná se o složitější přístup, který je nad rámec tohoto modulu Microsoft Learn.
Prostředí pro opakovaně použitelný kód Bicep
Když nasadíte do Azure pomocí Bicep, je běžné použít více prostředí, která vám pomůžou ověřit a otestovat kód před publikováním do produkčního prostředí. V předchozích výukových modulech Microsoft Learn jste se naučili pracovat s více prostředími z kanálu nasazení.
Některé organizace používají stejné principy pro moduly Bicep a specifikace šablon. Můžete například nejprve publikovat nové verze modulů do neprodukčního registru, aby si uživatelé každého modulu mohli vyzkoušet nové verze. Po odhlášení od změn pak můžete moduly publikovat do produkčního registru vaší organizace.
Stejně jako u běžných nasazení můžete pomocí úloh a šablon kanálů definovat pořadí nasazení ve vašich prostředích. V tomto modulu Microsoft Learn publikujeme do jednoho prostředí, aby byl kanál jednoduchý.
Při využívání modulů z registru nebo použití specifikace šablony jako modulu Bicep můžete použít aliasy. Místo zadání názvu registru nebo umístění specifikace šablony při každém definování modulu použijete jeho alias.
Pomocíaliasch Když například definujete modul, můžete místo názvu registru použít alias. Potom můžete navrhnout kanál nasazení tak, aby nakonfiguroval alias, na který se má namapovat:
- Registr vývojového modulu při nasazování do prostředí sandboxu.
- Produkční registr při nasazování do jiných prostředí.
Poznámka:
Aliasy se při publikování nepoužijí. Fungují jenom v případech, kdy v souboru Bicep používáte specifikace šablon nebo moduly.