Testgestuurde ontwikkeling voor Azure-landingszones
Testgestuurde ontwikkeling (TDD) is een softwareontwikkelings- en DevOps-proces dat de kwaliteit van nieuwe functies en verbeteringen in op code gebaseerde oplossingen verbetert. TDD maakt eenheidstestcases voordat de daadwerkelijke code wordt ontwikkeld en test de code op basis van de testcases. Deze aanpak is in tegenstelling tot het ontwikkelen van code eerst en het maken van testcases later.
Een landingszone is een omgeving voor het hosten van workloads die vooraf zijn ingericht via code. Landingszones bevatten basismogelijkheden die gebruikmaken van een gedefinieerde set cloudservices en best practices. In dit artikel wordt een benadering beschreven die gebruikmaakt van TDD voor het implementeren van geslaagde landingszones terwijl aan de vereisten voor kwaliteit, beveiliging, bewerkingen en governance wordt voldaan.
Cloudinfrastructuur is de uitvoer van code-uitvoering. Goed gestructureerde, geteste en geverifieerde code produceert een haalbare landingszone. De cloudinfrastructuur en de onderliggende broncode kunnen deze methode gebruiken om ervoor te zorgen dat landingszones van hoge kwaliteit zijn en voldoen aan de kernvereisten.
Gebruik deze benadering om te voldoen aan eenvoudige functieaanvragen tijdens vroege ontwikkeling. Later in de levenscyclus van cloudimplementatie kunt u dit proces gebruiken om te voldoen aan de vereisten voor beveiliging, bewerkingen, governance of naleving. Het proces is vooral handig voor het ontwikkelen en herstructureren van landingszones in een parallelle ontwikkelingsinspanning.
Testgestuurde ontwikkelingscyclus
In het volgende diagram ziet u de testgestuurde ontwikkelingscyclus voor Azure-landingszones:
Maak een test. Definieer een test om te controleren of aan acceptatiecriteria voor een functie is voldaan. Automatiseer de test tijdens het ontwikkelen om de hoeveelheid handmatige testinspanningen te verminderen, met name voor implementaties op ondernemingsniveau.
Test de landingszone. Voer de nieuwe test en eventuele bestaande tests uit. Als de vereiste functie niet is opgenomen in de aanbiedingen van de cloudprovider en niet is geleverd door eerdere ontwikkelingsinspanningen, mislukt de test. Door bestaande tests uit te voeren, kunt u controleren of uw nieuwe functie of test de betrouwbaarheid van bestaande functies van de landingszone niet vermindert.
Vouw de landingszone uit en herstructureer deze. Voeg broncode toe of wijzig deze om te voldoen aan de aangevraagde functie voor waarde-toevoegen en verbeter de algemene kwaliteit van de codebasis.
Om te voldoen aan de TDD-criteria, voegt het cloudplatformteam alleen code toe om te voldoen aan de aangevraagde functie. Codekwaliteit en -onderhoud worden echter gedeeld. Wanneer ze voldoen aan nieuwe functieaanvragen, moet het cloudplatformteam proberen code te verbeteren door duplicatie te verwijderen en de code te verduidelijken. Het wordt ten zeerste aanbevolen om tests uit te voeren tussen het maken van nieuwe code en het herstructureren van broncode.
Implementeer de landingszone. Zodra de broncode voldoet aan de functieaanvraag, implementeert u de gewijzigde landingszone naar de cloudprovider in een gecontroleerde test- of sandboxomgeving.
Test de landingszone. Test de landingszone opnieuw om te controleren of de nieuwe code voldoet aan de acceptatiecriteria voor de aangevraagde functie. Zodra alle tests zijn geslaagd, wordt de functie beschouwd als voltooid en worden de acceptatiecriteria als voldaan.
De TDD-cyclus herhaalt de voorgaande basisstappen totdat deze voldoen aan de volledige definitie van voltooid. Wanneer alle toegevoegde waardefuncties en acceptatiecriteria aan hun bijbehorende tests voldoen, is de landingszone klaar om de volgende golf van het cloudacceptatieplan te ondersteunen.
De cyclus die TDD effectief maakt, wordt vaak een rode/groene test genoemd. In deze benadering begint het cloudplatformteam met een mislukte test of een rode test, op basis van de definitie van voltooid en de gedefinieerde acceptatiecriteria. Voor elke functie of acceptatiecriteria voert het cloudplatformteam ontwikkelingstaken uit totdat de test is geslaagd of een groene test heeft.
Het doel van TDD is om een beter ontwerp aan te pakken, niet om een reeks tests te maken. De tests zijn een waardevol artefact voor het voltooien van het proces.
Definitie van gereed
Succes kan een subjectieve meting zijn die een cloudplatformteam weinig bruikbare informatie biedt tijdens het ontwikkelen of herstructureren van landingszones. Gebrek aan duidelijkheid kan leiden tot gemiste verwachtingen en beveiligingsproblemen in een cloudomgeving. Voordat het cloudplatformteam eventuele landingszones herstructureert of uitbreidt, moeten ze duidelijkheid zoeken met betrekking tot de definitie van gereedheid (DoD) voor elke landingszone.
DoD is een eenvoudige overeenkomst tussen het cloudplatformteam en andere betrokken teams die de verwachte functies voor toegevoegde waarde definiëren die moeten worden opgenomen in de ontwikkelingsinspanning van de landingszone. DoD is vaak een controlelijst die is afgestemd op het kortetermijnplan voor cloudimplementatie.
Naarmate teams meer workloads en cloudfuncties gebruiken, worden de DoD en de acceptatiecriteria complexer. In volwassen processen hebben de verwachte functies elk hun eigen acceptatiecriteria om meer duidelijkheid te bieden. Wanneer de toegevoegde waardefuncties allemaal voldoen aan de acceptatiecriteria, is de landingszone voldoende geconfigureerd om het succes van de huidige acceptatiegolf of -release mogelijk te maken.
Eenvoudig DoD-voorbeeld
Voor een eerste migratie is de DoD mogelijk te eenvoudig. Het volgende voorbeeld is een eenvoudige DoD:
De eerste landingszone host 10 workloads voor initiële leerdoeleinden. Deze workloads zijn niet essentieel voor het bedrijf en hebben geen toegang tot gevoelige gegevens. In de toekomst zullen deze workloads waarschijnlijk worden uitgebracht voor productie, maar de kritiek en gevoeligheid worden naar verwachting niet gewijzigd.
Ter ondersteuning van deze workloads moet het cloudacceptatieteam voldoen aan de volgende criteria:
- Netwerksegmentatie die overeenkomt met het voorgestelde netwerkontwerp. Deze omgeving moet een perimeternetwerk zijn met toegang tot het openbare internet.
- Toegang tot reken-, opslag- en netwerkresources om de workloads te hosten die zijn afgestemd op de detectie van digitale activa.
- Naamgevings- en tagschema voor gebruiksgemak.
- Tijdens de ingebruikname kan het cloudacceptatieteam tijdelijke toegang krijgen om serviceconfiguraties te wijzigen.
- Voorafgaand aan de productierelease, integratie met de provider van bedrijfsidentiteiten om de lopende identiteit en toegang voor operations management te beheren. Op dat moment moet de toegang van het cloudacceptatieteam worden ingetrokken.
Het laatste punt is geen functie- of acceptatiecriterium, maar een indicator dat er meer uitbreidingen nodig zijn en vroeg met andere teams moeten worden verkend.
Complexere DoD-voorbeelden
De Governance-methodologie binnen het Cloud Adoption Framework biedt een verhaaltraject door de natuurlijke volwassenheid van een governanceteam. In die reis zijn verschillende voorbeelden van DoD- en acceptatiecriteria, in de vorm van beleidsinstructies.
Initiële beleidsinstructies. Voorbeeld van initiële DoD op basis van bedrijfsbeleid dat van toepassing is op vereisten voor vroege acceptatie.
Incrementele verbeteringen om identiteitsbeheer uit te breiden. Voorbeeld van bedrijfsbeleid voor DoD om te voldoen aan vereisten voor het uitbreiden van identiteitsbeheer voor een landingszone.
Incrementele verbeteringen om de beveiligingsvereisten uit te breiden. Voorbeeld van bedrijfsbeleid voor DoD om te voldoen aan de beveiligingsvereisten die zijn afgestemd op het referentieplan voor cloudimplementatie.
Incrementele verbeteringen voor het uitbreiden van bewerkingsbeheer. Voorbeeld van bedrijfsbeleid voor DoD om te voldoen aan basisvereisten voor operationeel beheer.
Incrementele verbeteringen om kostenbeheer uit te breiden. Voorbeeld van bedrijfsbeleid voor DoD om te voldoen aan de vereisten voor kostenbeheer.
De voorgaande voorbeelden zijn basisvoorbeelden om u te helpen bij het ontwikkelen van een DoD voor uw landingszones. U kunt voorbeeldbeleid krijgen voor elk van de vijf disciplines van cloudgovernance.
Azure-hulpprogramma's en -functies ter ondersteuning van TDD-landingszone
In het volgende diagram ziet u de beschikbare testgestuurde ontwikkelhulpprogramma's in Azure:
U kunt deze Azure-hulpprogramma's en -functies eenvoudig integreren in TDD voor het maken van landingszones. De hulpprogramma's dienen voor specifieke doeleinden, waardoor het eenvoudiger is om landingszones te ontwikkelen, testen en implementeren in overeenstemming met TDD-cycli.
Azure Resource Manager biedt een consistent platform voor het bouwen en implementeren van processen. Het Resource Manager-platform kan landingszones implementeren op basis van broncodedefinities.
Arm-sjablonen (Azure Resource Manager) bieden primaire broncode voor omgevingen die zijn geïmplementeerd in Azure. Sommige hulpprogramma's van derden, zoals Terraform, bieden hun eigen ARM-sjablonen die moeten worden verzonden naar Azure Resource Manager.
Azure-quickstartsjablonen bieden broncodesjablonen waarmee de implementatie van landingszones en workloads kan worden versneld.
Azure Policy biedt het primaire mechanisme voor het testen van acceptatiecriteria in uw DoD. Azure Policy kan ook geautomatiseerde detectie, beveiliging en oplossing bieden wanneer implementaties afwijken van governancebeleid.
In een TDD-cyclus kunt u een beleidsdefinitie maken om één acceptatiecriteria te testen. Azure Policy bevat ingebouwde beleidsdefinities die kunnen voldoen aan afzonderlijke acceptatiecriteria binnen een DoD. Deze benadering biedt een mechanisme voor rode tests voordat u de landingszone wijzigt.
Azure Policy bevat ook ingebouwde beleidsinitiatieven die u kunt gebruiken om de volledige DoD voor een landingszone te testen en af te dwingen. U kunt alle acceptatiecriteria toevoegen aan een beleidsinitiatief dat is toegewezen aan het hele abonnement. Zodra de landingszone voldoet aan de DoD, kan Azure Policy de testcriteria afdwingen om codewijzigingen te voorkomen die ervoor zorgen dat de test in toekomstige releases mislukt.
Ontwerp en controleer Azure Policy als codewerkstromen als onderdeel van uw TDD-benadering.
Azure Resource Graph biedt een querytaal voor het maken van gegevensgestuurde tests op basis van informatie over de assets die zijn geïmplementeerd in een landingszone. Verderop in het implementatieplan kan dit hulpprogramma ook complexe tests definiëren op basis van de interacties tussen workloadassets en de onderliggende cloudomgeving.
Resource Graph bevat geavanceerde queryvoorbeelden, die u kunt gebruiken om te begrijpen hoe workloads worden geïmplementeerd binnen een landingszone voor geavanceerde testscenario's.
Afhankelijk van uw voorkeursbenadering kunt u ook de volgende hulpprogramma's gebruiken:
- Landingszones implementeren met Terraform.
- Landingszones implementeren met Bicep.
- Beheer landingszones met Behulp van AzOps, een PowerShell-module waarmee resourcesjablonen en Bicep-bestanden op alle Azure-bereikniveaus worden gepusht, en Azure-resourcehiërarchieën worden opgehaald en geëxporteerd.