Návrh kanálu
- 11 min
V této lekci sledujete webový tým Společnosti Tailspin, který definuje kanál vydání pro web Space Game .
Když plánujete vydávací kanál, obvykle začnete identifikací fází nebo hlavních částí daného kanálu. Každá fáze se obvykle mapuje na prostředí. Například v předchozím modulu měli Andy a Mara základní kanál, který měl fázi nasazení , která se mapovala na instanci služby Azure App Service.
V tomto modulu propagujete změny z jedné fáze na další. V každé fázi nasadíte web Space Game do prostředí přidruženého k této fázi.
Po definování potřebných fází zvažte, jak se změny propagují z jedné fáze na další. Každá fáze může definovat kritéria úspěchu, která musí být splněna, než se sestavení může přesunout do další fáze. Azure Pipelines poskytuje několik způsobů, jak řídit, kdy a jak se změny pohybují skrze pipeline. Jako celek se tyto přístupy používají ke správě verzí.
V této části vy:
- Seznamte se s rozdíly mezi běžnými fázemi pipeline, jako jsou sestavení, vývoj, testování a předprodukce.
- Naučte se, jak pomocí triggerů ručního, plánovaného a průběžného nasazování řídit, kdy se artefakty přesunou do další fáze v potrubí.
- Podívejte se, jak schválení uvolnění pozastaví potrubí, dokud schvalovatel schválí nebo zamítne uvolnění.
Schůzka
Celý webový tým Tailspin se shromažďuje společně. Dříve tým naplánoval své úkoly pro aktuální sprint. Každá úloha souvisí se sestavením vydávacího kanálu pro web Space Game .
Tým se rozhodl pro tento sprint těchto pět úkolů:
- Vytvořte kanál s více fázemi
- Připojení webové aplikace k databázi
- Automatizace testů kvality
- Automatizace testů výkonnosti
- Zlepšení četnosti vydávání verzí
Tým se setká, aby si promluvil o prvním úkolu, vytvoření vícestupňového potrubí. Jakmile tým definuje kanál, může přejít ze základního testování konceptu na vydávací kanál, který zahrnuje více fází, kontrol kvality a schválení.
Amita a Tim sledují, jak Andy a Mara podruhé ukazují vydávací proces. Vidí, že artefakt je sestavený a nainstalovaný ve službě App Service.
Jaké fáze kanálu potřebujete?
Když chcete implementovat vydávací kanál, je důležité nejprve určit, které etapy potřebujete. Zvolené fáze závisí na vašich požadavcích. Pojďme s týmem sledovat, jak se rozhodují o svých fázích.
Tim: Dobře, rozumím myšlence automatizovaného kanálu. Líbí se mi, jak je snadné nasazení do Azure. Kam se posuneme od této ukázky? Potřebujeme něco, co můžeme ve skutečnosti použít pro naše vydání.
Amita: Vpravo! Musíme přidat další fáze. V současné době například nemáme místo pro testovací fázi.
Tim: Navíc potřebujeme fázi, ve které můžeme zobrazovat nové funkce pro správu. Nemůžu nic poslat do produkčního prostředí bez schválení managementu.
Ondra: Naprosto! Teď, když jsme se seznámili s tím, co dělá nasazovací potrubí, jak ho přizpůsobíme našim potřebám?
Mara: Pojďme si načrtnout naše požadavky, abychom mohli naplánovat další kroky. Začněme tím, co máme.
Mara se přesune na tabuli a načrtá stávající kanál.
Mara: Fáze sestavení sestaví zdrojový kód a vytvoří balíček. V našem případě je tento balíček .zip soubor. Fáze nasazení nainstaluje soubor .zip, což je web Space Game, na instanci služby App Service. Co chybí v našem procesu vydání?
Přidání vývojové fáze
Ondra: Možná jsem zkreslený, ale myslím, že potřebujeme vývojovou fázi. Tato fáze by měla být prvním zastavením artefaktu po jeho sestavení. Vývojáři nemůžou vždy spouštět celou službu ze svého místního vývojového prostředí. Například systém elektronického obchodování může vyžadovat web, databázi produktů a platební systém. Potřebujeme fázi, která zahrnuje vše, co aplikace potřebuje.
V našem případě funkce tabulky výsledků webu Space Game čte vysoké skóre z externího zdroje. Právě teď čte fiktivní skóre ze souboru. Nastavení vývojové fáze by nám poskytlo prostředí, ve kterém můžeme webovou aplikaci integrovat se skutečnou databází. Tato databáze může stále obsahovat fiktivní skóre, ale přináší nám ještě jeden krok blíž k naší konečné aplikaci.
Mara: Líbí se mi to. Zatím se neintegrujeme se skutečnou databází. Ve fázi vývoje ale můžeme nasadit do prostředí, kde můžeme přidat databázi.
Mara aktualizuje kresbu na tabuli. Nahradí "Deploy" za "Dev", aby zobrazila fázi Dev.
Ondra: Přinášíte zajímavý bod. Aplikaci sestavíme pokaždé, když nasdílíme změnu na GitHub. Znamená to, že každé sestavení je po dokončení povýšeno do vývojové fáze ?
Mara: Sestavování průběžně nám dává důležitou zpětnou vazbu o našem stavu sestavení a testování. Ale chceme zvýšit úroveň na fázi Dev pouze v případech, kdy kód sloučíme do některé centrální větve: hlavní nebo do jiné verze pro vydání. Aktualizujem výkres tak, aby ukázal tento požadavek.
Mara: Myslím, že toto povýšení bude snadné dosáhnout. Můžeme definovat podmínku, která povýší na fázi Dev pouze tehdy, když dojde ke změnám ve větvi vydané verze.
Co jsou podmínky?
V Azure Pipelines použijte podmínku ke spuštění úkolu nebo úlohy na základě stavu potrubí. Pracovali jste s podmínkami v předchozích modulech.
Nezapomeňte, že některé podmínky, které můžete zadat, jsou:
- Pouze v případech, kdy byly všechny předchozí závislé úkoly úspěšné
- I v případě, že předchozí závislost selhala, pokud se spuštění nezrušilo
- I když předchozí závislost selhala, i když se spuštění zrušilo
- Pouze v případech, kdy předchozí závislost selhala
- Některá vlastní podmínka
Tady je základní příklad:
steps:
- script: echo Hello!
condition: always()
Podmínka always() způsobí, že tento úkol vytiskne "Hello!" bezpodmínečně, i když předchozí úkoly selhaly.
Tato podmínka se použije, pokud nezadáte podmínku:
condition: succeeded()
Předdefinovaná funkce succeeded() zkontroluje, jestli předchozí úloha proběhla úspěšně. Pokud předchozí úkol selže, tento úkol a pozdější úkoly, které používají stejnou podmínku, se přeskočí.
Tady chcete vytvořit podmínku, která určuje:
- Předchozí úkol byl úspěšný.
- Název aktuální větve Git je release.
K sestavení této podmínky použijete integrovanou funkci and(). Tato funkce zkontroluje, jestli jsou splněné všechny její podmínky. Pokud některá podmínka není pravdivá, celková podmínka selže.
Pokud chcete získat název aktuální větve, použijte proměnnou Build.SourceBranchName, která je předdefinovaná systémem. K proměnným v rámci podmínky můžete přistupovat několika způsoby. Tady použijete syntaxi variables[].
K otestování hodnoty proměnné můžete použít integrovanou funkci eq(). Tato funkce zkontroluje, zda jsou argumenty stejné.
S ohledem na to použijete tuto podmínku ke spuštění fáze Dev pouze když název aktuální větve je "release":
condition: |
and
(
succeeded(),
eq(variables['Build.SourceBranchName'], 'release')
)
První podmínka ve funkci and() zkontroluje, jestli předchozí úkol proběhl úspěšně. Druhá podmínka zkontroluje, jestli se název aktuální větve rovná release.
V YAML použijete syntaxi kanálu (|) k definování řetězce, který zahrnuje více řádků. Podmínku můžete definovat na jednom řádku, ale tímto způsobem ji napíšeme, aby byla čitelnější.
Poznámka
V tomto modulu používáme jako příklad větev release. Podmínky můžete kombinovat, abyste definovali chování, které potřebujete. Můžete například vytvořit podmínku, která spustí fázi pouze v případě, že sestavení je spuštěno pull requestem proti hlavní větvi.
V další lekci, když nastavíte fázi vývoje , budete pracovat s úplnějším příkladem.
Pro podrobnější popis podmínek ve službě Azure Pipelines se podívejte do dokumentace k výrazům .
Mara: Pomocí podmínek můžete určit, které změny se upřednostní do jednotlivých fází. Můžeme vytvořit výstup sestavení pro jakoukoli změnu, abychom naše sestavení ověřili a potvrdili jeho správnost. Až budeme připraveni, můžeme tyto změny sloučit do release větve a povýšit toto sestavení do vývojové fáze.
Přidání testovací fáze
Mara: Zatím máme fáze buildu a vývoje . Co se stane dál?
Amita: Můžeme přidat další fázi testování ? Zdá se, že je to správné místo, abych si vyzkoušel nejnovější změny.
Mara přidá testovací fázi do své kresby na tabuli.
Amita: Jedním z problémů, které mám, je, jak často potřebuji otestovat aplikaci. E-mail mě upozorní pokaždé, když Mara nebo Andy provede změnu. Změny probíhají v průběhu dne a já nikdy nevím, kdy se zapojit. Myslím, že bych chtěl vidět sestavení jednou denně, možná když přijdu do kanceláře. Můžeme to udělat?
Ondra: Jistý. Proč se nenasazujeme do testování během mimopracovní doby? Řekněme, že vám každý den pošleme build v 3:00.
Mara: To zní dobře. Pokud potřebujeme, můžeme proces kdykoli aktivovat i ručně. Můžeme ji například aktivovat, pokud potřebujete, abyste hned ověřili důležitou opravu chyb.
Mara aktualizuje svou kresbu, aby ukázala, že se build každý den ve 3:00 ráno přesune z fáze vývoje do fáze testování.
Co jsou triggery?
Amita: Teď se cítím lépe, když víme, jak se jedna fáze posune k druhé. Jak ale řídíme, kdy se etapa spustí?
Mara: V Azure Pipelines můžeme použít triggery. Aktivační událost definuje, kdy se fáze spustí. Azure Pipelines poskytuje několik typů triggerů. Tady jsou naše volby:
- Spouštěč kontinuální integrace (CI)
- Spouštěč žádosti o začlenění změn (PR)
- Naplánovaná aktivační událost
- Trigger dokončení sestavení
Triggery CI a PR umožňují řídit, které větve se účastní celkového procesu. Chcete například vytvořit projekt při provedení změny v libovolné větvi. Naplánovaná aktivační událost spustí nasazení v určitém čase. Trigger dokončení sestavení spustí sestavení, když se úspěšně dokončí jiné sestavení, například sestavení pro závislé součásti. Zdá se, že chceme naplánovanou aktivační událost.
Co jsou naplánované triggery?
Naplánovaný trigger používá syntaxi cron k tomu, aby se sestavení spustilo podle definovaného plánu.
V systémech Unix a Linux je cron oblíbeným způsobem, jak naplánovat spouštění úloh v nastaveném časovém intervalu nebo v určitém čase. V Azure Pipelines používají naplánované triggery syntaxi cron k definování, kdy se fáze spustí.
Výraz cron obsahuje pole, která odpovídají určitým časovým parametrům. Toto jsou pole:
mm HH DD MM DW
\ \ \ \ \__ Days of week
\ \ \ \____ Months
\ \ \______ Days
\ \________ Hours
\__________ Minutes
Tento cron výraz například popisuje "3:00 každý den": 0 3 * * *
Výraz cron může obsahovat speciální znaky k určení seznamu hodnot nebo rozsahu hodnot. V tomto příkladu hvězdička (*) odpovídá všem hodnotám polí Dny, Měsíce a Dny v týdnu .
Jinak řečeno, tento výraz cron se čte takto:
- Za minutu 0,
- Ve třetí hodině,
- V libovolném dni v měsíci,
- V libovolném měsíci
- V libovolném dni v týdnu,
- Spusťte úlohu
Pokud chcete zadat 3 A.M. pouze v pondělí až pátek, použili byste tento výraz: 0 3 * * 1-5
Poznámka
Časové pásmo pro plány cron je koordinovaný univerzální čas (UTC), takže v tomto příkladu 3:00 odkazuje na 3:00 v UTC. V praxi možná budete chtít upravit časový plán cron vzhledem k času UTC, aby se potrubí spouštělo v očekávanou dobu pro vás a váš tým.
K nastavení naplánovaného triggeru v Azure Pipelines potřebujete v souboru YAML oddíl schedules. Tady je příklad:
schedules:
- cron: '0 3 * * *'
displayName: 'Deploy every day at 3 A.M.'
branches:
include:
- release
always: false
V této schedules části:
-
cronurčuje výraz cron. -
branchesurčuje nasazení pouze z větverelease. -
alwaysurčuje, jestli se má nasazení spouštět bezpodmínečně (true), nebo pouze v případech, kdy se od posledního spuštění změnila větevrelease(false). Zde zadátefalse, protože potřebujete nasadit pouze v případě, že se od posledního spuštění změnila větevrelease.
Celý kanál se spustí, když Azure Pipelines spustí naplánovanou aktivační událost. Kanál se také spouští za jiných podmínek, například když nasdílíte změnu na GitHub. Pokud chcete spustit fázi pouze v reakci na naplánovanou aktivační událost, můžete použít podmínku, která kontroluje, jestli je důvodem sestavení naplánované spuštění.
Tady je příklad:
- stage: 'Test'
displayName: 'Deploy to the Test environment'
condition: and(succeeded(), eq(variables['Build.Reason'], 'Schedule'))
Tato fáze Testse spustí pouze v případě, že předchozí fáze proběhne úspěšně a vestavěná proměnná potrubí Build.Reason se rovná Schedule.
Podrobnější příklad uvidíte později v tomto modulu.
Amita: Líbí se mi to. Ani nemusím vyzvednout verzi ručně a nainstalovat ji. Je to pro mě nachystané.
Ondra: A nezapomeňte, že pokud budeme chtít později automatizovat více, můžeme. Nic není napsané v kamene. Proces se vyvíjí, jak se zlepšujeme a učíme.
Přidání přípravné fáze
Tim: Je to můj tah. Potřebuji fázi, abych spustil více zátěžových testů. Potřebujeme také prostor, kde můžeme předvést demo vedení a získat jejich schválení. Prozatím můžeme tyto dvě potřeby zkombinovat do fáze, kterou nazýváme Staging.
Andy: Hezky řečeno, Time. Je důležité mít přípravné nebo předprodukční prostředí. Toto přípravné prostředí je často posledním zastavením před tím, než se funkce nebo oprava chyb dostane k našim uživatelům.
Mara přidá Staging do svého obrázku na bílou tabuli.
Amita: K povýšení změn z fáze vývoje do fáze testování používáme naplánovaný trigger. Jak ale můžeme přesunout změny z testování na Staging? Musí se tato propagace provádět také podle plánu?
Mara: Myslím, že nejlepší způsob, jak to zvládnout, by bylo schválení vydané verze. Schválení uvolnění umožňuje ručně posunout změnu z jedné fáze do další.
Amita: To zní jako přesně to, co potřebuji! Schválení vydané verze by mi poskytlo čas na otestování nejnovějších změn, než představíme sestavení pro správu. Mohu zvýšit úroveň sestavení, až budu připraven.
Mara aktualizuje kresbu, aby ukázala, že se build přesune z Test do Staging pouze, pokud to Amita schválí.
Tim: Mohl bych si také představit, že po odhlášení správy používáme schválení vydaných verzí k propagaci z přípravného do produkčního prostředí . Nemůžu nikdy předpovědět, jak dlouho to trvá. Po jejich schválení můžu schválit vydání a ručně jej povýšit na produkční verzi. Jak ale funguje schvalování verzí?
Co jsou schválení vydání?
Schválení vydání je způsob, jak pozastavit procesní řetězec, dokud schvalovatel vydání nepřijme nebo neodmítne. Pokud chcete definovat pracovní postup vydávání verzí, můžete zkombinovat schválení, podmínky a triggery.
Tady je příklad z existujícího pipeline, který definuje prostředí ve své konfiguraci a reprezentuje prostředí nasazení.
- stage: 'Deploy'
displayName: 'Deploy the web application'
dependsOn: Build
jobs:
- deployment: Deploy
pool:
vmImage: 'ubuntu-20.04'
environment: dev
variables:
- group: Release
Vaše prostředí může obsahovat konkrétní kritéria pro vaši verzi. Kritéria můžou určovat, které pipeliny se můžou do daného prostředí nasadit a jaká lidská schválení jsou potřebná k postupu vydání z jedné fáze do další.
Později v tomto modulu definujete přípravné prostředí a přiřadíte sami sebe jako schvalovatele k propagaci webové aplikace Space Gamez testovací fáze do přípravné fáze.
Automatizujte málo nebo hodně, jak potřebujete.
Azure Pipelines nabízí flexibilitu pro automatizaci některých fází a ruční řízení fází, které nejsou připravené pro automatizaci.
Tim: Líbí se mi, jak můžeme definovat kritéria, která propagují změny z jedné fáze na další. V procesu jsme ale definovali určitá ruční kritéria. Myslel jsem, že DevOps je o automatizaci všeho.
Mara: Uvádíte dobrý argument. DevOps je opravdu o automatizaci opakujících se úloh a náchylných k chybám. Někdy je nutný lidský zásah. Před vydáním nových funkcí například získáme schválení od správy. S tím, jak získáme více zkušeností s automatizovanými nasazeními, můžeme automatizovat více našich ručních kroků, abychom proces urychlili. Můžeme například automatizovat více kontrol kvality ve fázi testování , takže Amita nemusí schvalovat každé sestavení.
Tim: Zní to skvěle. Pojďme teď s tímto plánem začít a podívat se, jak můžeme systém později urychlit.
Amita: Když už mluvíme o našem plánu, můžeme shrnout další kroky?
Plán
Pojďme se podívat na plán týmu Tailspin, když se posunou k dalším krokům.
Mara: Tady je nasazovací potrubí, které chceme vytvořit.
Mara ukazuje na tabuli.
Mara: Abychom to shrnuli, máme následující kroky:
- Při každém odeslání změn na GitHub vytvořte artefakt sestavení. K tomuto kroku dochází ve fázi sestavení .
- Zvýšení úrovně artefaktu sestavení do fáze vývoje K tomuto kroku dochází automaticky, když fáze sestavení proběhne úspěšně a změna se nachází ve větvi vydané verze.
- Zvyšte úroveň artefaktu sestavení do testovací fáze každé ráno v 3:00. K automatickému zvýšení úrovně artefaktu sestavení používáme naplánovanou aktivační událost.
- Zvýšení úrovně artefaktu sestavení na přípravný po otestování Amita a schválení sestavení. Ke zvýšení úrovně artefaktu sestavení používáme schválení vydané verze.
Jakmile správa sestavení schválí, můžeme artefakt sestavení nasadit do produkčního prostředí.
Amita: Bude to těžké udělat? Zdá se, že je to hodně práce.
Mara: Nemyslím si, že je to moc špatné. Každá fáze je oddělená od každé druhé fáze. Fáze jsou diskrétní. Každá fáze má svou vlastní sadu úkolů. Například to, co se stane ve fázi testování , zůstane ve fázi testování .
Každá fáze nasazení v našem řetězci má také vlastní prostředí. Když například nasadíme aplikaci do vývoje nebo testování, prostředí je instance služby App Service.
Nakonec testujeme jenom jednu verzi najednou. Nikdy neměníme vydání uprostřed procesu. Stejnou verzi používáme ve fázi vývoje jako v přípravné fázi a každá vydaná verze má vlastní číslo verze. Pokud se verze přeruší v jedné z fází, opravíme ji a znovu ji sestavíme s novým číslem verze. Tato nová verze poté prochází procesem od samého začátku.
Pár slov o kvalitě
Právě jste viděli, jak tým navrhl proces, který přenese jejich aplikaci celou cestu od sestavení až po přípravu. Hlavním účelem tohoto procesu není jen usnadnit jejich život. Je potřeba zajistit kvalitu softwaru, který dodává svým zákazníkům.
Jak změříte kvalitu procesu vydávání? Nemůžete ho měřit přímo. Co můžete měřit, je to, jak dobře váš proces funguje. Pokud proces neustále měníte, může to značit, že se něco nepovedlo. Verze, které konzistentně selhávají v určitém bodě potrubí, mohou také naznačovat, že je problém s procesem vydání.
Dochází k selhání vydaných verzí vždy v určitý den nebo čas? Vždy selžou po nasazení do konkrétního prostředí? Hledejte tyto a další vzory, abyste zjistili, jestli jsou některé aspekty procesu vydávání závislé nebo související.
Dobrým způsobem, jak sledovat kvalitu procesu vydávání verzí, je vytvořit vizualizace kvality vydaných verzí. Můžete například přidat widget řídicího panelu, který zobrazuje stav každé verze.
Pokud chcete měřit kvalitu samotné verze, můžete v pipeline provádět všechny druhy kontrol. Například můžete během běhu pipeline provádět různé typy testů, jako jsou zátěžové testy a testy uživatelského rozhraní.
Použití brány kvality je také skvělý způsob, jak zkontrolovat kvalitu vašeho vydání. Existuje mnoho různých kvalitních bran. Například kontrolní brány pracovních úkolů mohou ověřit kvalitu procesu tvorby požadavků.
Můžete také přidat další kontroly zabezpečení a dodržování předpisů. Dodržujete například zásadu čtyř očí nebo máte správnou dohledatelnost?
Při procházení tohoto studijního programu uvidíte mnoho z těchto technik, které jsou součástí praxe.
A konečně, když navrhujete proces vydávání verzí kvality, zamyslete se nad tím, jaký druh dokumentace nebo poznámky k verzi potřebujete uživateli poskytnout. Udržování aktuální dokumentace může být obtížné. Můžete zvážit použití nástroje, jako je generátor zpráv k vydání verze Azure DevOps, což je aplikace funkcí, která obsahuje funkci aktivovanou protokolem HTTP. Pomocí služby Azure Blob Storage vytvoří soubor Markdown při každém vytvoření nové verze v Azure DevOps.