Testgestuurde ontwikkeling voor Azure-landingszones
Testgestuurde ontwikkeling (TDD) is een proces voor softwareontwikkeling en DevOps waarmee de kwaliteit van nieuwe functies en verbeteringen in op code gebaseerde oplossingen worden verbeterd. TDD maakt eenheidstestcases voordat de werkelijke code wordt ontwikkeld en test de code op basis van de testcases. Deze benadering is in tegenstelling tot het eerst ontwikkelen van code 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 om geslaagde landingszones te implementeren en tegelijkertijd te voldoen aan de vereisten voor kwaliteit, beveiliging, bewerkingen en governance.
Cloudinfrastructuur is de uitvoer van code-uitvoering. Goed gestructureerde, geteste en geverifieerde code produceert een levensvatbare landingszone. Cloudinfrastructuur en de onderliggende broncode kunnen deze benadering gebruiken om ervoor te zorgen dat landingszones van hoge kwaliteit zijn en voldoen aan de kernvereisten.
Gebruik deze methode om te voldoen aan eenvoudige functieaanvragen tijdens een vroege ontwikkeling. Later in de levenscyclus van de cloudimplementatie kunt u dit proces gebruiken om te voldoen aan vereisten voor beveiliging, bewerkingen, governance of naleving. Het proces is vooral nuttig voor het ontwikkelen en herstructureren van landingszones in een parallelle ontwikkeling.
Testgestuurde ontwikkelingscyclus
In het volgende diagram ziet u de testgestuurde ontwikkelingscyclus voor Azure-landingszones:
Een test maken. Definieer een test om te controleren of aan de acceptatiecriteria voor een functie is voldaan. Automatiseer de test tijdens het ontwikkelen om de hoeveelheid handmatige testinspanning 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 in 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 het toevoegen van waarde en om de algemene kwaliteit van de codebasis te verbeteren.
Om te voldoen aan de TDD-criteria, voegt het cloudplatformteam alleen code toe om te voldoen aan de aangevraagde functie. Codekwaliteit en onderhoud zijn echter gedeelde inspanningen. Wanneer ze voldoen aan nieuwe functieaanvragen, moet het cloudplatformteam proberen code te verbeteren door duplicatie te verwijderen en de code te verduidelijken. Het uitvoeren van tests tussen het maken van nieuwe code en het herstructureren van broncode wordt ten zeerste aanbevolen.
Implementeer de landingszone. Zodra de broncode aan de functieaanvraag voldoet, implementeert u de gewijzigde landingszone naar de cloudprovider in een gecontroleerde test- of sandbox-omgeving.
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 als voltooid beschouwd en wordt aan de acceptatiecriteria voldaan.
De TDD-cyclus herhaalt de voorgaande basisstappen totdat ze voldoen aan de volledige definitie van gereed. Wanneer alle functies met toegevoegde waarde en acceptatiecriteria voldoen aan de bijbehorende tests, is de landingszone klaar om de volgende fase van het cloudacceptatieplan te ondersteunen.
De cyclus die TDD effectief maakt, wordt vaak een rood-groene test genoemd. Bij deze benadering begint het cloudplatformteam met een mislukte test, of rode test, op basis van de definitie van gereed en de gedefinieerde acceptatiecriteria. Voor elke functie of acceptatiecriteria voltooit het cloudplatformteam ontwikkelingstaken 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 landingszones herstructureert of uitbreidt, moeten ze duidelijkheid zoeken over de definitie van gereed (DoD) voor elke landingszone.
DoD is een eenvoudige overeenkomst tussen het cloudplatformteam en andere betrokken teams waarin de verwachte functies met toegevoegde waarde worden gedefinieerd die moeten worden opgenomen in de ontwikkeling van de landingszone. De 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 functies met toegevoegde waarde 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 initiële 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 vrijgegeven voor productie, maar de ernst en gevoeligheid zullen naar verwachting niet veranderen.
Om deze workloads te ondersteunen, moet het cloudacceptatieteam voldoen aan de volgende criteria:
- Netwerksegmentatie om uit te lijnen met het voorgestelde netwerkontwerp. Deze omgeving moet een perimeternetwerk zijn met toegang tot het openbare internet.
- Toegang tot reken-, opslag- en netwerkresources voor het hosten van de workloads die zijn afgestemd op de detectie van digitale activa.
- Naamgevings- en tagschema's voor gebruiksgemak.
- Tijdens de ingebruikname, tijdelijke toegang voor het cloudacceptatieteam om serviceconfiguraties te wijzigen.
- Voorafgaand aan de productierelease, integratie met de bedrijfsidentiteitsprovider om doorlopende identiteit en toegang voor operationeel beheer 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 de Cloud Adoption Framework biedt een verhaaltraject door de natuurlijke volwassenheid van een governanceteam. In dat traject zijn verschillende voorbeelden van DoD- en acceptatiecriteria opgenomen, in de vorm van beleidsinstructies.
Initiële beleidsinstructies. Voorbeeld van initiële DoD op basis van bedrijfsbeleid dat van toepassing is op vereisten voor ingebruikname in een vroeg stadium.
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 beveiligingsvereisten die zijn afgestemd op het referentieplan voor cloudimplementatie.
Incrementele verbeteringen voor het uitbreiden van operationeel beheer. Voorbeeld van bedrijfsbeleid voor DoD om te voldoen aan de basisvereisten voor operations management.
Incrementele verbeteringen om kostenbeheer uit te breiden. Voorbeeld van bedrijfsbeleid voor DoD om te voldoen aan vereisten voor kostenbeheer.
De voorgaande voorbeelden zijn basisvoorbeelden om u te helpen bij het ontwikkelen van een DoD voor uw landingszones. U kunt voorbeeldbeleidsregels ophalen voor elk van de vijf disciplines van cloudgovernance.
Azure-hulpprogramma's en -functies ter ondersteuning van TDD van landingszones
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 wordt om landingszones te ontwikkelen, testen en implementeren in overeenstemming met TDD-cycli.
Azure Resource Manager biedt een consistent platform voor bouw- en implementatieprocessen. 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 kunnen worden verzonden naar Azure Resource Manager.
Azure-snelstartsjablonen bieden broncodesjablonen waarmee u de implementatie van de landingszone en workload kunt versnellen.
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 acceptatiecriterium 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, kunt Azure Policy de testcriteria afdwingen om codewijzigingen te voorkomen waardoor de test in toekomstige releases mislukt.
Ontwerp en controleer Azure Policy als codewerkstromen als onderdeel van uw TDD-benadering.
Azure Blueprints groepeert beleidsregels en andere implementatiehulpprogramma's in een herhaalbaar pakket dat u kunt toewijzen aan meerdere landingszones. Blauwdrukken zijn handig voor meerdere implementatie-inspanningen die algemene DoD's delen, die u mogelijk in de loop van de tijd wilt bijwerken. Azure Blueprints kan ook helpen bij de implementatie tijdens volgende pogingen om landingszones uit te breiden en te herstructureren.
Azure Blueprints biedt verschillende blauwdrukvoorbeelden, waaronder beleidsregels voor testen en sjablonen voor implementatie. Deze blauwdrukvoorbeelden kunnen de ontwikkelings-, implementatie- en testinspanningen in TDD-cycli versnellen.
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 binnen een landingszone worden geïmplementeerd voor geavanceerde testscenario's.
Afhankelijk van uw voorkeursbenadering kunt u ook de volgende hulpprogramma's gebruiken:
- Landingszones implementeren met Behulp van Terraform.
- Implementeer landingszones met bicep.
- Beheer landingszones met behulp van AzOps, een PowerShell-module die resourcesjablonen en Bicep-bestanden pusht op alle Azure-bereikniveaus, en Azure-resourcehiërarchieën pullt en exporteert.