Share via

Testdriven utveckling för Azure-landningszoner

  • Artikel

Testdriven utveckling (TDD) är en process för programvaruutveckling och DevOps som förbättrar kvaliteten på nya funktioner och förbättringar i kodbaserade lösningar. TDD skapar enhetstestfall innan den faktiska koden utvecklas och testar koden mot testfallen. Den här metoden motsätter sig att först utveckla kod och skapa testfall senare.

En landningszon är en miljö som är värd för arbetsbelastningar som företableras via kod. Landningszoner innehåller grundläggande funktioner som använder en definierad uppsättning molntjänster och metodtips. Den här artikeln beskriver en metod som använder TDD för att distribuera lyckade landningszoner samtidigt som kvalitet, säkerhet, åtgärder och styrningskrav uppfylls.

Molninfrastruktur är utdata från kodkörning. Välstrukturerad, testad och verifierad kod skapar en fungerande landningszon. Molnbaserad infrastruktur och dess underliggande källkod kan använda den här metoden för att säkerställa att landningszonerna håller hög kvalitet och uppfyller kärnkraven.

Använd den här metoden för att uppfylla enkla funktionsförfrågningar under tidig utveckling. Senare i molnimplementeringslivscykeln kan du använda den här processen för att uppfylla säkerhet, åtgärder, styrning eller efterlevnadskrav. Processen är särskilt användbar för att utveckla och omstrukturera landningszoner i en parallell utvecklingsinsats.

Testdriven utvecklingscykel

Följande diagram visar den testdrivna utvecklingscykeln för Azure-landningszoner:

Diagram över den testdrivna utvecklingsprocessen för Azure-landningszoner.

  1. Skapa ett test. Definiera ett test för att verifiera att godkännandevillkoren för en funktion har uppfyllts. Automatisera testet när du utvecklar för att minska mängden manuella testinsatser, särskilt för distributioner i företagsskala.

  2. Testa landningszonen. Kör det nya testet och eventuella befintliga tester. Om den nödvändiga funktionen inte ingår i molnleverantörens erbjudanden och inte har tillhandahållits av tidigare utvecklingsarbete bör testet misslyckas. Genom att köra befintliga tester kan du kontrollera att den nya funktionen eller testet inte minskar tillförlitligheten för befintliga funktioner i landningszonen.

  3. Expandera och omstrukturera landningszonen. Lägg till eller ändra källkoden för att uppfylla den begärda funktionen för värdetillägg och förbättra den allmänna kvaliteten på kodbasen.

    För att uppfylla TDD-kriterierna lägger molnplattformsteamet bara till kod för att uppfylla den begärda funktionen. Kodkvalitet och underhåll är dock delade insatser. När de uppfyller nya funktionsbegäranden bör molnplattformsteamet försöka förbättra koden genom att ta bort duplicering och förtydliga koden. Vi rekommenderar starkt att du kör tester mellan att skapa ny kod och omstrukturera källkoden.

  4. Distribuera landningszonen. När källkoden uppfyller funktionsbegäran distribuerar du den ändrade landningszonen till molnleverantören i en kontrollerad testnings- eller sandbox-miljö.

  5. Testa landningszonen. Testa landningszonen igen för att verifiera att den nya koden uppfyller godkännandevillkoren för den begärda funktionen. När alla tester har godkänts anses funktionen vara fullständig och godkännandekriterierna anses vara uppfyllda.

TDD-cykeln upprepar de föregående grundläggande stegen tills de uppfyller den fullständiga definitionen av klar. När alla mervärdesfunktioner och acceptanskriterier klarar sina associerade tester är landningszonen redo att stödja nästa våg av molnimplementeringsplanen.

Den cykel som gör TDD effektiv kallas ofta för ett rött/grönt test. I den här metoden börjar molnplattformsteamet med ett misslyckat test, eller ett rött test, baserat på definitionen av klar och de definierade acceptanskriterierna. För varje funktion eller godkännandevillkor slutför molnplattformsteamet utvecklingsuppgifter tills testet har godkänts eller har ett grönt test.

Målet med TDD är att hantera bättre design, inte att skapa en uppsättning tester. Testerna är en värdefull artefakt för att slutföra processen.

Definitionen av klar

Framgång kan vara ett subjektivt mått som ger ett molnplattformsteam lite användbar information under utveckling eller refaktorisering av landningszoner. Brist på klarhet kan leda till missade förväntningar och sårbarheter i en molnmiljö. Innan molnplattformsteamet omstrukturerar eller expanderar några landningszoner bör de söka klarhet om definitionen av klar (DoD) för varje landningszon.

DoD är ett enkelt avtal mellan molnplattformsteamet och andra berörda team som definierar de förväntade mervärdesfunktionerna som ska ingå i utvecklingsinsatsen för landningszonen. DoD är ofta en checklista som är anpassad till den kortsiktiga molnimplementeringsplanen.

I takt med att teamen inför fler arbetsbelastningar och molnfunktioner blir doD- och acceptanskriterierna mer komplexa. I mogna processer har de förväntade funktionerna var och en sina egna acceptanskriterier för att ge mer klarhet. När alla mervärdesfunktioner uppfyller godkännandekriterierna är landningszonen tillräckligt konfigurerad för att den aktuella implementeringsvågen eller versionen ska lyckas.

Exempel på enkel doD

För en inledande migrering kan doD vara alltför enkelt. Följande exempel är en enkel DoD:

Den första landningszonen är värd för 10 arbetsbelastningar i inledande utbildningssyfte. Dessa arbetsbelastningar är inte viktiga för företaget och har ingen åtkomst till känsliga data. I framtiden kommer dessa arbetsbelastningar förmodligen att lanseras i produktion, men kritiskheten och känsligheten förväntas inte ändras.

För att stödja dessa arbetsbelastningar måste molnimplementeringsteamet uppfylla följande kriterier:

  • Nätverkssegmentering för att anpassa till den föreslagna nätverksdesignen. Den här miljön bör vara ett perimeternätverk med åtkomst till det offentliga Internet.
  • Åtkomst till beräknings-, lagrings- och nätverksresurser som värd för arbetsbelastningarna som är anpassade till identifieringen av digital egendom.
  • Namngivnings- och taggningsschema för enkel användning.
  • Under implementeringen får molnimplementeringsteamet tillfällig åtkomst för att ändra tjänstkonfigurationer.
  • Före produktionsversionen ska integrering med företagets identitetsprovider styra pågående identitet och åtkomst för driftshantering. Vid den tidpunkten bör molnimplementeringsteamets åtkomst återkallas.

Den sista punkten är inte ett funktions- eller acceptanskriterium, men en indikator på att fler expansioner kommer att krävas och bör utforskas med andra team tidigt.

Mer komplexa DoD-exempel

Styrningsmetodiken i Cloud Adoption Framework ger en berättande resa genom en styrningsteams naturliga mognad. Inbäddade i den resan är flera exempel på DoD- och acceptanskriterier, i form av principinstruktioner.

Föregående exempel är grundläggande exempel som hjälper dig att utveckla en DoD för dina landningszoner. Du kan hämta exempelprinciper för var och en av de fem områdena för molnstyrning.

Azure-verktyg och funktioner för att stödja TDD för landningszoner

Följande diagram visar tillgängliga testdrivna utvecklingsverktyg i Azure:

Diagram som visar tillgängliga testdrivna utvecklingsverktyg i Azure.

Du kan enkelt integrera dessa Azure-verktyg och funktioner i TDD för att skapa landningszoner. Verktygen har specifika syften, vilket gör det enklare att utveckla, testa och distribuera landningszoner i linje med TDD-cykler.

  • Azure Resource Manager tillhandahåller en konsekvent plattform för bygg- och distributionsprocesser. Resource Manager-plattformen kan distribuera landningszoner baserat på källkodsdefinitioner.

  • Azure Resource Manager-mallar (ARM) tillhandahåller primär källkod för miljöer som distribuerats i Azure. Vissa verktyg från tredje part som Terraform tillhandahåller egna ARM-mallar som ska skickas till Azure Resource Manager.

  • Azure-snabbstartsmallar tillhandahåller källkodsmallar som hjälper till att påskynda distributionen av landningszoner och arbetsbelastningar.

  • Azure Policy tillhandahåller den primära mekanismen för att testa acceptanskriterier i din doD. Azure Policy kan också tillhandahålla automatisk identifiering, skydd och lösning när distributioner avviker från styrningsprinciper.

    I en TDD-cykel kan du skapa en principdefinition för att testa ett enda godkännandevillkor. Azure Policy innehåller inbyggda principdefinitioner som kan uppfylla individuella acceptanskriterier i en doD. Den här metoden ger en mekanism för röda tester innan du ändrar landningszonen.

    Azure Policy innehåller också inbyggda principinitiativ som du kan använda för att testa och framtvinga hela doD för en landningszon. Du kan lägga till alla godkännandekriterier i ett principinitiativ som tilldelats hela prenumerationen. När landningszonen uppfyller DoD kan Azure Policy framtvinga testvillkoren för att undvika kodändringar som gör att testet misslyckas i framtida versioner.

    Utforma och granska Azure Policy som kodarbetsflöden som en del av din TDD-metod.

  • Azure Resource Graph tillhandahåller ett frågespråk för att skapa datadrivna tester baserat på information om de tillgångar som distribueras i en landningszon. Senare i implementeringsplanen kan det här verktyget också definiera komplexa tester baserat på interaktionerna mellan arbetsbelastningstillgångar och den underliggande molnmiljön.

    Resource Graph innehåller avancerade frågeexempel som du kan använda för att förstå hur arbetsbelastningar distribueras i en landningszon för avancerade testscenarier.

Beroende på vilken metod du föredrar kan du också använda följande verktyg:

Nästa steg