Vývoj řízený testy pro přistávací zóny Azure
Vývoj řízený testy (TDD) je proces vývoje softwaru a DevOps, který zlepšuje kvalitu nových funkcí a vylepšení v řešeních založených na kódu. TDD vytváří jednotkové testy před vývojem samotného kódu a testuje kód proti těmto testům. Tento přístup je v rozporu s nejprve vývojem kódu a vytvořením testovacích případů později.
Cílová zóna je prostředí pro hostování úloh, které je předem zřízeno prostřednictvím kódu. Cílové zóny zahrnují základní funkce, které používají definovanou sadu cloudových služeb a osvědčené postupy. Tento článek popisuje přístup, který používá TDD k nasazení úspěšných cílových zón při plnění požadavků na kvalitu, zabezpečení, provoz a zásady správného řízení.
Cloudová infrastruktura je výstupem spouštění kódu. Dobře strukturovaný, testovaný a ověřený kód vytváří realizovatelnou cílovou zónu. Cloudová infrastruktura a základní zdrojový kód můžou tento přístup použít k zajištění vysoké kvality cílových zón a splnění základních požadavků.
Tento přístup použijte ke splnění jednoduchých požadavků na funkce během raného vývoje. Později v životním cyklu přechodu na cloud můžete tento proces použít ke splnění požadavků na zabezpečení, provoz, zásady správného řízení nebo dodržování předpisů. Tento proces je užitečný zejména pro vývoj a refaktoring cílových zón v rámci paralelního vývoje.
Vývojový cyklus řízený testy
Následující diagram znázorňuje vývojový cyklus řízený testy pro cílové zóny Azure:
Vytvořte test. Definujte test, který ověří splnění kritérií přijetí pro funkci. Automatizujte test při vývoji, abyste snížili množství ručního testování, zejména pro nasazení na podnikové úrovni.
Otestujte cílovou zónu. Spusťte nový test a všechny existující testy. Pokud požadovaná funkce není zahrnutá v nabídkách poskytovatele cloudu a nebyla poskytována předchozím úsilím o vývoj, měl by test selhat. Spuštění existujících testů pomáhá ověřit, že nová funkce nebo test nezmenšuje spolehlivost stávajících funkcí cílové zóny.
Rozšiřte a přestavte vylodovací zónu. Přidejte nebo upravte zdrojový kód tak, aby splňoval požadovanou funkci přidání hodnoty a zlepšila obecnou kvalitu základu kódu.
Aby tým cloudové platformy splnil kritéria TDD, přidal kód pouze pro splnění požadované funkce. Úsilí o kvalitu kódu a údržbu je však sdílené. Při plnění nových požadavků na funkce by se tým cloudové platformy měl pokusit vylepšit kód odebráním duplicit a objasněním kódu. Spouštění testů mezi vytvořením nového kódu a refaktoringem zdrojového kódu se důrazně doporučuje.
Nasaďte přistávací zónu. Jakmile zdrojový kód splní požadavek na funkci, nasaďte upravenou cílovou zónu poskytovateli cloudu v řízeném testovacím nebo sandboxovém prostředí.
Otestujte cílovou zónu. Znovu otestujte cílovou zónu a ověřte, že nový kód splňuje kritéria přijetí požadované funkce. Po splnění všech testů se funkce považuje za dokončenou a kritéria přijetí se považují za splněná.
Cyklus TDD opakuje předchozí základní kroky, dokud nesplní úplnou definici dokončení . Když všechny funkce přidané hodnotou a kritéria přijetí projdou souvisejícími testy, cílová zóna je připravená podporovat další vlnu plánu přechodu na cloud.
Cyklus, díky kterému je TDD efektivní, se často označuje jako červený/zelený test. V tomto přístupu tým cloudové platformy začíná neúspěšným testem, nebo-li červeným testem, na základě definice hotového a definovaných kritérií přijetí. Pro každou funkci nebo akceptační kritéria tým cloudové platformy dokončí úlohy vývoje, dokud test není úspěšný nebo není označen zeleně.
Cílem TDD je vyřešit lepší návrh, ne vytvořit sadu testů. Testy jsou cenným artefaktem pro dokončení procesu.
Definice dokončení
Úspěch může být subjektivním měřítkem, které týmu cloudové platformy poskytuje málo praktických informací během vývoje cílové zóny nebo refaktorování. Nedostatek srozumitelnosti může vést ke zmeškaným očekáváním a ohrožením zabezpečení v cloudovém prostředí. Než tým cloudové platformy refaktoruje nebo rozšíří jakékoli cílové zóny, měli by si ujasnit definici dokončení (DoD) pro každou z nich.
DoD je jednoduchá smlouva mezi týmem cloudové platformy a dalšími ovlivněnými týmy, která definuje očekávané funkce s přidanou hodnotou, které se mají zahrnout do vývojového úsilí přistávací zóny. DoD je často kontrolním seznamem, který je sladěný s krátkodobým plánem přechodu na cloud.
S tím, jak týmy přijímají více úloh a cloudových funkcí, jsou ministerstvo obrany a kritéria akceptace stále složitější. Ve vyspělých procesech mají očekávané funkce vlastní kritéria přijetí, aby byly přehlednější. Když všechny funkce s přidanou hodnotou splňují kritéria přijetí, přistávací zóna je dostatečně nakonfigurovaná tak, aby umožňovala úspěch aktuální přijímací vlny nebo verze vydání.
Příklad jednoduchého DoD
U počátečního úsilí o migraci může být DoD příliš zjednodušené. Následující příklad je jednoduchý DoD.
Počáteční přistávací zóna bude hostovat 10 úloh pro účely úvodního učení. Tyto úlohy nejsou pro firmu důležité a nemají přístup k citlivým datům. V budoucnu se tyto úlohy pravděpodobně uvolní do produkčního prostředí, ale důležitost a citlivost se neočekává, že se změní.
Aby tým přechodu na cloud tyto úlohy podporoval, musí splňovat následující kritéria:
- Segmentace sítě tak, aby odpovídala navrhovanému návrhu sítě. Toto prostředí by mělo být hraniční sítí s přístupem k veřejnému internetu.
- Přístup k výpočetním, úložným a síťovým prostředkům pro hostování úloh v souladu se zjišťováním digitálních aktiv.
- Pojmenovávací a značkovací systém pro snadné použití
- Během přechodu má tým zodpovědný za přechod na cloud dočasný přístup ke změně konfigurací služeb.
- Před uvedením do produkce se integrací se zprostředkovatelem podnikové identity můžete řídit průběžnou správu identity a přístupu pro řízení operací. V té době by měl být přístup týmu přechodu na cloud odvolán.
Poslední poznámka není funkcí nebo kritériem přijetí, ale indikátorem, že bude nutné další rozšíření a mělo by být prozkoumáno s ostatními týmy co nejdříve.
Složitější příklady DoD
Metodologie Govern v rámci Cloud Adoption Framework přináší cestu příběhem přirozeného dospívání týmu pro řízení. Do této cesty je zabudováno několik příkladů kritérií DoD a kritérií pro přijetí ve formě politických prohlášení.
počáteční prohlášení o zásadách. Příklad počátečního doD založeného na podnikových zásadách, které řídí požadavky na přijetí v rané fázi
Přírůstková vylepšení pro rozšířenísprávy identit. Příklad podnikových zásad řídících Ministerstvo obrany pro splnění požadavků na rozšíření správy identit pro cílovou zónu.
Přírůstková vylepšení pro rozšíření požadavků na zabezpečení. Příklad podnikových zásad, které řídí doD, aby splňovaly požadavky na zabezpečení v souladu s referenčním plánem přechodu na cloud
Přírůstková vylepšení ke rozšíření správy operací. Příklad podnikových zásad, které řídí doD, aby splňovaly základní požadavky na správu provozu
Postupná vylepšení pro rozšířenísprávy nákladů . Příklad firemních zásad, které řídí DoD, aby splňovaly požadavky na správu nákladů.
Předchozí příklady jsou základní ukázky, které vám pomůžou s vývojem Definice hotového stavu (DoD) pro přistávací zóny.
Nástroje a funkce Azure pro podporu přistávací zóny TDD
Následující diagram znázorňuje dostupné vývojové nástroje řízené testy v Azure:
Tyto nástroje a funkce Azure můžete snadno integrovat do TDD pro vytvoření cílové zóny. Nástroje slouží ke konkrétním účelům, což usnadňuje vývoj, testování a nasazování cílových zón v souladu s cykly TDD.
Azure Resource Manager poskytuje konzistentní platformu pro procesy sestavení a nasazení. Platforma Resource Manageru může nasadit cílové zóny na základě definic zdrojového kódu.
šablony Azure Resource Manageru (ARM) poskytují primární zdrojový kód pro prostředí nasazená v Azure. Některé nástroje třetích stran, jako je Terraform, poskytují vlastní šablony ARM pro odeslání do Azure Resource Manageru.
šablony Azure Pro rychlý start poskytují šablony zdrojového kódu, které pomáhají urychlit nasazení cílové zóny a úloh.
Azure Policy poskytuje primární mechanismus pro testování kritérií přijetí ve vašem doD. Azure Policy může také poskytovat automatizované zjišťování, ochranu a řešení v případě, že se nasazení odchylují od zásad správného řízení.
V cyklu TDD můžete vytvořit definici zásady pro otestování jednoho kritéria přijetí. Azure Policy zahrnuje předdefinované definice zásad, které můžou splňovat jednotlivá kritéria přijetí v rámci doD. Tento přístup poskytuje mechanismus pro červené testy před úpravou cílové zóny.
Azure Policy také zahrnuje předdefinované iniciativy zásad, které můžete použít k otestování a prosazení úplného DoD pro cílovou zónu. Všechna kritéria přijetí můžete přidat do iniciativy zásad přiřazené celému předplatnému. Jakmile přistávací zóna splňuje požadavky DoD, Azure Policy může prosadit testovací kritéria, aby se zabránilo změnám kódu, které by způsobily selhání testu v budoucích verzích.
Navrhněte a zkontrolujte Azure Policy jako pracovní postupy kódu jako součást vašeho přístupu TDD.
Azure Resource Graph poskytuje dotazovací jazyk pro vytváření testů řízených daty na základě informací o prostředcích nasazených v cílové zóně. Později v plánu přechodu může tento nástroj také definovat složité testy na základě interakcí mezi prostředky úloh a základním cloudovým prostředím.
Resource Graph obsahuje pokročilé ukázky dotazů, které můžete použít k pochopení toho, jak se úlohy nasazují v cílové zóně pro pokročilé scénáře testování.
V závislosti na preferovaném přístupu můžete také použít následující nástroje:
- Nasadit cílové zóny pomocí Terraformu.
- Nastavení přistávacích zón pomocí Bicep.
- Spravujte cílové zóny pomocí AzOps, modulu PowerShell, který odesílá šablony prostředků a soubory Bicep na všech úrovních rozsahu Azure a načítá a exportuje hierarchie prostředků Azure.