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

Platí pro toto doporučení kontrolního seznamu provozní efektivity architektury Azure Well-Architected Framework:

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 zajistili předvídatelnou 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 možná máte několik kanálů, které se řídí stejnými procesy a používají stejné nástroje.

Zabudujte dodavatelský řetězec, který chrání vaše úlohy před poškozením, ke kterému může dojít, když změny úloh nespravujete správně. Vždy mějte na paměti stav vaší úlohy, takže nemáte riziko nepředvídatelného chování. Tato riziková sloučenina se v případě, že potřebujete věnovat kritickou dobu retracování neúčtovaných změn v případě, že dojde k problémům. Pokud chcete tato rizika minimalizovat, standardizujte procesy a nástroje, které definují váš dodavatelský řetězec, a ujistěte se, že se váš tým úloh plně zavazuje k jejich použití.

Definice

Klíčové strategie návrhu

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

Vynucení striktních zásad automatizovaných nasazení založených na šablonách

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

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

Nasazení opakovatelné a neměnné infrastruktury jako kódu

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 stejný zdrojový kód měl při každém kompilaci vygenerovat stejný binární soubor. Podobně model IaC generuje stejné prostředí při každém použití.

Zahrňte IaC, abyste zajistili, že váš tým dodržuje standardní a dobře zavedený proces. Některé organizace určují jednu nebo malou skupinu jednotlivců pro nasazení a konfiguraci infrastruktury. Při implementaci plně automatizovaného procesu vyžadují nasazení infrastruktury méně správy od jednotlivců. Odpovědnost se přenese do procesu automatizace a nástrojů. Členové týmu můžou zahájit nasazení infrastruktury, aby zachovali konzistenci a kvalitu.

Navrhněte úlohu jako logickou skupinu komponent, které můžete seskupit do jedné šablony, aby bylo nasazení snadné a opakovatelné. Tyto balíčky si můžete představit jako razítka nebo jednotky škálování. 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 ve 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. Do kanálů IaC zahrňte síťové komponenty, abyste zajistili, že se vaše razítka nasazení automaticky připojí k existujícím prostředkům.

Pokud chcete optimalizovat kanál IaC pro zajištění konzistence a efektivity, navrhněte neměnnou infrastrukturu místo proměnlivé infrastruktury. Implementujte neměnnou infrastrukturu, aby se zajistilo, že všechny systémy v oboru budou nahrazeny aktualizovanou konfigurací současně a identicky s každým nasazením.

Použití stejné sady artefaktů nasazení ve všech prostředích

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

Pokud chcete řídit náklady, je obvykle rozdíl mezi produkčním a neprodukčním prostředím. Často nepotřebujete stejný stupeň redundance a výkonu v neprodukčních prostředích jako v produkčním prostředí. Počet a skladová položka vašich prostředků se můžou mezi prostředími lišit. Ujistěte se, že řídíte odchylku a rozumíte jí pomocí standardizovaných parametrů, abyste při provádění změn zachovali předvídatelnost.

Odráží organizační strukturu v dodavatelském řetězci.

Reflektujte organizační strukturu v návrhu dodavatelského řetězce a kanálu. Vaše organizace může být vysílaná 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 aplikací, testování a nasazení. V některých organizacích jsou týmy pro vývoj a infrastrukturu začleněné do týmů DevOps, které společně spravují všechna 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 k zajištění co nejefektivnějšího dodavatelského řetězce.

Váš dodavatelský řetězec se může spoléhat na dodavatele třetích stran, pokud zadáváte části životního cyklu úloh. Tito dodavatelé jsou stejně důležití pro úspěch dodavatelského řetězce jako interní prostředky. Ujistěte se, že existují vzájemné dohody mezi všemi týmy o procesech a nástrojích, které používáte.

Volba správné metody nasazení

Standardizujte metodu nasazení. Promluvte si s vlastníkem produktu o přijatelném množství výpadků produkčního prostředí pro vaši úlohu. V závislosti na tom, kolik výpadků je přijatelné, můžete zvolit metodu nasazení, která je pro vaše požadavky správná. V ideálním případě byste měli během časového období údržby provádět nasazení, abyste snížili složitost a riziko. Pokud není žádný výpadek přijatelný, zaužte metodu nasazení s modrou zelenou barvou.

Pomocí progresivního přístupu k expozici můžete snížit riziko zavedení nedetekovaných chyb pro vaše zákazníky ve velkém. Tato metoda se také označuje jako kanárské nasazení, nasadí se do kontrolovaných skupin uživatelů v postupném pořadí. Zachytává problémy dříve, než ovlivní více uživatelů. Počáteční skupina zavedení může být pododdílem vašich zákazníků, kteří o strategii zavedení vědí. Tento pododdíl zákazníků může tolerovat určité množství neočekávaného chování a poskytnout zpětnou vazbu. Nebo to může být skupina interních uživatelů, která pomáhá obsahovat poloměr výbuchu chyb během zavádění.

Když definujete metodu nasazení, přijměte standardní zásadu, která bude nasazovat pouze nejmenší realizovatelnou změnu v každém nasazení. 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ší realizovatelná změna je obvykle nasazení prostředků s nejnovější konfigurací, která nahradí prostředky, které používají předchozí verzi. Pokud používáte proměnlivou infrastrukturu, můžete se rozhodnout, že nejmenší realizovatelná změna je pouze jedna aktualizace skupiny prostředků v oboru.

Sledování vícevrstvého přístupu

Postupujte podle vícevrstvého přístupu, abyste odráželi různé životní cyklus. Základní vrstvy by měly zůstat statické v průběhu většiny životního cyklu úloh a vrstvy aplikací se často mění. Pokud chcete tyto rozdíly zohlednit, měli byste mít různé kanály, které budou mít vliv na změny v jednotlivých vrstvách.

Cílová zóna je na 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 topologie sítí. Cílová zóna umožňuje snadno nasazovat a spravovat úlohy a poskytuje centrální provozní týmy nebo týmy platforem s opakovatelným přístupem ke konfiguraci prostředí. Pro 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 správného řízení spolu s demokratizací 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 příchozí a výchozí síťové řadiče, 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 občasné významné změny. Můžou ale vyžadovat časté aktualizace konfigurace.

Vaše aplikace a datová vrstva vyžadují časté aktualizace konfigurace a časté změny infrastruktury. Tyto komponenty by měly mít nejmálnější kanály.

Začlenění komplexních typů testování

Plánování holistické strategie testování Základním principem spolehlivosti systému je princip posunu doleva . Vývoj a nasazení aplikace je proces, který je znázorněný jako řada kroků 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 brzy. Mohou být nákladné nebo nemožné opravit později v životním cyklu aplikace.

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 pomocí 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 automatizované testování k zajištění konzistence. 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ýt 100 procent kódu a běžet do 30 sekund.

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

  Použití testů jednotek u všech prostředků kódu, včetně šablon a skriptů

• Orientační testování: Orientační testy ověřují, že úloha může být v testovacím prostředí zastavěná a funguje podle očekávání. Orientační testy neověřují interoperabilitu součástí.

  Orientační testy ověřují, že funguje metodologie nasazení infrastruktury a aplikace a že systém reaguje podle očekávání po dokončení procesu.

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

  Spuštění rozsáhlé integrační sady 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. Zarezervujte 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é testovací scénáře využívají ruční 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á. Testování přijetí určuje, jestli softwarový systém splňuje specifikace požadavků.

  Hlavním účelem tohoto testu je vyhodnotit dodržování obchodních požadavků systému a určit, jestli systém splňuje požadovaná kritéria pro doručování koncovým uživatelům.

Implementace bran kvality v procesech povýšení kódu

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 to prostřednictvím vyšších prostředí, jako je příprava a produkční prostředí. Při průchodu nasazením branami kvality se ujistěte, že splňuje vaše cíle kvality, než se změní do produkčního prostředí. Vaše obchodní požadavky určují, jaký je zaměření bran kvality. Zvažte také základní principy dobře architektuře: zabezpečení, spolehlivost a efektivita výkonu.

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

Usnadnění azure

Azure DevOps je kolekce služeb, které vám pomůžou vytvořit efektivní a konzistentní vývojový postup pro spolupráci.

Azure Pipelines poskytuje služby sestavení a vydávání, které podporují CI/CD ve vašich aplikacích.

GitHub Actions pro Azure se integruje s Azure, aby se zjednodušilo nasazení. Pomocí GitHub Actions můžete automatizovat procesy CI/CD. Můžete vytvářet pracovní postupy, které sestavují a testují všechny žádosti o přijetí změn do úložiště nebo nasazují 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 vašeho týmu s nástroji můžete pro nasazení a správu prostředků použít jeden nebo více těchto nástrojů.

Příklad

Příklad, který ukazuje, jak pomocí Azure Pipelines sestavit kanál CI/CD, najdete v základní architektuře Azure Pipelines.

Související odkazy

• Azure DevOps
• Azure Pipelines
• Model razítka nasazení
• GitHub Actions pro Azure
• Pilíř efektivity výkonu
• Pilíř spolehlivosti
• Pilíř zabezpečení

Kontrolní seznam pro efektivitu operací

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