Navržení 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 kanál verze, obvykle začnete identifikací fází nebo hlavních divizí daného kanálu. Každá fáze se obvykle mapuje na prostředí. Například v předchozím modulu měl Andy a Mara základní kanál fázi nasazení, která se mapovala na instanci služby Aplikace Azure 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 nabízí několik způsobů, jak řídit, jak a kdy se v kanálu pohybují změny. Jako celek se tyto přístupy používají ke správě verzí.

V této části:

  • Seznamte se s rozdíly mezi běžnými fázemi kanálu, jako jsou sestavení, vývoj, testování a příprava.
  • Zjistěte, jak pomocí triggerů ručního, plánovaného a průběžného nasazování řídit, kdy se artefakt přesune do další fáze kanálu.
  • Podívejte se, jak schválení vydané verze pozastaví kanál, dokud schvalovatel tuto verzi přijme nebo neodmítne.

Schůzka

Celý webový tým Tailspin se shromažďuje společně. V části Vytvoření kanálu verze se službou Azure Pipelines tým naplánoval své úkoly pro aktuální sprint. Každý úkol se vztahuje k vytvoření kanálu vydání pro web Space Game .

Vzpomeňte si, že tým rozhodl o těchto pěti úkolech pro sprint:

  • Vytvořte kanál s více fázemi.
  • Připojení webové aplikace do databáze.
  • Automatizujte testy kvality.
  • Automatizujte testy výkonu.
  • Vylepšete tempo vydávání verzí.

Tým se setká, aby mluvil o prvním úkolu a vytvořil kanál s více fázemi. Jakmile tým kanál definuje, může přejít ze základního testování konceptu na kanál verze, který zahrnuje více fází, kontrol kvality a schválení.

Amita a Tim sledují Andyho a Maru podruhé kanál vydání. Vidí, že artefakt je sestavený a nainstalovaný ve službě App Service.

Jaké fáze kanálu potřebujete?

Pokud chcete implementovat kanál verze, je důležité nejprve zjistit, které fáze potřebujete. Zvolené fáze závisí na vašich požadavcích. Pojďme se s týmem pustit do rozhodování 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. Ale kde můžeme jít z této ukázky? Potřebujeme něco, co můžeme ve skutečnosti použít pro naše verze.

Amita: Dobře! 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.

Andy: Naprosto! Teď, když je na rychlosti, co kanál verze dělá, jak tento kanál děláme, co potřebujeme?

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.

Diagram of the whiteboard illustrating build and dev stages. Build stage produces .zip file. Dev stage deploys .zip file to Azure App Service.

Mara: Fáze sestavení sestaví zdrojový kód a vytvoří balíček. V našem případě je tento balíček soubor .zip . Fáze nasazení nainstaluje soubor .zip , což je web Space Game , na instanci služby App Service. Co v kanálu verze chybí?

Přidání vývojové fáze

Andy: 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í nasazení za "Dev", aby zobrazila fázi vývoje .

Diagram that shows the whiteboard illustrating build and dev stages. Build stage produces .zip file. Dev stage deploys .zip file to Azure App Service.

Andy: Vy vyvolá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: Budová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 vývoje pouze v případech, kdy kód sloučíme do některé centrální větve: hlavní nebo jiné větve vydané verze. Aktualizujem výkres tak, aby ukázal tento požadavek.

Diagram that shows whiteboard illustrating build and dev stages. A condition promotes to the Dev stage only when changes happen on a release branch.

Mara: Myslím, že toto povýšení bude snadné dosáhnout. Můžeme definovat podmínku , která propaguje fázi vývoje pouze v případech, 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í úlohy nebo úlohy na základě stavu kanálu. 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 nebylo spuštění zrušeno.
  • I když došlo k selhání předchozí závislosti, 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 jednoduchý 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()

Integrovaná succeeded() funkce 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 vydaný.

Pokud chcete sestavit tuto podmínku, použijte předdefinovanou 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 předdefinované Build.SourceBranchName proměnné. Proměnné 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 předdefinovanou funkci eq(). Tato funkce zkontroluje, jestli jsou její argumenty stejné.

S ohledem na to použijete tuto podmínku pro spuštění fáze vývoje pouze v případě, že 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í úloha byla úspěšná. Druhá podmínka zkontroluje, jestli se název aktuální větve rovná vydané verzi.

V YAML použijete syntaxi svislé čáry (|) k definování řetězce, který zahrnuje více řádků. Podmínku byste mohli definovat na jednom řádku, ale tímto způsobem ji zapíšeme, aby byla lépe čitelná.

Poznámka:

V tomto modulu jako příklad používáme větev vydané verze . 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í aktivuje žádost o přijetí změn proti hlavní větvi.

V další lekci, když nastavíte fázi vývoje , budete pracovat s úplnějším příkladem.

Podrobnější popis podmínek ve službě Azure Pipelines najdete v dokumentaci 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 artefakt sestavení pro jakoukoli změnu, abychom ověřili sestavení a potvrdili, že je v pořádku. Až budeme připraveni, můžeme tyto změny sloučit do větve vydané verze a zvýšit úroveň 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 testovací fázi jako další? Zdá se, že je to správné místo pro mě, abych si otestování nejnovějších změn.

Mara přidá testovací fázi do své kresby na tabuli.

Diagram that shows the whiteboard illustrating build, dev and test stages. The Test stage deploys the build to Azure App Service.

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 nikdy nevím, kdy skočit. Myslím, že bych chtěla vidět build jednou denně, možná když se dostanu do kanceláře. Můžeme to udělat?

Andy: 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 kresbu, aby ukázala, že se build přesune z fáze vývoje do testovací fáze v 3:00 ráno.

Diagram that shows the whiteboard showing Build, Dev, and Test stages. The schedule promotes the change from Dev to Test at 3 A.M. each morning.

Co jsou triggery?

Amita: Teď se cítím lépe, když víme, jak se jedna fáze přesune do druhé. Jak ale řídíme, kdy se fáze spustí?

Mara: V Azure Pipelines můžeme použít triggery. Trigger definuje, kdy se fáze spustí. Azure Pipelines poskytuje několik typů triggerů. Tady jsou naše volby:

  • Trigger kontinuální integrace (CI)
  • Trigger žádosti o přijetí 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 výraz cron například popisuje "3 A.M. 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,
  • Spuštění úlohy

Pokud chcete zadat 3 A.M. pouze ve dnech 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 můžete chtít upravit čas v plánu cron vzhledem k času UTC tak, aby se kanál spustil v očekávaném čase pro vás a váš tým.

Pokud chcete nastavit naplánovaný trigger v Azure Pipelines, potřebujete schedules v souboru YAML oddíl. 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:

  • cron určuje výraz cron.
  • branches určuje, že se má nasadit jenom z release větve.
  • alwaysurčuje, jestli se má nasazení spouštět bezpodmínečně (true), nebo pouze v případech, kdy release se větev od posledního spuštění změnila.false Tady zadáte false , protože je potřeba nasadit jenom v případě, že release se větev od posledního spuštění změnila.

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 se spustí pouze v případě, Testže předchozí fáze proběhne úspěšně a předdefinovaná Build.Reason proměnná kanálu se Schedulerovná .

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ě připravené.

Andy: A nezapomeňte, že pokud chceme později automatizovat více, můžeme. Nic není napsané v kamene. Kanál se vyvíjí při vylepšování a učení.

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é fázi, ve které můžeme demo pro správu získat jejich schválení. Prozatím můžeme tyto dvě potřeby zkombinovat do fáze, kterou můžeme volat přípravný.

Andy: Řekl jsem, 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á do své kresby na tabuli přípravnou přípravu.

Diagram where the whiteboard is showing the Build, Dev, Test, and Staging stages. The Staging stage deploys the build to Azure App Service.

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 zvýšit úroveň změn z testování na pracovní? Musí se tato propagace provádět také podle plánu?

Mara: Myslím, že nejlepší způsob, jak to zvládnout, by to bylo schválení vydané verze. Schválení verze umožňuje ručně zvýšit úroveň změny z jedné fáze na další.

Amita: To zní přesně tak, 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 výkres, aby ukázala, že se build přesune z testovacího do přípravného prostředí, jenom když ji Amita schválí.

Diagram where the whiteboard shows the Build, Dev, Test, and Staging stages. Changes move from Test to Staging only after approval.

Tim: Mohl bych si představit, že po odhlášení vedení 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 odhlášení můžu schválit verzi a ručně ji povýšit na produkční. Jak ale schválení verzí funguje?

Co jsou schválení verzí?

Schválení verze je způsob, jak kanál pozastavit, dokud schvalovatel verzi přijme nebo odmítne. Pokud chcete definovat pracovní postup vydávání verzí, můžete zkombinovat schválení, podmínky a triggery.

Vzpomeňte si, že v části Vytvoření kanálu verze pomocí Azure Pipelines jste definovali prostředí v konfiguraci kanálu, které představuje vaše prostředí nasazení. Tady je příklad z existujícího kanálu:

- 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é kanály se můžou do daného prostředí nasadit a jaké schválení člověka je potřeba k povýšení vydané verze z jedné fáze na 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 Game ztestovací fáze do přípravné fáze.

Automatizace tak malého nebo tolik, kolik 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 kanálu jsme ale definovali nějaká ruční kritéria. Myslel jsem, že DevOps je o automatizaci všeho.

Mara: Vyvoláte dobrý bod. 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í 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ž 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 kanál verze, který chceme sestavit.

Mara ukazuje na tabuli.

Diagram of the final whiteboard showing the Build, Dev, Test, and Staging stages.

Mara: Abychom mohli shrnout, máme následující kroky:

  1. Při každém nasdílení změn do GitHubu vytvoří artefakt sestavení. K tomuto kroku dochází ve fázi sestavení .
  2. 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.
  3. 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.
  4. 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 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 kanálu 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. Vydání nikdy neměníme uprostřed kanálu. 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 pak prochází kanálem od samého začátku.

Pár slov o kvalitě

Právě jste viděli, že tým navrhuje kanál, který přenese aplikaci celou cestu od sestavení až po přípravu. Celým bodem tohoto kanálu není jen usnadnění jejich života. Je potřeba zajistit kvalitu softwaru, který dodává svým zákazníkům.

Jak změříte kvalitu procesu vydávání? Kvalitu procesu vydávání nejde 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ě selžou v určitém bodě kanálu, můžou také znamenat, že došlo k potíží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 kanálu provádět všechny druhy kontrol. Při spouštění kanálu můžete například spouště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 brány pracovních položek můžou ověřit kvalitu procesu 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 sledovatelnost?

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. Generátor 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.

Prověřte si své znalosti

1.

Kanál obsahuje mnoho testů a kontrol kvality, které dokončení trvá několik minut. Jaký typ triggeru je nejvhodnější pro spouštění testů pouze u kódu, který byl zkontrolován peerem?

2.

Jaký je nejlepší způsob, jak kanál pozastavit, dokud se schvalovatel nepřihlásí ke změně?

3.

Webovou aplikaci chcete nasadit do testovacího prostředí při každém dokončení sestavení. Jaký je nejjednodušší způsob nastavení procesu?