Doporučení ohledně návrhu dodavatelského řetězce pro vývoj úlohy
Platí pro toto doporučení Power Platform Dobře architektonizovaného kontrolního seznamu provozní dokonalosti:
| OE:06 | Vybudujte dodavatelský řetězec úlohy, který řídí navrhované změny prostřednictvím předvídatelných, automatizovaných kanálů. Kanály testují a podporují tyto změny napříč prostředími. Optimalizujte dodavatelský řetězec, aby vaše pracovní zatížení bylo spolehlivé, bezpečné, nákladově efektivní a výkonné. |
|---|
Tato příručka popisuje doporučení ohledně návrhu dodavatelského řetězce pro vývoj úlohy, který je založen na kanálech kontinuální integrace a průběžného doručování (CI/CD). V cloudových úlohách je dodavatelský řetězec standardizovanou sadou nástrojů a procesů, které používáte k ovlivnění konfigurace a změn úlohy napříč prostředími. Vytvořte dodavatelský řetězec, abyste zajistili, že budete mít předvídatelnou, standardizovanou metodu údržby své úlohy. Kanály CI/CD jsou projevem dodavatelského řetězce, ale měli byste mít jediný dodavatelský řetězec. Můžete mít několik kanálů, které se řídí stejnými procesy a používají stejné nástroje.
Zaveďte dodavatelský řetězec, který ochrání vaši úlohu před poškozením, ke kterému může dojít, když správně nespravujete změny úlohy. Vždy si uvědomujte stav své pracovní zátěže, abyste nebyli vystaveni riziku nepředvídatelného chování. Toto riziko se zvyšuje, pokud potřebujete strávit kritický čas sledováním nezodpovězených změn, když nastanou problémy. Chcete-li tato rizika minimalizovat, standardizujte procesy a nástroje, které definují dodavatelský řetězec, a zajistěte, aby jej tým pro úlohu plně používal.
Klíčové strategie návrhu
Následující doporučení vám mohou pomoci definovat základní principy vašeho dodavatelského řetězce.
Provádějte navrhované změny úlohy prostřednictvím procesů a nástrojů dodavatelského řetězce. Vynucujte přísné zásady automatizovaného nasazení založeného na šablonách. Tato metoda pomáhá zajistit, že konfigurace vaší úlohy ve všech prostředích je standardizovaná, dobře definovaná a přísně kontrolovaná. U prostředí v řetězci pro propagaci kódu neprovádějte aktualizace pomocí ručních procesů nebo lidské interakce. Všechny změny prostředí začleňte prostřednictvím kanálu podle postupů nasazení, které definujete. Abyste lépe vynutili tuto zásadu, jako výchozí nastavte přístup pouze pro čtení a přístup pro zápis umožněte prostřednictvím brány ověřování.
Důležitým aspektem této zásady je, že všechny změny jsou navrhované změny, dokud nejsou nasazeny do provozu. Prostřednictvím automatizovaného testování, jako je testování integrace a orientační testování, umožníte dodavatelskému řetězci automaticky odmítat změny.
Použijte jednu sadu zdrojů kódu a artefaktů ve všech prostředích a kanálech. Společným problémem organizací je, když se neprovozní prostředí liší od provozního. Ruční vytváření provozních a neprovozních prostředí může vést k nesouladu konfigurací mezi prostředími. Tento nesoulad zpomaluje testování a zvyšuje pravděpodobnost, že změny mohou poškodit provozní systém.
V návrzích dodavatelského řetězce a kanálů odrážejte organizační strukturu. Vaše organizace může být rozdělena na sila mezi týmy. Každý tým může spravovat část dodavatelského řetězce. Mnoho organizací má například týmy, které spravují nastavení zabezpečení a dodržování předpisů nebo konfigurace prostředí. Tyto týmy jsou oddělené od vývojových týmů, které spravují vývoj, testování a nasazení aplikací. Existuje mnoho způsobů, jak organizovat týmy, které jsou zapojeny do dodavatelského řetězce. Váš dodavatelský řetězec závisí na bezproblémové spolupráci všech týmů. Zajistěte, aby všechny týmy dodržovaly standardní procesy a používali standardní nástroje, aby byl dodavatelský řetězec co nejúčinnější.
Váš dodavatelský řetězec se může spoléhat na dodavatele třetích stran, pokud outsourcujete části životního cyklu pracovní zátěže. Tito dodavatelé jsou pro úspěch vašeho dodavatelský řetězec stejně důležití jako interní zdroje. Ujistěte se, že mezi všemi týmy existuje vzájemná shoda ohledně procesů a nástrojů, které používáte.
Standardizujte způsob nasazení. Promluvte si s vlastníkem produktu o přijatelném rozsahu prostojů ve výrobě pro vaši úlohu. V závislosti na tom, jak velké prostoje jsou přijatelné, jestli vůbec nějaké, můžete zvolit metodu nasazení, která je vhodná pro dané požadavky. V ideálním případě byste nasazení měli provádět během časového období údržby, abyste snížili složitost a rizika.
Naplánujte si holistickou testovací strategii. Základním principem spolehlivosti systému je princip „posunout doleva“. Vývoj a nasazení aplikace je proces, který je znázorněn jako série kroků zleva doprava. Testování byste neměli omezovat na konec procesu. Pokud je to možné, posuňte testování na začátek, neboli doleva. Oprava chyb je levnější, když je zachytíte brzy. Mohou být drahé nebo nemožné je opravit později během životního cyklu aplikace.
Pokud je to možné, používejte automatické testování pro 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ějí jako součást rutiny nepřetržité 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. Použijte testy jednotek na všechny zdroje kódu, včetně šablon a skriptů.
Kouřové testování: Kouřové testy ověřují, že zátěž lze v testovacím prostředí vydržet a funguje podle očekávání. Orientační testy neověřují interoperabilitu komponent. Orientační testy ověřují, že metodika nasazení pro infrastrukturu a aplikaci funguje a že systém po dokončení procesu reaguje tak, jak bylo zamýšleno.
Testování integrace: Testy integrace zajišťují, že komponenty aplikace fungují samostatně, a poté zjišťují, zda mohou komponenty vzájemně interagovat, jak by měly. Spuštění rozsáhlé sady pro testování integrace může trvat značné množství času. Proto je nejlepší začlenit princip shift-left a provádět testování na začátku životního cyklu vývoje softwaru. Testy integrace si rezervujte pro situace, kdy nemůžete provádět orientační test nebo test jednotky. V případě potřeby můžete v pravidelných intervalech spouštět dlouhotrvající testovací procesy. Pravidelný interval nabízí dobrý kompromis a odhalí problémy s interoperabilitou mezi komponentami aplikace nejpozději jeden den po jejich zavedení. Některé testovací scénáře fungují lépe při ručním spuštění. Ruční testování použijte, když potřebujete do testů zavést prvky lidské interaktivity.
Akceptační testování: V závislosti na kontextu můžete ručně provést akceptační testování. Může být částečně nebo plně automatizováno. Testování přijetí určuje, zda softwarový systém splňuje specifikace požadavků. Hlavním účelem tohoto testu je vyhodnotit shodu systému s obchodními požadavky a určit, zda systém splňuje požadovaná kritéria pro doručení uživatelům.
Implementujte brány kvality do celého procesu propagace kódu prostřednictvím testování. Nasaďte svůj kód do nižších prostředí, jako je kontrola a testování kvality, a do vyšších prostředí, jako je příprava a provoz. Když vaše nasazení prochází branami kvality, zajistěte, aby splňovalo cíle kvality, než se změny dostanou do výroby. Obchodní požadavky určují, na co se zaměřují brány kvality. Zvažte také základní Power Platform dobře navržené principy: bezpečnost, spolehlivost a výkonnost.
Do bran kvality integrujte také schvalovací pracovní postupy. V případě potřeby jasně definujte a automatizujte pracovní postupy schvalování. Definujte do své automatizace kritéria přijatelnosti kvality, abyste se mohli svými branami pohybovat efektivně a bezpečně.
Usnadnění dáky Power Platform
Pipelines in Power Platform si klade za cíl demokratizovat správu životního cyklu aplikací (ALM) pro zákazníky Power Platform a Dynamics 365 tím, že do služby přinášejí automatizaci ALM a průběžnou integraci a nepřetržité doručování (CI/CD).
Microsoft Power Platform Build Tools for Azure DevOps lze použít k automatizaci běžných úloh sestavování a nasazení souvisejících s aplikacemi postavenými na Power Platform.
Akce GitHub pro Power Platform umožňují vývojářům vytvářet automatizované pracovní postupy životního cyklu vývoje softwaru. Pomocí GitHub Actions pro Microsoft Power Platform můžete ve svém úložišti vytvářet pracovní toky pro sestavování, testování, balení, vydávání a nasazování aplikací, provádět automatizaci nebo spravovat roboty a další vestavěné komponenty na Power Platform.
ALM Accelerator je nástroj s otevřeným zdrojovým kódem, který se skládá ze sady aplikací, skriptů a kanálů navržených k automatizaci procesu nepřetržité integrace/průběžného doručování.
Automatizujte testy pomocí Azure Pipelines.
Power Apps checker Web API poskytuje mechanismus pro spouštění kontrol statické analýzy proti přizpůsobením a rozšířením platformy Microsoft Dataverse .
Microsoft Power Platform CLI (PAC CLI) je nástroj příkazového řádku, který podporuje import a export Power Platform řešení a sbalení do a rozbalení ze zdrojových souborů Power Platform řešení. PAC CLI je k dispozici jako samostatný nástroj příkazového řádku nebo jako rozšíření pro Visual Studio Kód.
Terraform, Bicep a Azure Resource Manager můžete použít pro neměnná nasazení infrastruktury jako kódu (IaC). V závislosti na vašich požadavcích a znalostech vašeho týmu ohledně těchto nástrojů můžete pro nasazení a správu prostředků použít jeden nebo více z nich.
Organizační sladění
Cloud Adoption Framework poskytuje pokyny pro centrální týmy, jak zajistit cílové zóny vaší úlohy. Přistávací zóny pracovního zatížení jsou místa, kam vlastní dodavatelský řetězec nasazuje aplikace.
Další informace naleznete v části Co je přistávací zóna Azure? a Principy návrhu přistávací zóny Azure.