Vývoj řízený testy pro cílové 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 vytvoří testovací případy jednotek před vývojem skutečného kódu a otestuje kód proti testovacím případům. Tento přístup není na rozdíl od vývoje kódu nejprve a vytvoření testovacích případů později.
Cílová zóna je prostředí pro hostování úloh předem zřízených 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.
Rozbalte a refaktorujte cílovou 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. Kvalita kódu a údržba se však sdílí. 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 cílovou 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 červeným testem na základě definice hotovou a definovaných kritérií přijetí. Pro každou funkci nebo kritéria přijetí tým cloudové platformy dokončí úlohy vývoje, dokud test neprojde, nebo nemá zelený test.
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 akčních informací během vývoje cílové zóny nebo refaktoringu. 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šíří všechny cílové zóny, měli by získat přehled o definici hotovou (DoD) pro každou cílovou zónu.
DoD je jednoduchá smlouva mezi týmem cloudové platformy a dalšími ovlivněnými týmy, které definují očekávané funkce přidané hodnotou, které se mají zahrnout do úsilí o vývoj cílové zóny. DoD je často kontrolní seznam, který je v souladu 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 doD a kritéria přijetí 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 přidané hodnotou splňují kritéria přijetí, cílová zóna je dostatečně nakonfigurovaná tak, aby umožňovala úspěch aktuální vlny přijetí nebo vydání.
Příklad jednoduchého doD
U počátečního úsilí o migraci může být doD příliš jednoduché. Následující příklad je jednoduchý doD:
Počáteční cílová zóna bude hostovat 10 úloh pro účely počáteční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ání a označování schématu pro snadné použití
- Během přechodu může dočasný přístup týmu přechodu na cloud změnit konfigurace služeb.
- Před produkčním vydáním se integrací s zprostředkovatelem podnikové identity můžete řídit průběžnou identitu a přístup ke správě operací. V té době by měl být přístup týmu přechodu na cloud odvolán.
Poslední bod není kritériem pro funkci nebo přijetí, ale indikátor, že se bude vyžadovat další rozšíření a mělo by se prozkoumat s ostatními týmy dříve.
Složitější příklady DoD
Metodologie řízení v rámci architektury přechodu na cloud poskytuje příběh o přirozené vyspělosti týmu zásad správného řízení. Do této cesty je vloženo několik příkladů kritérií pro doD a přijetí ve formě prohlášení o zásadách.
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, které řídí doD, aby splňovaly požadavky 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í správy operací Příklad podnikových zásad, které řídí doD, aby splňovaly základní požadavky na správu provozu
Přírůstková 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 doD pro cílové zóny. Můžete získat ukázkové zásady pro každou z pěti disciplín zásad správného řízení v cloudu.
Nástroje a funkce Azure pro podporu TDD cílové zóny
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 rychlého startu Azure poskytují šablony zdrojového kódu, které pomáhají zrychlit 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 obsahuje integrované 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 integrované iniciativy zásad, které můžete použít k otestování a vynucování ú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 cílová zóna splňuje doD, azure Policy může vynutit testovací kritéria, aby se zabránilo změnám kódu, které by způsobily selhání testu v budoucích verzích.
Návrh a kontrola pracovních postupů Azure Policy jako kódu v rámci 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:
- Nasaďte cílové zóny pomocí Terraformu.
- Nasaďte cílové zóny pomocí Bicep.
- Správa cílových zón pomocí AzOps, modulu PowerShellu, který odesílá šablony prostředků a soubory Bicep na všech úrovních oboru Azure, a načítá a exportuje hierarchie prostředků Azure.