Doporučení pro návrh dodavatelského řetězce pro vývoj úloh

  • Článek

Platí pro toto doporučení kontrolního seznamu pro efektivitu provozu azure Well-Architected Framework:

OE:06 Vytvořte dodavatelský řetězec úloh, který řídí navrhované změny prostřednictvím předvídatelných automatizovaných kanálů. Kanály tyto změny testují a propagují v různých prostředích. Optimalizujte dodavatelský řetězec, aby vaše úlohy byly spolehlivé, zabezpečené, nákladově efektivní a výkonné.

Tato příručka popisuje doporučení pro návrh dodavatelského řetězce vývoje úloh, který je založený na kanálech kontinuální integrace a průběžného doručování (CI/CD). Vytvořte dodavatelský řetězec, abyste měli jistotu, že máte předvídatelnou a standardizovanou metodu údržby úloh. Kanály CI/CD jsou projevem dodavatelského řetězce, ale měli byste mít jeden dodavatelský řetězec. A můžete mít několik kanálů, které se řídí stejnými procesy a používají stejné nástroje.

Začlenění dodavatelského řetězce pro ochranu úloh před poškozením, ke kterému může dojít, když správně neřídíte změny úloh. Vždy mějte na paměti stav úlohy, abyste nebyli ohroženi nepředvídatelným chováním. Toto riziko se sčítá v případě, že potřebujete věnovat kritickou dobu odpočtu změn, když dojde k problémům. Pokud chcete tato rizika minimalizovat, standardizujte procesy a nástroje, které definují váš dodavatelský řetězec, a zajistěte, aby se váš tým úloh plně zavázal k jejich použití.

Definition

Období Definice
Dodavatelský řetězec V cloudových úlohách je dodavatelský řetězec standardizovanou sadou nástrojů a procesů, které používáte k ovlivnění změn infrastruktury a aplikací v různých prostředích.

Klíčové strategie návrhu

Poznámka

Doporučení v této příručce odkazují na prostředí úloh v řetězu povýšení kódu. Sandbox nebo jiná průzkumná prostředí a prostředí pro testování konceptu vyžadují menší přísnost a strukturu.

Základní principy

Následující doporučení vám můžou pomoct definovat základní principy vašeho dodavatelského řetězce.

Proveďte navrhované změny úloh prostřednictvím procesů a nástrojů dodavatelského řetězce. Vynucujte striktní zásady automatizovaných nasazení založených na šablonách. Tato metoda pomáhá zajistit, aby konfigurace úloh ve všech prostředích byla standardizovaná, dobře definovaná a úzce řízená. V prostředích v řetězu povýšení kódu neprovádějte aktualizace pomocí ručních procesů nebo lidské interakce s řídicí rovinou cloudové platformy, například portálem nebo rozhraním API. Začleňte všechny změny prostředí prostřednictvím kanálu pomocí postupů nasazení, které definujete. Pokud chcete tyto zásady vynutit, zvažte jako výchozí omezení přístupu jen pro čtení a použití autorizační brány přístupu k povolení přístupu k zápisu.

Důležitým aspektem této verze je, že všechny změny jsou navrhovanézměny , dokud se nenasadí do produkčního prostředí. Prostřednictvím automatizovaného testování, jako je integrace a testování kouře, umožníte dodavatelskému řetězci automaticky odmítnout změny.

Nasaďte opakovatelnou a neměnnou infrastrukturu jako kód (IaC). IaC je správa infrastruktury v popisném modelu, který používá systém správy verzí, který zrcadlí zdrojový kód. Při vytváření aplikace by měl stejný zdrojový kód generovat stejný binární soubor pokaždé, když je zkompilován. Podobným způsobem model IaC generuje stejné prostředí při každém použití.

ZačleněníM IaC zajistíte, že váš tým bude postupovat podle standardního a dobře zavedeného procesu. Některé organizace určí pro nasazení a konfiguraci infrastruktury jednu osobu nebo malou skupinu jednotlivců. Při implementaci plně automatizovaného procesu vyžadují nasazení infrastruktury méně správy od jednotlivců. Odpovědnost se přenese na proces automatizace a nástroje. Členové týmu můžou iniciovat nasazení infrastruktury, aby zachovali konzistenci a kvalitu.

Navrhněte úlohu jako logickou skupinu komponent, které můžete sbalit do jedné šablony, aby bylo nasazení snadné a opakovatelné. Tyto svazky si můžete představit jako razítka nebo jednotky měřítka. Další informace najdete v tématu Model razítka nasazení. Pokud potřebujete nasadit úlohu pro horizontální navýšení kapacity do jiné oblasti nebo zóny v rámci stejné oblasti, nasaďte razítko pomocí kanálu. V závislosti na tom, jak navrhujete razítka, můžete místo celé úlohy nasadit podmnožinu úloh. Zahrnutím síťových komponent do kanálů IaC zajistíte, že se razítka nasazení automaticky připojí k existujícím prostředkům.

Pokud chcete kanál IaC optimalizovat z hlediska konzistence a efektivity, navrhněte neměnnou infrastrukturu místo proměnlivé infrastruktury. Implementujte neměnnou infrastrukturu, abyste zajistili, že všechny systémy v oboru budou nahrazeny aktualizovanou konfigurací současně a shodně s každým nasazením.

Použijte jednu sadu prostředků kódu a artefaktů ve všech prostředích a kanálech. Častou bolestí pro organizace je, když se neprodukční prostředí liší od produkčních prostředí. Ruční sestavování produkčního a neprodukčního prostředí může vést k neshodě konfigurací mezi prostředími. Tato neshoda zpomaluje testování a pravděpodobnější, že změny můžou poškodit produkční systém. Přístup IaC tyto problémy minimalizuje. Pokud používáte automatizaci IaC, můžete použít stejné konfigurační soubory infrastruktury pro všechna prostředí a vytvořit téměř identická prostředí. Do konfiguračních souborů infrastruktury můžete přidat parametry a upravit je tak, aby splňovaly požadavky jednotlivých prostředí.

Pro řízení nákladů je obvykle rozdíl mezi produkčním a neprodukčním prostředím. V neprodukčních prostředích často nepotřebujete stejný stupeň redundance a výkonu jako v produkčním prostředí. Počet a skladová položka prostředků se můžou v jednotlivých prostředích lišit. Pomocí standardizovaných parametrů, které vám pomůžou zachovat předvídatelnost při provádění změn, se ujistěte, že řídíte odchylku a rozumíte jí.

Promítněte svou organizační strukturu do návrhu dodavatelského řetězce a kanálů. Vaše organizace může být v silech mezi týmy. Každý tým může spravovat část dodavatelského řetězce. Mnoho organizací má například týmy, které spravují domény infrastruktury, jako jsou sítě, data a výpočetní prostředky. Tyto týmy jsou oddělené od vývojových týmů, které spravují vývoj, testování a nasazení aplikací. V některých organizacích jsou vývojové týmy a týmy infrastruktury začleněné do týmů DevOps, které společně spravují veškerá nasazení infrastruktury a aplikací. Existuje mnoho způsobů, jak uspořádat týmy, které jsou zapojeny do dodavatelského řetězce. Váš dodavatelský řetězec spoléhá na bezproblémovou spolupráci všech týmů. Zajistěte, aby všechny týmy dodržovaly standardní procesy a používaly standardní nástroje, aby byl dodavatelský řetězec co nejefektivnější.

Pokud outsourcujete části životního cyklu úloh, může se váš dodavatelský řetězec spoléhat na dodavatele třetích stran. Tito dodavatelé jsou pro úspěch vašeho dodavatelského řetězce stejně důležití jako interní zdroje. Ujistěte se, že všechny týmy vzájemně souhlasí s procesy a nástroji, které používáte.

Standardizujte metodu nasazení. Spojte se s vlastníkem produktu o přijatelném množství výpadků v produkčním prostředí pro vaši úlohu. V závislosti na tom, do jaké míry jsou případné výpadky přijatelné, můžete zvolit metodu nasazení, která odpovídá vašim požadavkům. V ideálním případě byste měli nasazení provádět během časového období údržby, abyste snížili složitost a riziko. Pokud není přijatelný žádný výpadek, použijte modrozelenou metodu nasazení.

Použití progresivního přístupu ke snížení rizika zavedení nezjištěných chyb u vašich zákazníků. Tato metoda se také označuje jako nasazení kanárů a postupně se nasazuje do řízených skupin uživatelů. Zachytává problémy dříve, než ovlivní více uživatelů. Skupina počátečního uvedení může být dílčí částí vašich zákazníků, kteří vědí o strategii zavedení. Tato dílčí část zákazníků může tolerovat určité množství neočekávaného chování a poskytovat zpětnou vazbu. Nebo se může jednat o skupinu interních uživatelů, která pomáhá obsahovat poloměr výbuchu chyb během zavádění.

Když definujete metodu nasazení, použijte standardní zásadu, která v každém nasazení nasadí jenom nejmenší schůdnou změnu. V závislosti na faktorech, jako je závažnost úlohy a složitost komponent, určete nejmenší realizovatelnou změnu. Pokud používáte neměnnou infrastrukturu, nejmenší schůdnou změnou je obvykle nasazení prostředků s nejnovější konfigurací, která nahradí prostředky, na kterých běží předchozí verze. Pokud používáte proměnlivou infrastrukturu, můžete se rozhodnout, že nejmenší schůdnou změnou je pouze jedna aktualizace skupiny prostředků v oboru.

Postupujte podle vrstvených přístupů, které odrážejí různé životní cykly. Základní vrstvy by měly zůstat statické po celou většinu životního cyklu úloh a aplikační vrstvy se často mění. Pokud chcete tyto rozdíly zohlednit, měli byste mít různé kanály, které budou mít na každé vrstvě vliv na změny.

Cílová zóna je v nejnižší vrstvě. Cílová zóna je logické seskupení základních prvků, jako jsou předplatná, skupiny pro správu, skupiny prostředků, funkce zásad správného řízení a síťová topologie. Cílová zóna umožňuje snadno nasazovat a spravovat úlohy a poskytuje centrálním provozním týmům nebo týmům platforem opakovatelný přístup ke konfiguraci prostředí. Za účelem zajištění konzistentních prostředí poskytují všechny cílové zóny Azure sadu společných oblastí návrhu, referenční architekturu, referenční implementaci a proces úprav nasazení tak, aby vyhovoval vašim požadavkům na návrh. Principy návrhu cílové zóny Azure poskytují doporučené postupy založené na zásadách zásad správného řízení a demokratizaci předplatného. Cílová zóna by měla v průběhu životního cyklu úloh vyžadovat minimální změny. Příklad cílové zóny najdete v tématu Co je cílová zóna Azure. Tato koncepční architektura poskytuje sadu názorů doporučených pro Azure.

Vaše základní infrastruktura a funkce, jako jsou síťové adaptéry příchozího a odchozího přenosu dat, vyrovnávání zatížení, řešení směrování sítě, správa DNS a základní servery, by také měly vyžadovat méně závažné změny. Můžou ale vyžadovat časté aktualizace konfigurace.

Vaše aplikační a datová vrstva vyžaduje časté aktualizace konfigurace a časté změny infrastruktury. Tyto komponenty by měly mít nejdynamičtější kanály.

Naplánujte strategii holistického testování. Základní princip spolehlivosti systému je princip posunu doleva . Vývoj a nasazení aplikace je proces, který je znázorněn jako řada kroků, které jdou zleva doprava. Testování byste neměli omezovat na konec procesu. Co nejvíce posunujte testování na začátek nebo doleva. Chyby jsou levnější opravit, když je chytáte včas. Jejich oprava může být v průběhu životního cyklu aplikace nákladná nebo nemožná.

Otestujte veškerý kód, včetně kódu aplikace, šablon infrastruktury a konfiguračních skriptů. Prostředí, ve kterém běží aplikace, by mělo být řízeno verzí a nasazeno prostřednictvím stejných mechanismů jako kód aplikace. Prostředí můžete otestovat a ověřit pomocí stejných testovacích paradigmat, která už vaše týmy používají pro kód aplikace.

Pokud je to možné, použijte k zajištění konzistence automatizované testování. Do návrhu dodavatelského řetězce zahrňte následující typy testování.

  • Testování jednotek: Testy jednotek se obvykle spouští jako součást rutiny kontinuální integrace. Testy jednotek by měly být rozsáhlé a rychlé. V ideálním případě by měly pokrývat 100 procent kódu a běžet za méně než 30 sekund.

    Implementujte testování částí, abyste ověřili, že syntaxe a funkce jednotlivých modulů kódu fungují tak, jak by měly, například vytvoření definovaného výstupu pro známý vstup. Testy jednotek můžete také použít k ověření platnosti prostředků IaC.

    Použijte testy jednotek na všechny prostředky kódu, včetně šablon a skriptů.

  • Orientační testování: Orientační testy ověřují, že je možné úlohu v testovacím prostředí odsud nastavit a že funguje podle očekávání. Orientační testy neověřují interoperabilitu komponent.

    Orientační testy ověřují, že metodologie nasazení pro infrastrukturu a aplikaci funguje a že systém po dokončení procesu reaguje zamýšleným způsobem.

  • Testování integrace: Integrační testy zajišťují, že komponenty aplikace fungují jednotlivě, a pak určí, jestli spolu můžou interagovat tak, jak by měly.

    Spuštění velké sady testů integrace může trvat poměrně dlouho. Proto je nejlepší začlenit princip posunu doleva a provést testování v rané fázi životního cyklu vývoje softwaru. Vyhraďte si integrační testy pro scénáře, které nemůžete testovat pomocí orientačního testu nebo testu jednotek.

    V případě potřeby můžete spouštět dlouhotrvající testovací procesy v pravidelných intervalech. Pravidelný interval nabízí dobrý kompromis a detekuje problémy s interoperabilitou mezi komponentami aplikace nejpozději jeden den po jejich zavedení.

    Některé scénáře testování těží z ručních spuštění. Ruční testování použijte, když potřebujete do testů zavést prvky lidské interaktivity.

  • Testování přijetí: V závislosti na kontextu můžete ručně provést akceptační testování. Může být částečně nebo plně automatizovaná. Akceptační testování určuje, jestli softwarový systém splňuje požadavky.

    Hlavním účelem tohoto testu je vyhodnotit soulad systému s obchodními požadavky a určit, jestli systém splňuje požadovaná kritéria pro doručení koncovým uživatelům.

Implementujte brány kvality v celém procesu povýšení kódu prostřednictvím testování. Nasaďte kód do nižších prostředí, jako je vývoj a testování, a až do vyšších prostředí, jako jsou přípravné a produkční prostředí. Když vaše nasazení prochází branami kvality, před přechodem změn do produkčního prostředí se ujistěte, že splňuje vaše cíle kvality. Vaše obchodní požadavky určují, na co se zaměřuje vaše brány kvality. Zvažte také základní principy architektury Well-Architected: zabezpečení, spolehlivost a efektivita výkonu.

Integrujte také pracovní postupy schvalování do bran kvality. V případě potřeby jasně definujte a automatizujte pracovní postupy schvalování. Definujte do své automatizace kritéria přijetí kvality, abyste mohli procházet branami efektivně a bezpečně.

Usnadnění Azure

Azure DevOps je kolekce služeb, které vám pomůžou vytvářet postupy pro spolupráci, efektivní a konzistentní vývoj.

Azure Pipelines poskytuje služby sestavení a vydání pro podporu CI/CD ve vašich aplikacích.

GitHub Actions for Azure se integruje s Azure, aby se zjednodušila nasazení. K automatizaci procesů CI/CD použijte GitHub Actions. Můžete vytvářet pracovní postupy, které sestavují a testují každou žádost o přijetí změn do vašeho úložiště, nebo můžete nasadit sloučené žádosti o přijetí změn do produkčního prostředí.

Pro nasazení IaC můžete použít Terraform, Bicep a Azure Resource Manager. V závislosti na vašich požadavcích a znalosti nástrojů vašeho týmu můžete pro nasazení a správu prostředků použít jeden nebo více z těchto nástrojů.

Příklad

Příklad, který ukazuje, jak použít Azure Pipelines k vytvoření kanálu CI/CD, najdete v tématu Základní architektura azure Pipelines.

Kontrolní seznam k efektivitě operací

Projděte si kompletní sadu doporučení.

Kontrolní seznam efektivity provozu