Návrh strategie pracovního postupu a 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ý komunikuje se změnami, které jste udělali v kódu. Dozvíte se také, jak můžete nastavit obor pracovních postupů tak, aby se publikoval pouze 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.
Pracovní postup může také automaticky nastavit číslo revize. Číslo spuštění pracovního postupu lze 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 modul Bicep, který publikoval někdo jiný. Modul má číslo 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 pro účely správy verzí. Předpokládejme například, že jste vytvořili 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řináší 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.
Můžete se také rozhodnout použít jednodušší strategii správy verzí, jako je například použití čísla spuštění pracovního postupu 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 pracovní postupy
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 pracovním postupu automatizovaného nasazení ale musíte změnit přístup k přiřazování čísel verzí. Pracovní postup 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 pracovních postupů?
Je běžné vytvořit kolekci specifikací šablon a modulů. Často je vhodné je uchovávat ve stejném úložišti Git.
Pomocí filtrů cest v GitHub Actions můžete vytvořit samostatné pracovní postupy 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. Opakovaně použitelné pracovní postupy můžete použít k definování kroků pracovního postupu v centralizovaném souboru, který udržuje pracovní postup jednotlivých modulů a specifikací šablon odlehčený.
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é pracovní postupy, jeden pro každý soubor Bicep. Výběrem každé karty zobrazíte odpovídající definici pracovního postupu a její filtr cesty:
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'
Předpokládejme, že změníte pouze soubor module-2/main.bicep . Spustí se pouze pracovní postup pro modul 2. Pokud ale změníte více souborů ve stejném potvrzení, aktivuje se každý z příslušných pracovních postupů.
Poznámka:
Přístup k vytvoření pracovního postupu 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é pracovní postupy pro každý modul a specifikaci šablony.
Můžete také napsat skripty v pracovním postupu, 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 výukového 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 kódu 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 pracovního postupu 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í pak můžete moduly publikovat do produkčního registru vaší organizace.
Stejně jako u běžných nasazení můžete pomocí úloh a opakovaně použitelných pracovních postupů definovat pořadí nasazení v různých prostředích. V tomto školicím modulu Microsoft Learn publikujeme do jednoho prostředí, aby byl pracovní postup 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. Pak můžete navrhnout pracovní postup nasazení tak, aby se alias namapoval na:
- 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.