Munkafolyamat és verziószámozási stratégia tervezése
Amikor újrahasználható Bicep-kódot kezd közzétenni, valószínűleg manuális megközelítést használ. Könnyen meghatározhatja, hogy melyik Bicep-fájlt kell közzétennie, és valószínűleg van egy manuális folyamat a verziószám növeléséhez.
A közzétételi folyamat automatizálása során meg kell fontolnia, hogyan automatizálhatja ezeket a lépéseket. Ebben a leckében megtanulhatja, hogyan hozhat létre verziószámozási rendszert, amely közli a kódon végrehajtott módosításokat. Azt is megtudhatja, hogyan teheti közzé a munkafolyamatokat úgy, hogy csak a várt kódot tegye közzé.
Verziószámok
A Microsoft Learn korábbi képzési moduljaiban megismerkedett a sablon-specifikációk és a Bicep-modulok verziószámozásának fontosságával. Számos különböző verziószámozási módszer közül választhat. Sok esetben ajánlott többrészes verziószámozási rendszert használni. A többrészes verziószámozási rendszer főverzióból, alverzióból és változatszámból áll, az alábbi példához hasonlóan:
Az előző példában a főverzió 1, az alverzió 4, a verziószám pedig 106.
A verziószámok különböző részeinek változásai fontos információkat közölnek a kód módosításainak típusairól:
Ha kompatibilitástörő módosítást tesz, növelnie kell a főverzió számát. Tegyük fel például, hogy új kötelező paramétert ad hozzá, vagy eltávolít egy paramétert a Bicep-fájlból. Ilyenek például a kompatibilitástörő változások, mivel a Bicep megköveteli a kötelező paraméterek megadását az üzembe helyezéskor, és nem teszi lehetővé a nem létező paraméterek értékeinek beállítását. Ezért frissítenie kell a főverzió számát.
Ha újat ad hozzá a kódhoz, de ez nem kompatibilitástörő változás, növelje az alverzió számát. Tegyük fel például, hogy új opcionális paramétert ad hozzá alapértelmezett értékkel. Az opcionális paraméterek nem törik meg a módosításokat, ezért frissítenie kell az alverzió számát.
Ha visszamenőlegesen kompatibilis hibajavításokat vagy más olyan módosításokat végez, amelyek nem befolyásolják a kód működését, növelnie kell a verziószámot. Tegyük fel például, hogy újra átfésüli a Bicep-kódot a változók és kifejezések jobb kihasználása érdekében. Ha az újrabontás egyáltalán nem változtatja meg a Bicep-kód viselkedését, frissítse a változatszámot.
A munkafolyamat automatikusan beállíthatja a változatszámot is. A munkafolyamat futtatási száma használható változatszámként. Ez az egyezmény segít biztosítani, hogy a verziószámok mindig egyediek legyenek, még akkor is, ha nem frissíti a verziószámok többi összetevőjét.
Tegyük fel például, hogy valaki más által közzétett Bicep-modult használ. A modul verziószáma: 2.0.496. Láthatja, hogy a modul új verziója elérhető a verziószámmal 2.1.502. Az egyetlen jelentős változás az alverzió száma, ami azt jelzi, hogy az új verzió használatakor nem kell kompatibilitástörő változásra számítania.
Feljegyzés
A szemantikus verziószámozás a többrészes verziószámozáshoz hasonló formalizált verziószámozási struktúra. A szemantikus verziószámozás további összetevőket tartalmaz a verziószámban, valamint szigorú szabályokat is tartalmaz arra vonatkozóan, hogy mikor kell beállítani vagy alaphelyzetbe állítani az egyes összetevőket. Az összegzésben a szemantikai verziószámozással kapcsolatos további információkra hivatkozunk.
A csapatnak el kell döntenie, hogyan definiálhat kompatibilitástörő változást a verziószámozás céljából. Tegyük fel például, hogy létrehozott egy Bicep-modult, amely egy tárfiókot helyez üzembe. Most frissíti a Bicep-fájlt, hogy engedélyezze a privát végpontokat a tárfiókban. Egy privát DNS-zónát ad hozzá a Bicep-fájlhoz egyszerre.
Ebben a példában a Bicep-fájl paramétereinek vagy kimeneteinek befolyásolása nélkül is elvégezheti a módosítást. Így előfordulhat, hogy bárki, aki telepíti a fájlt, nem veszi észre, hogy bármi más. Ez a változás azonban jelentős különbséget jelent az erőforrások viselkedésében, ezért dönthet úgy, hogy fő verziófrissítésként kezeli.
Dönthet úgy is, hogy egyszerűbb verziószámozási stratégiát használ, például a munkafolyamat futtatási számát használja verziószámként. Bár ez a megközelítés könnyebben implementálható, ez azt jelenti, hogy nem tudja hatékonyan kommunikálni a verziók közötti különbségeket bárkivel, aki a kódot használja.
Verziók és munkafolyamatok
Ha interaktívan teszi közzé a kódot, például az Azure CLI használatával, valószínűleg a sablon specifikációjához vagy moduljához hozzárendelt verziószámra gondol a közzététel során. Az automatizált üzembehelyezési munkafolyamatokban azonban módosítania kell a verziószámok hozzárendelésére vonatkozó megközelítést. A munkafolyamat nem képes automatikusan észlelni a kompatibilitástörő változásokat, és nem tud tanácsot adni, hogy mikor kell növelni a fő- vagy alverziószámokat. A sablon specifikációjának vagy moduljának közzététele előtt alaposan fontolja meg a verziószámozást.
Az egyik módszer egy metaadatfájl tárolása a Bicep-kóddal, az alábbi ábrán látható módon:
Amikor frissíti a Bicep-kódot, a megfelelő metaadatfájlban frissíti a verzióinformációkat. Győződjön meg arról, hogy helyesen azonosítja a kompatibilitástörő és a nem törhető módosításokat, hogy megfelelően növelhesse a verziószámokat.
Tipp.
Ha a csapat lekéréses kérések használatával tekinti át a Bicep-kódot, kérje meg a véleményezőket, hogy ellenőrizzek, hogy a kód módosításaihoz szükség van-e a fő- vagy alverziószám módosítására.
A következő gyakorlatban látni fogja, hogyan használhat metaadatfájlokat.
Hány munkafolyamat van?
Gyakori, hogy sablon-specifikációk és modulok gyűjteményét kell összeállítani. Gyakran érdemes ezeket ugyanabban a Git-adattárban tartani.
A GitHub Actions elérésiút-szűrőinek használatával külön munkafolyamatokat hozhat létre az adattárban lévő egyes modulokhoz vagy sablonspektúrákhoz. Ez a módszer segít elkerülni, hogy minden bicep-fájl új verzióját tegye közzé az adattárban minden alkalommal, amikor egy fájlt módosít. Az újrafelhasználható munkafolyamatok segítségével meghatározhatja a munkafolyamat lépéseit egy központi fájlban, így az egyes modulok és sablonspecifikációk munkafolyamata egyszerű marad.
Tegyük fel például, hogy a korábban bemutatotthoz hasonló fájlszerkezettel rendelkezik. Három külön munkafolyamatot konfigurálhat, egyet minden Bicep-fájlhoz. Jelölje ki az egyes lapokat a megfelelő munkafolyamat-definíció és elérésiút-szűrő megtekintéséhez:
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'
Tegyük fel, hogy csak a modul-2/main.bicep fájlt módosítja. Csak a 2. modul munkafolyamata fut. Ha azonban ugyanabban a véglegesítésben több fájlt módosít, a rendszer aktiválja az egyes releváns munkafolyamatokat.
Feljegyzés
Az egyes újrafelhasználható Bicep-fájlok munkafolyamatának létrehozásának módja egyszerű és rugalmas. Nehézkessé válhat azonban, ha nagy számú Bicep-fájllal rendelkezik, vagy ha nem szeretne külön munkafolyamatokat fenntartani minden modulhoz és sablon specifikációhoz.
Szkripteket is írhat a munkafolyamaton belül, hogy megkeresse a módosított kódot, és csak ezeket a fájlokat tegye közzé. Ez egy összetettebb megközelítés, amely túlmutat a Microsoft Learn képzési modul hatókörén.
Újrahasználható Bicep-kód környezetei
Amikor a Bicep használatával helyezi üzembe az Azure-ban, gyakori, hogy több környezet használatával ellenőrzi és teszteli a kódot, mielőtt közzéteené a kódot egy éles környezetben. A Microsoft Learn korábbi képzési moduljaiban megtanulta, hogyan dolgozhat több környezettel egy üzembehelyezési munkafolyamatból.
Egyes szervezetek ugyanazokat az alapelveket alkalmazzák a Bicep-modulokra és a sablon specifikációira. Előfordulhat például, hogy először közzéteszi a modulok új verzióit egy nem gyártási beállításjegyzékben, hogy az egyes modulok felhasználói kipróbálhassák az új verziókat. Ezután a kijelentkezés után közzéteheti a modulokat a szervezet éles beállításjegyzékében.
A szokásos üzemelő példányokhoz hasonlóan feladatok és újrafelhasználható munkafolyamatok használatával is meghatározhatja az üzembe helyezési sorrendet a környezetekben. Ebben a Microsoft Learn képzési modulban egyetlen környezetben tesszük közzé a munkafolyamat egyszerűségének érdekében.
Amikor egy beállításjegyzékből származó modulokat használ, vagy egy sablon specifikációt használ Bicep-modulként, aliasokat használhat. Ahelyett, hogy minden modul definiálásakor megadná a beállításjegyzék nevét vagy a sablon specifikációjának helyét, annak aliasát használná.
Az aliasok használatával az üzembehelyezési folyamat több környezetben is működik. Ha például egy modult definiál, a beállításjegyzék neve helyett aliast használhat. Ezután megtervezhet egy üzembehelyezési munkafolyamatot, hogy konfigurálja a megfeleltetendő aliast:
- Fejlesztői modul beállításjegyzéke tesztkörnyezetben való üzembe helyezéskor.
- Éles beállításjegyzék más környezetekben való üzembe helyezéskor.
Feljegyzés
Az aliasok nem érvényesek a közzétételkor. Ezek csak akkor működnek, ha sablon-specifikációkat vagy modulokat használ egy Bicep-fájlban.