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í klíčové řady úloh architektury Azure Well-Architected Framework. Pokud tuto řadu neznáte, doporučujeme začít s tím, co je kritická úloha?

Nasazení nulového výpadku

Podívejte se na následující video s přehledem nasazení nulového 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.

Pokud chcete dosáhnout nasazení nulového výpadku, nasaďte novou infrastrukturu vedle stávající infrastruktury, důkladně ji otestujte, přenosy 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 pro klíčové nasazení Online a Azure Mission-Critical Connected znázorňují 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 podřízená bezpečnostní zařízení, jako jsou brány firewall a zdrojová umístění 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 prostředí ve vyhrazeném předplatném s kontextovou sadou 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ávají stejné, ale všechna data, včetně monitorování a protokolování, potřebují zvláštní správu. 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áte jasnou hranici zásad správného řízení pro produkční a nižší 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í, které obsluhuje uživatelský provoz v produkčním prostředí. Zelené nasazení je nová, která je připravená a otestovaná pro příjem 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í je pak možné vyřadit z provozu prostřednictvím postupné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.

Azure Mission-Critical doporučuje přístup modrého/zeleného 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 oproti infrastruktuře a koncovému ukončení aplikace před přesměrováním uživatelského provozu na něj. 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.

Aspekty návrhu

• Technologické možnosti. Využijte integrované funkce nasazení ve službách Azure. Například služba Aplikace Azure poskytuje sekundární sloty nasazení, které je možné po nasazení prohodit. 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 všech komponent, které nefungují podle očekávání, přepíše obavy 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čí.

• Přechod 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 razítek pokaždé vytvoří nové zahájení před zřízením prostředků.

Doporučení k návrhu

• Přijměte přístup modrého/zeleného nasazení k 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 jednotlivými oblastmi nasazení jako s dočasným životním cyklem, který je svázaný s jednou verzí.

• 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 nízký objem provozu v zeleném nasazení funguje a poskytuje očekávaný stav aplikace, postupně zvyšte provoz. Během toho použijte krátkou dobu odsud, 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é a nyní neaktivní modré prostředí. Pro další nasazení opakujte proces s modrou a zelenou obrácenou barvou.

Nasazení s vymezeným předplatným

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, že aktualizace nižšího prostředí znečišťují výrobu tím, že poskytují jasnou hranici 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 problémem během místního procesu vývojáře ( vnitřní smyčka) a jako součást kompletního životního cyklu DevOps ( vnější smyčky), což je, když kód začíná na cestě od procesů kanálu 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ů.

Test	Popis
Testování jednotek	Potvrzuje, že obchodní logika aplikace funguje podle očekávání. Ověří celkový účinek změn kódu.
Orientační 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 vertikálně navyšte kapacitu výpočetních prostředků systému a sledujte, jak se chová při zatížení, a určete, jestli se může obnovit.
Testování výkonu	Kombinuje aspekty zátěžového a zátěžového testování za účelem ověření výkonu při zatížení a stanovení chování srovnávacích testů pro provoz aplikace.
Chaos testing	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ů s kontrolou a monitorováním známých běžných ohrožení zabezpečení a ohrožení (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 řídit verze spolu s dalšími artefakty kódu aplikace.

• Zarovnejte smlouvu SLA testovací infrastruktury se smlouvou SLA pro cykly nasazení a testování.

• V rámci každého nasazení spusťte orientační 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 experimenty chaosu a testy injektáže selhání ve stejnou dobu jako zátěžové testy.

  Tip

  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.

• Prohledejte a monitorujte kompletní softwarový dodavatelský řetězec a závislosti balíčků pro 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) zpracovává definice infrastruktury jako zdrojový kód, který se řídí verzí řízenou 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 operace převzetí služeb při selhání a škálování můžou záviset na automatizaci, kterou poskytují nástroje DevOps. Technické týmy musí porozumět vlivu nedostupnosti služby nasazení s ohledem na celkovou úlohu. 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á. Oblast 1 automaticky zpracovává veškerý provoz a potřebuje nasadit další jednotky škálování, aby poskytovala dobré prostředí převzetí služeb při selhání. Nebude ale možné ji kvůli závislosti Azure DevOps v oblasti 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 nebo aktivního nasazení, se ujistěte, že operace orchestrace převzetí služeb při selhání a škálování můžou fungovat i v případě, že primární oblast hostující sady nástrojů 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 provádět ve feature/* větvích a fix/* ve větvích. 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í. Umožňuje například správcům vytvářet větve vydaných verzí nebo vynucovat zásady vytváření názvů pro větve.

• Zrychlený proces pro nouzové situace. Strategie větvení by měla umožňovat sloučení main oprav hotfix, jakmile bude praktické. 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 a vydané verze funkcí, a použijte zásady a oprávnění větví k zajištění vhodného vynucení strategie.

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

• Zacházet s main větví jako s průběžným přesouváním a stabilní větví, 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í žádosti o přijetí mainzměn by se mělo automaticky spustit nasazení v prostředí integrace.
  • Větev by měla být považována main za stabilní. V daném okamžiku by mělo být bezpečné vytvořit uvolnění.main

• Používejte vyhrazené release/* větve vytvořené 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 ve větvi opravy hotfix fix/* pro následné sloučení do větve vydané verze 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, načítání (ETL), nemusí být schopné škálovat propustnost, aby se zachoval růst telemetrie nasazení a dat pozorovatelnosti 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, které jsou s podporou kontextu a závislostí, aby poskytovaly předpovědi automatizovaného inženýrství funkcí pro řešení změn 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í