Nasazení a testování důležitých úloh v Azure

Selhání nasazení a chybná vydání jsou běžnými příčinami výpadků aplikací. Váš přístup k nasazení a testování hraje důležitou roli v celkové spolehlivosti klíčové aplikace.

Nasazení a testování by mělo tvořit základ pro všechny operace aplikací a infrastruktury, aby se zajistily konzistentní výsledky pro klíčové úlohy. Připravte se na nasazení týdně, denně nebo častěji. Navrhněte kanály kontinuální integrace a průběžného nasazování (CI/CD), aby tyto cíle podporovaly.

Strategie by měla implementovat:

• Důkladné předběžné testování. Aktualizace by neměly zavádět chyby, ohrožení zabezpečení ani jiné faktory, které by mohly ohrozit stav aplikace.

• Transparentní nasazení. Aktualizace by měly být kdykoli možné zavést, aniž by to mělo vliv na uživatele. Uživatelé by měli být schopni pokračovat v interakci s aplikací bez přerušení.

• Vysoce dostupné operace. Procesy a nástroje pro nasazení a testování musí být vysoce dostupné, aby podporovaly celkovou spolehlivost aplikací.

• Konzistentní procesy nasazení Stejné artefakty a procesy aplikace by se měly použít k nasazení infrastruktury a kódu aplikace v různých prostředích. Kompletní automatizace je povinná. Ručním zásahům se musíme vyhnout, protože mohou představovat rizika spolehlivosti.

Tato oblast návrhu poskytuje doporučení k optimalizaci procesů nasazení a testování s cílem minimalizovat výpadky a udržovat stav a dostupnost aplikace.

Důležité

Tento článek je součástí série zaměřené na kritické úlohy Azure Well-Architected Framework. Pokud nejste obeznámeni s touto sérií, doporučujeme začít s kapitolou Co je kritická úloha?

Nasazení bez výpadku

Podívejte se na následující video s přehledem nasazení bez výpadku.

Dosažení nasazení s nulovými výpadky je základním cílem pro klíčové aplikace. Vaše aplikace musí být k dispozici celý den, každý den, i když se nové verze nasadí během pracovní doby. Investujte své úsilí předem, abyste definovali a plánovali procesy nasazení, aby bylo možné řídit klíčová rozhodnutí o návrhu, jako je to, jestli se s prostředky zacházet jako s dočasnými prostředky.

Chcete-li dosáhnout nasazení bez výpadku, rozmístěte novou infrastrukturu vedle stávající infrastruktury, důkladně ji otestujte, přesměrujte provoz koncových uživatelů a teprve potom vyřaďte předchozí infrastrukturu z provozu. Klíčové jsou i další postupy, jako je architektura jednotek škálování.

Referenční implementace Mission-Critical Online a Azure Mission-Critical Connected ilustrují tento přístup k nasazení, jak je znázorněno v tomto diagramu:

Aplikační prostředí

Podívejte se na následující video s přehledem doporučení pro aplikační prostředí.

K ověření a fázi operací nasazení potřebujete různé typy prostředí. Typy mají různé možnosti a životní cyklus. Některá prostředí můžou odrážet produkční prostředí a být dlouhodobá a jiná můžou být krátkodobá a mají méně možností než produkční prostředí. Nastavení těchto prostředí v rané fázi vývojového cyklu pomáhá zajistit flexibilitu, oddělení produkčních a předprodukčních prostředků a důkladné testování operací před uvolněním do produkčního prostředí. Všechna prostředí by měla co nejvíce odrážet produkční prostředí, i když můžete podle potřeby použít zjednodušení na nižší prostředí. Tento diagram znázorňuje kritickou architekturu:

Existují některé běžné aspekty:

• Komponenty by se neměly sdílet napříč prostředími. Možné výjimky jsou bezpečnostní zařízení umístěná níže ve vrstvě, jako jsou brány firewall, a zdrojová místa pro syntetická testovací data.

• Všechna prostředí by měla používat artefakty infrastruktury jako kódu (IaC), jako jsou Terraform nebo šablony Azure Resource Manageru (ARM).

Vývojová prostředí

V následujícím videu najdete informace o dočasných vývojových prostředích a automatizovaném ověřování funkcí.

Aspekty návrhu

• Možnosti. Nižší požadavky na spolehlivost, kapacitu a zabezpečení jsou přijatelné pro vývojová prostředí.

• Životní cyklus. Vývojová prostředí by se měla vytvořit podle potřeby a měla by existovat po krátkou dobu. Kratší životní cyklus pomáhá zabránit posunu konfigurace od základu kódu a snížit náklady. Vývojová prostředí také často sdílejí životní cyklus větve funkcí.

• Hustota. Týmy potřebují více prostředí pro podporu paralelního vývoje funkcí. Můžou existovat společně v rámci jednoho předplatného.

Doporučení k návrhu

• Udržujte pracovní prostředí ve vyhrazeném předplatném s nastaveným kontextem pro účely vývoje.

• Pomocí automatizovaného procesu nasaďte kód z větve funkcí do vývojového prostředí.

Testovací nebo přípravná prostředí

Tato prostředí se používají k testování a ověřování. K zajištění nasazení bez chyb do produkčního prostředí se provádí mnoho testovacích cyklů. Vhodné testy pro kritickou úlohu jsou popsány v části Průběžné ověřování a testování .

Aspekty návrhu

• Možnosti. Tato prostředí by měla odrážet produkční prostředí pro spolehlivost, kapacitu a zabezpečení. Bez produkčního zatížení použijte syntetické uživatelské zatížení k poskytování realistických metrik a hodnotného vstupu modelování stavu .

• Životní cyklus. Tato prostředí jsou krátkodobá. Po dokončení ověření testu by se měly zničit.

• Hustota. V jednom předplatném můžete spouštět mnoho nezávislých prostředí. Měli byste také zvážit použití více prostředí, z nichž každý je ve vyhrazeném předplatném.

Poznámka:

Důležité aplikace by měly být podrobeny důkladnému testování.

V jednom prostředí můžete provádět různé testovací funkce a v některých případech budete muset. Například pro testování chaosu, který poskytuje smysluplné výsledky, musíte nejprve umístit aplikaci pod zatížení, abyste pochopili, jak aplikace reaguje na vložené chyby. Proto se testování chaosu a zátěžové testování obvykle provádí paralelně.

Doporučení k návrhu

• Ujistěte se, že alespoň jedno přípravné prostředí plně odráží produkční prostředí, aby se umožnilo testování a ověřování podobné produkčnímu prostředí. Kapacita v tomto prostředí se může přizpůsobit na základě provádění testovacích aktivit.

• Vygenerujte syntetické uživatelské zatížení, abyste zajistili realistický testovací případ pro změny v jednom z prostředí.

  Poznámka:

  Referenční implementace Mission Critical Online poskytuje příklad generátoru zatížení uživatele.

• Definujte počet přípravných prostředí a jejich účel v rámci cyklu vývoje a vydávání.

Provozní prostředí

Aspekty návrhu

• Možnosti. Vyžadují se nejvyšší úrovně spolehlivosti, kapacity a zabezpečení aplikace.

• Životní cyklus. Životní cyklus úlohy a infrastruktury zůstává stejný, ale všechna data, včetně monitorování a protokolování, potřebují zvláštního řízení. Například správa se vyžaduje pro zálohování a obnovení.

• Hustota. U některých aplikací můžete chtít zvážit použití různých produkčních prostředí, aby vyhovovaly různým klientům, uživatelům nebo obchodním funkcím.

Doporučení k návrhu

Mějte jasnou hranici pro správu produkčního a neprodukčního prostředí. Každý typ prostředí umístěte do vyhrazeného předplatného, abyste tohoto cíle dosáhli. Tato segmentace zajišťuje, že využití prostředků v nižších prostředích nemá vliv na produkční kvóty. Vyhrazená předplatná také nastavují hranice přístupu.

Dočasné modré/zelené nasazení

Modrý/zelený model nasazení vyžaduje aspoň dvě identická nasazení. Modré nasazení je aktivním nasazením, které obsluhuje uživatelský provoz v produkčním prostředí. Zelené nasazení je to nové, které je připravené a otestované pro příjem datového provozu. Po dokončení a otestovaní zeleného nasazení se provoz postupně směruje z modré na zelenou. Pokud je přenos zatížení úspěšný, zelené nasazení se stane novým aktivním nasazením. Staré modré nasazení lze následně vyřadit z provozu prostřednictvím postupného, fázového procesu. Pokud ale v novém nasazení dojde k problémům, může se přerušit a provoz může zůstat ve starém modrém nasazení nebo se na něj přesměrovat.

Nepostradatelný návrh doporučuje modrý/zelený přístup k nasazení, kdy se infrastruktura a aplikace nasazují společně jako součást razítka nasazení. Proto zavedení změny infrastruktury nebo aplikace vždy vede k zelenému nasazení, které obsahuje obě vrstvy. Tento přístup vám umožní plně otestovat a ověřit účinek změny na infrastrukturu a aplikaci od začátku do konce, předtím, než na tuto změnu přesměrujete uživatelský provoz. Přístup zvyšuje důvěru při vydávání změn a umožňuje upgrady s nulovými výpadky, protože je možné ověřit kompatibilitu s podřízenými závislostmi, jako jsou platforma Azure, poskytovatelé prostředků a moduly IaC. Podrobnosti o konfiguraci najdete v průvodci službou Kubernetes Service.

Aspekty návrhu

• Technologické možnosti. Využijte integrované funkce nasazení ve službách Azure. Například Azure App Service poskytuje sekundární nasazovací sloty, které lze po nasazení vyměnit. Podrobnosti o konfiguraci najdete v průvodci službou App Service. Pomocí služby Azure Kubernetes Service (AKS) můžete na každém uzlu použít samostatné nasazení podu a aktualizovat definici služby.

• Doba trvání nasazení. Dokončení nasazení může trvat déle, protože razítko obsahuje infrastrukturu a aplikaci, a ne jenom změněnou komponentu. To je však přijatelné, protože riziko, že všechny součásti nebudou fungovat podle očekávání, převáží nad obavami o čas.

• Dopad na náklady Existují další náklady kvůli dvěma souběžným nasazením, která musí existovat společně, dokud se nasazení nedokončí.

• Změna dopravního provozu. Po ověření nového nasazení se provoz musí převést z modrého prostředí na zelený. Tento přechod vyžaduje orchestraci uživatelského provozu mezi prostředími. Přechod by měl být plně automatizovaný.

• Životní cyklus. Razítka nasazení kritická pro klíčové účely by se měla považovat za dočasné. Použití krátkodobých identifikátorů pokaždé vytvoří čerstvý začátek před zřízením prostředků.

Doporučení k návrhu

• Přijměte přístup modrého/zeleného nasazení pro uvolnění všech produkčních změn. Nasaďte veškerou infrastrukturu a aplikaci pokaždé pro jakýkoli typ změn, abyste dosáhli konzistentního stavu a nulového výpadku. I když můžete opakovaně používat prostředí, nedoporučujeme je pro klíčové úlohy. Zacházejte s každým razítkem regionálního nasazení jako s pomíjivým, jehož životní cyklus je svázán s jedním vydáním.

• Pomocí globálního nástroje pro vyrovnávání zatížení, jako je Azure Front Door, můžete orchestrovat automatizovaný přechod uživatelského provozu mezi modrým a zeleným prostředím.

• Pokud chcete převést provoz, přidejte zelený back-endový koncový bod, který používá nízký provoz k objemu, například 10 procent. Po ověření, že zelené nasazení při nízkém objemu provozu funguje a vykazuje očekávaný stav aplikace, postupně zvyšujte objem provozu. Během toho použijte krátkou záběhovou dobu, abyste zachytili chyby, které nemusí být okamžitě zřejmé.

  Po přechodu veškerého provozu odeberte modrý back-end ze stávajících připojení. Odeberte například back-end ze služby globálního nástroje pro vyrovnávání zatížení, vyprázdněte fronty a odpojte další přidružení. To pomáhá optimalizovat náklady na údržbu sekundární produkční infrastruktury a zajistit, aby nová prostředí byla bez posunu konfigurace.

  V tomto okamžiku vyřaďte staré modré prostředí, které je nyní neaktivní. Pro další nasazení opakujte proces s modrou a zelenou obrácenou barvou.

Nasazení v rámci předplatného

V závislosti na požadavcích na škálování vaší aplikace možná budete potřebovat několik produkčních předplatných, která budou sloužit jako jednotky škálování.

Podívejte se na následující video a získejte přehled doporučení pro určení rozsahu předplatných pro kritickou aplikaci.

Aspekty návrhu

• Škálovatelnost. V případě scénářů aplikací s velkými objemy provozu navrhujte řešení tak, aby se škálovalo napříč několika předplatnými Azure, aby omezení škálování jednoho předplatného neomezovalo škálovatelnost.

  Důležité

  Použití více předplatných vyžaduje další složitost CI/CD, kterou je potřeba správně spravovat. Proto doporučujeme více předplatných pouze ve scénářích extrémního rozsahu, kdy se limity jednoho předplatného pravděpodobně stanou omezením.

• Hranice prostředí. Nasaďte produkční, vývojová a testovací prostředí do samostatných předplatných. Tento postup zajišťuje, že nižší prostředí nepřispívají k limitům škálování. Snižuje také riziko znečištění produkčního prostředí aktualizacemi prostředí nižší úrovně poskytnutím jasné hranice správy a identity.

• Zásady správného řízení. Pokud potřebujete více produkčních předplatných, zvažte použití vyhrazené skupiny pro správu aplikací ke zjednodušení přiřazení zásad prostřednictvím hranice agregace zásad.

Doporučení k návrhu

• Nasaďte každé razítko místního nasazení ve vyhrazeném předplatném, abyste zajistili, že limity předplatného platí jenom v kontextu jednoho razítka nasazení, a ne v celé aplikaci. V případě potřeby můžete zvážit použití více razítek nasazení v rámci jedné oblasti, ale měli byste je nasadit napříč nezávislými předplatnými.

• Umístěte globální sdílené prostředky do vyhrazeného předplatného, abyste umožnili konzistentní místní nasazení předplatného. Nepoužívejte specializované nasazení pro primární oblast.

Průběžné ověřování a testování

Testování je kritická aktivita, která umožňuje plně ověřit stav kódu a infrastruktury aplikace. Konkrétně vám testování umožňuje splnit vaše standardy pro spolehlivost, výkon, dostupnost, zabezpečení, kvalitu a škálování. Testování musí být dobře definované a použité jako součást návrhu aplikace a strategie DevOps. Testování je klíčovým krokem v místním procesu vývojáře (ve vnitřní smyčce) a jako součást celého životního cyklu DevOps (ve vnější smyčce), kdy kód začíná cestu od procesů uvolnění verze směrem k produkčnímu prostředí.

Pokud chcete získat přehled o průběžném ověřování a testování, podívejte se na následující video.

Tato část se zaměřuje na testování vnější smyčky. Popisuje různé typy testů.

Zkouška	Popis
Testování jednotek	Potvrzuje, že obchodní logika aplikace funguje podle očekávání. Ověří celkový účinek změn kódu.
Prvotní testování	Určuje, jestli jsou komponenty infrastruktury a aplikací dostupné a fungují podle očekávání. Obvykle se testuje pouze jedna relace virtuálního uživatele. Výsledkem by mělo být, že systém reaguje očekávanými hodnotami a chováním. Mezi běžné scénáře orientačního testování patří dosažení koncového bodu HTTPS webové aplikace, dotazování databáze a simulace toku uživatele v aplikaci.
Testování uživatelského rozhraní	Ověří, že se nasazují uživatelská rozhraní aplikací a že interakce uživatelského rozhraní fungují podle očekávání. K řízení automatizace byste měli použít nástroje pro automatizaci uživatelského rozhraní. Během testu uživatelského rozhraní by měl skript napodobovat realistický uživatelský scénář a dokončit řadu kroků pro provedení akcí a dosažení zamýšleného výsledku.
Zátěžové testování	Ověří škálovatelnost a operaci aplikace rychlým zvýšením zatížení nebo postupně, dokud nedosáhnete předem stanovené prahové hodnoty. Zátěžové testy se obvykle navrhují kolem konkrétního toku uživatele, aby ověřily, že požadavky na aplikace jsou splněné v rámci definovaného zatížení.
Zátěžové testování	Použije aktivity, které přetíží existující prostředky, aby určily limity řešení a ověřily schopnost systému řádně obnovit. Hlavním cílem je identifikovat potenciální kritické body výkonu a omezení škálování. Naopak snižte kapacitu výpočetních prostředků systému a sledujte, jak se chová při zatížení, a určete, zda se může zotavit.
Testování výkonu	Kombinuje aspekty zátěžového a stresového testování za účelem ověření výkonu při zatížení a stanovení referenčního chování pro provoz aplikace.
Chaosové testování	Vloží do systému umělá selhání, aby vyhodnotila, jak reaguje, a ověřila efektivitu opatření odolnosti, provozních postupů a zmírnění rizik. Vypnutí komponent infrastruktury, účelné snížení výkonu a zavedení chyb aplikací jsou příklady testů, které se dají použít k ověření, že aplikace bude reagovat podle očekávání, když se scénáře skutečně objeví.
Testování průniku	Zajišťuje, aby aplikace a její prostředí splňovaly požadavky očekávaného stavu zabezpečení. Cílem je identifikovat ohrožení zabezpečení. Testování zabezpečení může zahrnovat kompletní softwarový dodavatelský řetězec a závislosti balíčků, přičemž zahrnuje skenování a monitorování známých Common Vulnerabilities and Exposures (CVE).

Aspekty návrhu

• Automatizace. Automatizované testování je nezbytné k včasnému a opakovatelnému ověřování změn aplikací nebo infrastruktury.

• Otestujte pořadí. Pořadí, ve kterém se testy provádějí, je zásadním aspektem z důvodu různých závislostí, jako je potřeba mít spuštěné aplikační prostředí. Doba trvání testu také ovlivňuje pořadí. Testy s kratší dobou spuštění by měly běžet dříve v cyklu, pokud je to možné, aby se zvýšila efektivita testování.

• Omezení škálovatelnosti Služby Azure mají různá měkká a pevná omezení. Zvažte použití zátěžového testování k určení, jestli systém při očekávaném produkčním zatížení riskuje, že je překročí. Zátěžové testování může být také užitečné pro nastavení vhodných prahových hodnot pro automatické škálování. U služeb, které nepodporují automatické škálování, vám zátěžové testování může pomoct vyladit automatizované provozní postupy.

  Neschopnost systémových komponent, jako jsou aktivní/pasivní síťové komponenty nebo databáze, aby bylo možné odpovídajícím způsobem škálovat, může být omezující. Zátěžové testování může pomoct identifikovat omezení.

• Analýza režimu selhání Zavedení chyb do aplikace a základní infrastruktury a vyhodnocení účinku je nezbytné k posouzení mechanismů redundance řešení. Během této analýzy identifikujte riziko, dopad a šířku dopadu (částečný nebo úplný výpadek). Příklad analýzy vytvořené pro referenční implementaci Mission Critical Online najdete v tématu Rizika výpadku jednotlivých komponent.

• Monitorování. Výsledky testů byste měli zachytit a analyzovat jednotlivě a také je agregovat, abyste mohli vyhodnotit trendy v průběhu času. Výsledky testů byste měli průběžně vyhodnocovat z hlediska přesnosti a pokrytí.

Doporučení k návrhu

V následujícím videu se dozvíte, jak je možné integrovat testování odolnosti s kanály CI/CD Azure DevOps.

• Zajistěte konzistenci tím, že automatizujete veškeré testování komponent infrastruktury a aplikací. Integrujte testy v kanálech CI/CD, abyste je mohli orchestrovat a spouštět tam, kde je to možné. Informace o možnostech technologie najdete v tématu Nástroje DevOps.

• Zachází se všemi testovacími artefakty jako s kódem. Měly by se udržovat a mít verze pod kontrolou spolu s ostatními součástmi kódu aplikace.

• Zarovnejte úroveň služeb SLA pro testovací infrastrukturu s úrovní služeb SLA pro cykly nasazení a testování.

• V rámci každého nasazení spusťte kouřové testy. Spusťte také rozsáhlé zátěžové testy spolu se zátěžovými a chaosovými testy, abyste ověřili, že je zachován výkon a funkčnost aplikace.

  • Použijte profily zatížení, které odrážejí skutečné vzory využití ve špičce.
  • Spusťte chaosové experimenty a testy injekce selhání ve stejnou dobu jako zátěžové testy.

  Návod

  Azure Chaos Studio je nativní sada nástrojů pro experimentování s chaosem. Nástroje usnadňují provádění experimentů chaosu a vkládání chyb v rámci služeb Azure a komponent aplikací.

  Chaos Studio poskytuje integrované experimenty s chaosem pro běžné scénáře chyb a podporuje vlastní experimenty, které cílí na infrastrukturu a komponenty aplikací.

• Pokud jsou pro zátěžové nebo orientační testy vyžadovány interakce databází, jako je vytváření záznamů, použijte testovací účty, které mají omezená oprávnění, a proveďte oddělení testovacích dat od skutečného uživatelského obsahu.

• Skenujte a monitorujte celý softwarový dodavatelský řetězec a závislosti balíčků na známé CVE.

  • Pomocí Dependabotu pro úložiště GitHub se ujistěte, že je úložiště automaticky aktuální s nejnovějšími verzemi balíčků a aplikací, na které závisí.

Infrastruktura jako nasazení kódu

Infrastruktura jako kód (IaC) chápe definice infrastruktury jako zdrojový kód, který je verzován společně s dalšími artefakty aplikace. Použití IaC podporuje konzistenci kódu napříč prostředími, eliminuje riziko lidské chyby během automatizovaných nasazení a poskytuje sledovatelnost a vrácení zpět. U modrých/zelených nasazení je imperativní použití IaC s plně automatizovanými nasazeními.

Klíčové úložiště IaC má dvě odlišné definice, které jsou namapované na globální a regionální prostředky. Informace o těchto typech prostředků najdete v základním vzoru architektury.

Aspekty návrhu

• Opakovatelná infrastruktura Nasaďte klíčové úlohy způsobem, který pokaždé generuje stejné prostředí. IaC by měla být primárním modelem.

• Automatizace. Všechna nasazení musí být plně automatizovaná. Lidské procesy jsou náchylné k chybám.

Doporučení k návrhu

• Použijte IaC a zajistěte, aby všechny prostředky Azure byly definovány v deklarativních šablonách a udržovány v úložišti správy zdrojového kódu. Šablony se nasazují a prostředky se zřídí automaticky ze správy zdrojového kódu prostřednictvím kanálů CI/CD. Nedoporučujeme používat imperativní skripty.

• Zakázat ruční operace ve všech prostředích. Jedinou výjimkou jsou plně nezávislá vývojová prostředí.

Nástroje DevOps

Efektivní použití nástrojů pro nasazení je důležité pro celkovou spolehlivost, protože procesy DevOps ovlivňují celkovou funkci a návrh aplikace. Například převzetí služeb při selhání a škálovací operace mohou záviset na automatizaci, kterou poskytují nástroje DevOps. Inženýrské týmy musí porozumět vlivu nedostupnosti služby nasazení s ohledem na celkové zatížení. Nástroje pro nasazení musí být spolehlivé a vysoce dostupné.

Microsoft poskytuje dvě sady nástrojů nativní pro Azure, GitHub Actions a Azure Pipelines, které můžou efektivně nasazovat a spravovat nepostradatelnou aplikaci.

Aspekty návrhu

• Technologické možnosti. Možnosti GitHubu a Azure DevOps se překrývají. Můžete je použít společně, abyste získali to nejlepší z obou. Běžným přístupem je ukládání úložišť kódu v GitHub.com nebo GitHubU AE při nasazování pomocí Azure Pipelines.

  Mějte na paměti složitost, kterou jste přidali při použití více technologií. Vyhodnoťte bohatou sadu funkcí oproti celkové spolehlivosti.

• Regionální dostupnost. Z hlediska maximální spolehlivosti představuje závislost na jedné oblasti Azure provozní riziko.

  Řekněme například, že provoz je rozložený do dvou oblastí: Region 1 a Region 2. Oblast 2 hostuje instanci nástrojů Azure DevOps. Předpokládejme, že v oblasti 2 došlo k výpadku a instance není dostupná. Region 1 automaticky zpracovává veškerý provoz a potřebuje nasadit další jednotky škálování pro zajištění kvalitního zajištění při selhání. Nebude to možné kvůli závislosti na Azure DevOps v regionu 2.

• Replikace dat. Data, včetně metadat, kanálů a zdrojového kódu, by se měla replikovat napříč oblastmi.

Doporučení k návrhu

• Obě technologie jsou hostované v jedné oblasti Azure, což může vyžadovat omezující strategii zotavení po havárii.

  GitHub Actions je vhodný pro úlohy sestavení (kontinuální integrace), ale může chybět funkce pro složité úlohy nasazení (průběžné nasazování). Vzhledem k bohaté sadě funkcí Azure DevOps ji doporučujeme pro důležitá nasazení. Po posouzení kompromisů byste si ale měli vybrat.

• Definujte smlouvu SLA o dostupnosti pro nástroje nasazení a zajistěte soulad s širšími požadavky na spolehlivost aplikací.

• V případě scénářů s více oblastmi, které používají konfiguraci aktivního/pasivního nebo aktivního/aktivního nasazení, se ujistěte, že operace orchestrací převzetí služeb při selhání a škálování mohou pokračovat i když primární oblast, která hostuje sady nástrojů pro nasazení, přestane být dostupná.

Strategie větvení

Existuje mnoho platných přístupů k větvení. Měli byste zvolit strategii, která zajišťuje maximální spolehlivost. Dobrá strategie umožňuje paralelní vývoj, poskytuje jasnou cestu od vývoje do produkčního prostředí a podporuje rychlé verze.

Aspekty návrhu

• Minimalizujte přístup. Vývojáři by měli svou práci dělat ve větvích feature/* a fix/*. Tyto větve se stanou vstupními body pro změny. Omezení založená na rolích by se měla použít u větví jako součást strategie větvení. Například povolit pouze správcům vytvářet vydávací větve nebo vynucovat dodržování pojmenovacích konvencí pro větve.

• Zrychlený proces pro nouzové situace. Strategie větvení by měla umožňovat, aby byly hotfixy sloučeny do main co nejdříve, jakmile to bude možné. Budoucí verze tak obsahují opravu a opakování problému se vyhnete. Tento proces použijte pouze u menších změn, které řeší naléhavé problémy, a používejte ho se omezením.

Doporučení k návrhu

• Určete prioritu použití GitHubu pro správu zdrojového kódu.

  Důležité

  Vytvořte strategii větvení, která podrobně popisuje práci na funkcích a verze vydání, a použijte pravidla větví a oprávnění k zajištění řádného dodržování strategie.

• Spusťte automatizovaný proces testování, abyste ověřili příspěvky ke změnám kódu před jejich přijetím. Členové týmu také musí zkontrolovat změny.

• Považovat main větev za pokračující vpřed a stabilní větev, která se primárně používá k testování integrace.

  • Ujistěte se, že se změny provádějí main jenom prostřednictvím žádostí o přijetí změn. K zákazu přímých potvrzení použijte zásadu větve.
  • Při každém sloučení PR do main by se mělo automaticky spustit nasazení proti integračnímu prostředí.
  • Větev main by měla být považována za stabilní. Mělo by být bezpečné vytvořit vydání z main v daném okamžiku.

• Používejte vyhrazené release/* větve, které jsou vytvořeny z main větve a slouží k nasazení do produkčních prostředí. release/* větve by měly zůstat v úložišti a je možné je použít k opravě vydané verze.

• Zdokumentujte proces opravy hotfix a použijte ho pouze v případě potřeby. Vytvořte hotfixy ve větvi fix/* pro následné sloučení do větve vydání a nasazení do produkčního prostředí.

AI pro DevOps

Metodologie AIOps můžete použít v kanálech CI/CD k doplnění tradičních testovacích přístupů. Díky tomu je možné detekovat potenciální regrese nebo snížení výkonu a umožnit, aby nasazení byla předem zastavena, aby se zabránilo potenciálním negativním dopadům.

Aspekty návrhu

• Objem telemetrických dat Kanály CI/CD a procesy DevOps generují širokou škálu telemetrických dat pro modely strojového učení. Telemetrie se pohybuje od výsledků testů a výsledků nasazení až po provozní data o součástech testů ze složených fází nasazení.

• Škálovatelnost. Tradiční přístupy ke zpracování dat, jako je extrakce, transformace a načítání (ETL), nemusí být schopné škálovat propustnost, aby se udržela rychlost růstu telemetrie nasazení systému a dat sledovatelnosti aplikací. K zajištění průběžné analýzy modelů AIOps můžete použít moderní analytické přístupy, které nevyžadují etL a přesun dat, jako je virtualizace dat.

• Změny nasazení Změny v nasazení je potřeba uložit pro automatizovanou analýzu a korelaci s výsledky nasazení.

Doporučení k návrhu

• Definujte data procesu DevOps, která se mají shromažďovat a jak je analyzovat. Telemetrie, jako jsou metriky spouštění testů a data časových řad změn v rámci každého nasazení, jsou důležitá.

  • Zveřejnění dat pozorovatelnosti aplikací z přípravných, testovacích a produkčních prostředí pro účely analýzy a korelace v rámci modelů AIOps

• Přijměte pracovní postup MLOps.

• Vyvíjejte analytické modely citlivé na kontext a závislosti, které poskytují předpovědi s automatizovaným zpracováním vlastností, aby řešily změny schématu a chování.

• Zprovoznění modelů registrací a nasazením nejlepších vytrénovaných modelů v rámci kanálů nasazení

Další krok

Projděte si důležité informace o zabezpečení.

Zabezpečení