Governance van azure DevTest Labs-infrastructuur

In dit artikel worden de uitlijning en het beheer van resources voor DevTest Labs binnen uw organisatie behandeld.

Resources

DevTest Labs-resources in een Azure-abonnement uitlijnen

Voordat een organisatie Azure gaat gebruiken voor algemene toepassingsontwikkeling, moeten IT-planners eerst bekijken hoe ze de mogelijkheid kunnen introduceren als onderdeel van hun algehele portfolio met services. Gebieden die moeten worden beoordeeld, moeten de volgende problemen aanpakken:

• Hoe meet ik de kosten die zijn gekoppeld aan de levenscyclus van de ontwikkeling van toepassingen?
• Hoe lijnt de organisatie het voorgestelde serviceaanbod af op het beveiligingsbeleid van het bedrijf?
• Is segmentatie vereist om de ontwikkel- en productieomgevingen te scheiden?
• Welke controles worden geïntroduceerd voor het beheer, de stabiliteit en de groei op lange termijn?

De eerste aanbevolen procedure is om de Azure-taxonomie van organisaties te bekijken waarin de afdelingen tussen productie- en ontwikkelingsabonnementen worden beschreven. In het volgende diagram maakt de voorgestelde taxonomie een logische scheiding van ontwikkel-/test- en productieomgevingen mogelijk. Met deze aanpak kan een organisatie factureringscodes introduceren om de kosten bij te houden die aan elke omgeving zijn gekoppeld. Zie Prescriptive subscription governance voor meer informatie. Daarnaast kunt u Azure-tags gebruiken om resources te organiseren voor tracerings- en factureringsdoeleinden.

De tweede aanbevolen procedure is om het DevTest-abonnement in te schakelen in de Azure Enterprise-portal. Hiermee kan een organisatie clientbesturingssystemen uitvoeren die doorgaans niet beschikbaar zijn in een Azure Enterprise-abonnement. Gebruik vervolgens bedrijfssoftware waarbij u alleen betaalt voor de rekenkracht en u zich geen zorgen hoeft te maken over licenties. Het zorgt ervoor dat de facturering voor aangewezen services, inclusief galerie-installatiekopieën in IaaS, zoals Microsoft SQL Server, alleen is gebaseerd op verbruik. Meer informatie over het Azure DevTest-abonnement vindt u hier voor Enterprise Overeenkomst (EA)-klanten en hier voor betalen per gebruik-klanten.

Dit model biedt een organisatie de flexibiliteit om Azure DevTest Labs op schaal te implementeren. Een organisatie kan honderden labs ondersteunen voor verschillende bedrijfseenheden met 100 tot 1000 virtuele machines die parallel worden uitgevoerd. Het bevordert het idee van een gecentraliseerde bedrijfslaboplossing die dezelfde principes van configuratiebeheer en beveiligingscontroles kan delen.

Dit model zorgt er ook voor dat de organisatie de resourcelimieten die zijn gekoppeld aan hun Azure-abonnement niet uitputt. Zie Azure-abonnements- en servicelimieten, quota en beperkingen voor meer informatie over abonnements- en servicelimieten. Het inrichtingsproces van DevTest Labs kan een groot aantal resourcegroepen verbruiken. U kunt aanvragen om limieten te verhogen via een ondersteuningsaanvraag in het Azure DevTest-abonnement. De resources binnen het productieabonnement worden niet beïnvloed naarmate het ontwikkelingsabonnement in gebruik wordt. Zie Quota en limieten schalen in DevTest Labs voor meer informatie over het schalen van DevTest Labs.

Een algemene limiet op abonnementsniveau waarvoor rekening moet worden gehouden, is hoe de toewijzingen van het NETWERK-IP-bereik worden toegewezen ter ondersteuning van zowel productie- als ontwikkelingsabonnementen. Deze toewijzingen moeten in de loop van de tijd rekening houden met groei (ervan uitgaande dat on-premises connectiviteit of een andere netwerktopologie die vereist dat de onderneming de netwerkstack beheert in plaats van de standaardinstelling voor de implementatie van Azure). De aanbevolen procedure is om een aantal virtuele netwerken te hebben waaraan een groot IP-adresvoorvoegsel is toegewezen en verdeeld met veel grote subnetten in plaats van meerdere virtuele netwerken met kleine subnetten te hebben. Met 10 abonnementen kunt u bijvoorbeeld 10 virtuele netwerken definiëren (één voor elk abonnement). Alle labs waarvoor geen isolatie is vereist, kunnen hetzelfde subnet delen in het virtuele netwerk van het abonnement.

Aantal gebruikers per lab en labs per organisatie

Bedrijfseenheden en ontwikkelingsgroepen die aan hetzelfde ontwikkelingsproject zijn gekoppeld, moeten worden gekoppeld aan hetzelfde lab. Hiermee kunnen dezelfde typen beleidsregels, installatiekopieën en afsluitbeleidsregels worden toegepast op beide groepen.

Mogelijk moet u ook rekening houden met geografische grenzen. Ontwikkelaars in het noordoosten Verenigde Staten (VS) kunnen bijvoorbeeld gebruikmaken van een lab dat is ingericht in VS - oost2. En ontwikkelaars in Dallas, Texas en Denver, Colorado kunnen worden omgeleid om een resource te gebruiken in VS - zuid-centraal. Als er een samenwerking met een externe derde partij is, kunnen deze worden toegewezen aan een lab dat niet wordt gebruikt door interne ontwikkelaars.

U kunt ook een lab gebruiken voor een specifiek project in Azure DevOps Projects. Vervolgens past u beveiliging toe via een opgegeven Microsoft Entra-groep, waarmee u toegang hebt tot beide resources. Het virtuele netwerk dat aan het lab is toegewezen, kan een andere grens zijn om gebruikers samen te voegen.

Het verwijderen van resources voorkomen

Stel machtigingen in op labniveau, zodat alleen geautoriseerde gebruikers resources kunnen verwijderen of labbeleid kunnen wijzigen. Ontwikkelaars moeten in de groep DevTest Labs-gebruikers worden geplaatst. De leadontwikkelaar of de infrastructuurleider moet de eigenaar van DevTest Labs zijn. U wordt aangeraden slechts twee labeigenaren te hebben. Dit beleid breidt zich uit naar de codeopslagplaats om beschadiging te voorkomen. Labgebruik heeft rechten om resources te gebruiken, maar kan labbeleid niet bijwerken. Zie het volgende artikel met de rollen en rechten die elke ingebouwde groep in een lab heeft: Eigenaren en gebruikers toevoegen in Azure DevTest Labs.

Kosten en eigendom beheren

Kosten en eigendom zijn primaire aandachtspunten wanneer u overweegt om uw ontwikkel- en testomgevingen te bouwen. In deze sectie vindt u informatie die u helpt bij het optimaliseren van kosten en het afstemmen van het eigendom in uw omgeving.

Optimaliseren voor kosten

Verschillende ingebouwde functies van DevTest Labs helpen u bij het optimaliseren van kosten. Zie artikelen over kostenbeheer, drempelwaarden en beleidsregels om activiteiten van uw gebruikers te beperken.

Als u DevTest Labs gebruikt voor ontwikkel- en testworkloads, kunt u het Enterprise Dev/Test Subscription Benefit gebruiken dat deel uitmaakt van uw Enterprise Overeenkomst. Of als u een betalen per gebruik-klant bent, kunt u de DevTest-aanbieding betalen per gebruik overwegen.

Deze aanpak biedt verschillende voordelen:

• Speciale lagere Dev/Test-tarieven op virtuele Windows-machines, cloudservices, HDInsight, App Service en Logic Apps
• Geweldige tarieven voor Enterprise Overeenkomst (EA) voor andere Azure-services
• Toegang tot exclusieve Dev/Test-installatiekopieën in de galerie, waaronder Windows 8.1 en Windows 10

Alleen actieve Visual Studio-abonnees (standaardabonnementen, jaarlijkse cloudabonnementen en maandelijkse cloudabonnementen) kunnen Azure-resources gebruiken die worden uitgevoerd binnen een enterprise Dev/Test-abonnement. Eindgebruikers hebben echter toegang tot de toepassing om feedback te geven of acceptatietests uit te voeren. U kunt resources binnen dit abonnement alleen gebruiken voor het ontwikkelen en testen van toepassingen. Er is geen garantie voor uptime.

Als u besluit de DevTest-aanbieding te gebruiken, gebruikt u dit voordeel uitsluitend voor het ontwikkelen en testen van uw toepassingen. Gebruik binnen het abonnement heeft geen SLA met financiële ondersteuning, met uitzondering van het gebruik van Azure DevOps en HockeyApp.

Op rollen gebaseerde toegang definiëren binnen uw organisatie

Centrale IT moet alleen eigenaar zijn van wat nodig is en stelt het project- en toepassingsteams in staat om het benodigde controleniveau te hebben. Normaal gesproken betekent dit dat de centrale IT eigenaar is van het abonnement en kern-IT-functies, zoals netwerkconfiguraties, afhandelt. De set eigenaren voor een abonnement moet klein zijn. Deze eigenaren kunnen andere eigenaren nomineren wanneer er behoefte is of beleidsregels op abonnementsniveau toepassen, bijvoorbeeld 'Geen openbaar IP-adres'.

Er kan een subset van gebruikers zijn die toegang nodig hebben tot een abonnement, zoals ondersteuning voor laag 1 of laag 2. In dit geval raden we u aan deze gebruikers toegang te geven tot inzenders , zodat ze de resources kunnen beheren, maar geen gebruikerstoegang kunnen bieden of beleidsregels aanpassen.

DevTest Labs-resource-eigenaren moeten dicht bij het project- of toepassingsteam staan. Deze eigenaren begrijpen de machine- en softwarevereisten. In de meeste organisaties is de eigenaar van de DevTest Labs-resource het project of de ontwikkelingsleider. Deze eigenaar kan gebruikers en beleid beheren binnen de testomgeving en kan alle virtuele machines in de DevTest Labs-omgeving beheren.

Voeg project- en toepassingsteamleden toe aan de rol DevTest Labs-gebruikers. Deze gebruikers kunnen virtuele machines maken, in overeenstemming met beleid op lab- en abonnementsniveau. Gebruikers kunnen ook hun eigen virtuele machines beheren, maar kunnen geen virtuele machines beheren die tot andere gebruikers behoren.

Zie de Azure Enterprise-scaffold, prescriptieve abonnementsgovernance voor meer informatie.

Bedrijfsbeleid en naleving

Deze sectie bevat richtlijnen voor het beheren van bedrijfsbeleid en naleving voor de Infrastructuur van Azure DevTest Labs.

Openbare versus privéartefactopslagplaats

De opslagplaats voor openbare artefacten biedt een eerste set softwarepakketten die het meest worden gebruikt. Het helpt bij snelle implementatie zonder tijd te hoeven investeren om algemene ontwikkelhulpprogramma's en invoegtoepassingen te reproduceren. U kunt ervoor kiezen om hun eigen privéopslagplaats te implementeren. U kunt een openbare en een privéopslagplaats parallel gebruiken. U kunt er ook voor kiezen om de openbare opslagplaats uit te schakelen. De criteria voor het implementeren van een privéopslagplaats moeten worden aangestuurd door de volgende vragen en overwegingen:

• Heeft de organisatie een vereiste om bedrijfslicentiesoftware te hebben als onderdeel van hun DevTest Labs-aanbieding? Als het antwoord ja is, moet er een privéopslagplaats worden gemaakt.
• Ontwikkelt de organisatie aangepaste software die een specifieke bewerking biedt, die vereist is als onderdeel van het algehele inrichtingsproces? Als het antwoord ja is, moet er een privéopslagplaats worden geïmplementeerd.
• Als het beheerbeleid van de organisatie isolatie vereist en externe opslagplaatsen niet onder direct configuratiebeheer door de organisatie worden uitgevoerd, moet er een opslagplaats voor privéartefacten worden geïmplementeerd. Als onderdeel van dit proces kan een eerste kopie van de openbare opslagplaats worden gekopieerd en geïntegreerd met de persoonlijke opslagplaats. Vervolgens kan de openbare opslagplaats worden uitgeschakeld, zodat niemand binnen de organisatie er meer toegang toe heeft. Deze aanpak dwingt alle gebruikers binnen de organisatie slechts één opslagplaats te hebben die door de organisatie wordt goedgekeurd en configuratiedrift minimaliseren.

Eén opslagplaats of meerdere opslagplaatsen

Als onderdeel van de algemene governance- en configuratiebeheerstrategie van uw organisatie raden we u aan een gecentraliseerde opslagplaats te gebruiken. Wanneer u meerdere opslagplaatsen gebruikt, kunnen ze in de loop van de tijd silo's van onbeheerde software worden. Met een centrale opslagplaats kunnen meerdere teams artefacten uit deze opslagplaats gebruiken voor hun projecten. Het dwingt standaardisatie, beveiliging, beheergemak af en elimineert de duplicatie van inspanningen. Als onderdeel van de centralisatie worden de volgende acties aanbevolen voor langetermijnbeheer en duurzaamheid:

• Koppel de Azure-opslagplaatsen aan dezelfde Microsoft Entra-tenant die het Azure-abonnement gebruikt voor verificatie en autorisatie.
• Maak een groep met de naam Alle DevTest Labs-ontwikkelaars in Microsoft Entra ID die centraal wordt beheerd. Elke ontwikkelaar die bijdraagt aan de ontwikkeling van artefacten, moet in deze groep worden geplaatst.
• Dezelfde Microsoft Entra-groep kan worden gebruikt om toegang te bieden tot de opslagplaats voor Azure-opslagplaatsen en voor het lab.
• In Azure-opslagplaatsen moet vertakking of forking worden gebruikt om een afzonderlijke opslagplaats in ontwikkeling te maken van de primaire productieopslagplaats. Inhoud wordt alleen toegevoegd aan de hoofdbranch met een pull-aanvraag na een juiste codebeoordeling. Zodra de coderevisor de wijziging goedkeurt, voegt een hoofdontwikkelaar, die verantwoordelijk is voor het onderhoud van de hoofdbranch, de bijgewerkte code samen.

Bedrijfsbeleid voor beveiliging

Een organisatie kan beleidsregels voor bedrijfsbeveiliging toepassen op:

• Een uitgebreid beveiligingsbeleid ontwikkelen en publiceren. Het beleid verwoordt de regels van acceptabel gebruik dat is gekoppeld aan de software, cloudassets. Het definieert ook wat het beleid duidelijk schendt.
• Het ontwikkelen van een aangepaste installatiekopie, aangepaste artefacten en een implementatieproces dat indeling mogelijk maakt binnen de beveiligingsrealm die is gedefinieerd met Active Directory. Deze aanpak dwingt de bedrijfsgrens af en stelt een gemeenschappelijke set omgevingscontroles in. Deze controles voor de omgeving die een ontwikkelaar kan overwegen bij het ontwikkelen en volgen van een veilige ontwikkelingslevenscyclus als onderdeel van hun algehele proces. Het doel is ook een omgeving te bieden die niet te beperkend is die de ontwikkeling kan belemmeren, maar een redelijke set controles. De groepsbeleidsregels in de organisatie-eenheid (OE) die virtuele machines van het lab bevat, kunnen een subset zijn van het totale groepsbeleid dat in productie is gevonden. Ze kunnen ook een andere set zijn om geïdentificeerde risico's correct te beperken.

Gegevensintegriteit

Een organisatie kan gegevensintegriteit garanderen om ervoor te zorgen dat externe ontwikkelaars geen code kunnen verwijderen of malware of niet-goedgekeurde software kunnen introduceren. Er zijn verschillende controlelagen om de dreiging van externe consultants, aannemers of werknemers te beperken om samen te werken in DevTest Labs.

Zoals eerder vermeld, moet de eerste stap een aanvaardbaar gebruiksbeleid hebben opgesteld en gedefinieerd dat duidelijk de gevolgen beschrijft wanneer iemand het beleid schendt.

De eerste laag besturingselementen voor externe toegang is het toepassen van een beleid voor externe toegang via een VPN-verbinding die niet rechtstreeks is verbonden met het lab.

De tweede laag besturingselementen is het toepassen van een set groepsbeleidsobjecten die kopiëren en plakken via extern bureaublad voorkomen. Een netwerkbeleid kan worden geïmplementeerd om uitgaande services uit de omgeving, zoals FTP- en RDP-services, niet uit de omgeving toe te staan. Door de gebruiker gedefinieerde routering kan al het Azure-netwerkverkeer weer naar on-premises afdwingen, maar de routering kan geen rekening houden met alle URL's die het uploaden van gegevens mogelijk maken, tenzij via een proxy wordt gecontroleerd om inhoud en sessies te scannen. Openbare IP-adressen kunnen worden beperkt binnen het virtuele netwerk dat DevTest Labs ondersteunt om het overbruggen van een externe netwerkresource niet toe te staan.

Uiteindelijk moet hetzelfde type beperkingen worden toegepast binnen de organisatie, wat ook rekening moet houden met alle mogelijke methoden van verwisselbare media of externe URL's die een bericht van inhoud kunnen accepteren. Neem contact op met uw beveiligingsprofessional om een beveiligingsbeleid te controleren en te implementeren. Zie Microsoft Cyber Security voor meer aanbevelingen.

Migratie en integratie van toepassingen

Zodra uw ontwikkel-/testomgeving is ingesteld, moet u nadenken over de volgende vragen:

• Hoe gebruikt u de omgeving binnen uw projectteam?
• Hoe zorgt u ervoor dat u het vereiste organisatiebeleid volgt en de flexibiliteit behoudt om waarde toe te voegen aan uw toepassing?

Azure Marketplace-installatiekopieën versus aangepaste installatiekopieën

Azure Marketplace moet standaard worden gebruikt, tenzij u specifieke problemen of organisatievereisten hebt. Enkele veelvoorkomende voorbeelden zijn;

• Complexe software-installatie waarvoor een toepassing moet worden opgenomen als onderdeel van de basisinstallatiekopieën.
• Het installeren en instellen van een toepassing kan uren duren. Dit is geen efficiënt gebruik van de rekentijd die moet worden toegevoegd aan een Azure Marketplace-installatiekopieën.
• Ontwikkelaars en testers hebben snel toegang tot een virtuele machine nodig en willen de installatietijd van een nieuwe virtuele machine minimaliseren.
• Nalevings- of regelgevingsvoorwaarden (bijvoorbeeld beveiligingsbeleid) die aanwezig moeten zijn voor alle computers.

Overweeg aangepaste installatiekopieën zorgvuldig te gebruiken. Aangepaste installatiekopieën zorgen voor extra complexiteit, omdat u nu VHD-bestanden moet beheren voor die onderliggende basisinstallatiekopieën. U moet deze basisinstallatiekopieën ook regelmatig patchen met software-updates. Deze updates omvatten nieuwe besturingssysteemupdates en eventuele updates of configuratiewijzigingen die nodig zijn voor het softwarepakket zelf.

Formule versus aangepaste installatiekopieën

Normaal gesproken is de beslissingsfactor in dit scenario kosten en hergebruiken.

U kunt kosten verlagen door een aangepaste installatiekopieën te maken als:

• Veel gebruikers of labs vereisen de installatiekopieën.
• De vereiste installatiekopieën hebben veel software boven op de basisinstallatiekopieën.

Deze oplossing betekent dat u de installatiekopieën eenmaal maakt. Een aangepaste installatiekopieën verminderen de installatietijd van de virtuele machine. Er worden geen kosten in rekening gebracht voor het uitvoeren van de virtuele machine tijdens de installatie.

Een andere factor is de frequentie van wijzigingen in uw softwarepakket. Als u dagelijkse builds uitvoert en vereist dat de software zich op de virtuele machines van uw gebruikers bevindt, kunt u een formule gebruiken in plaats van een aangepaste installatiekopieën.

Patronen voor het instellen van netwerkconfiguratie

Wanneer u ervoor zorgt dat de ontwikkeling en test van virtuele machines het openbare internet niet kunnen bereiken, zijn er twee aspecten waarmee u rekening moet houden: inkomend en uitgaand verkeer.

Binnenkomend verkeer : als de virtuele machine geen openbaar IP-adres heeft, kan internet het niet bereiken. Een veelvoorkomende aanpak is het instellen van een beleid op abonnementsniveau dat geen gebruiker een openbaar IP-adres kan maken.

Uitgaand verkeer : als u wilt voorkomen dat virtuele machines rechtstreeks naar het openbare internet gaan en verkeer via een bedrijfsfirewall afdwingen, kunt u verkeer on-premises routeren via Azure ExpressRoute of VPN met behulp van geforceerde routering.

Notitie

Als u een proxyserver hebt die verkeer zonder proxy-instellingen blokkeert, vergeet dan niet om uitzonderingen toe te voegen aan het opslagaccount voor artefacten van het lab.

U kunt ook netwerkbeveiligingsgroepen gebruiken voor virtuele machines of subnetten. Met deze stap voegt u een andere beveiligingslaag toe om verkeer toe te staan of te blokkeren.

Nieuw versus bestaand virtueel netwerk

Als uw VM's moeten communiceren met de bestaande infrastructuur, moet u overwegen een bestaand virtueel netwerk in uw DevTest Labs-omgeving te gebruiken. Als u ExpressRoute gebruikt, minimaliseert u het aantal virtuele netwerken en subnetten, zodat u de IP-adresruimte die aan uw abonnementen is toegewezen niet fragmenteert. U kunt ook het peeringpatroon van het virtuele netwerk hier gebruiken (Hub-Spoke-model). Deze benadering maakt communicatie tussen virtuele netwerken en subnetten mogelijk tussen abonnementen binnen een bepaalde regio.

Elke DevTest Labs-omgeving kan een eigen virtueel netwerk hebben, maar er gelden limieten voor het aantal virtuele netwerken per abonnement. De standaardwaarde is 50, hoewel deze limiet kan worden verhoogd tot 100.

Gedeeld, openbaar of privé-IP-adres

Als u een site-naar-site-VPN of ExpressRoute gebruikt, kunt u privé-IP-adressen gebruiken, zodat uw computers toegankelijk zijn via uw interne netwerk en niet toegankelijk zijn via openbaar internet.

Notitie

Labeigenaren kunnen dit subnetbeleid wijzigen om ervoor te zorgen dat niemand per ongeluk openbare IP-adressen voor hun VM's maakt. De eigenaar van het abonnement moet een abonnementsbeleid maken om te voorkomen dat openbare IP-adressen worden gemaakt.

Wanneer u gedeelde openbare IP-adressen gebruikt, delen de virtuele machines in een lab een openbaar IP-adres. Deze aanpak kan handig zijn wanneer u moet voorkomen dat de limieten voor openbare IP-adressen voor een bepaald abonnement worden overschreden.

Lablimieten

Er zijn verschillende lablimieten waar u rekening mee moet houden. Deze limieten worden beschreven in de volgende secties.

Limieten van labs per abonnement

Er is geen specifieke limiet voor het aantal labs dat per abonnement kan worden gemaakt. De hoeveelheid resources die per abonnement worden gebruikt, is echter beperkt. U kunt lezen over de limieten en quota voor Azure-abonnementen en hoe u deze limieten kunt verhogen.

Limieten van VM's per lab

Er is geen specifieke limiet voor het aantal virtuele machines dat per lab kan worden gemaakt. De resources (VM-kernen, openbare IP-adressen, enzovoort) die worden gebruikt, zijn echter beperkt per abonnement. U kunt lezen over de limieten en quota voor Azure-abonnementen en hoe u deze limieten kunt verhogen.

Limieten van het aantal virtuele machines per gebruiker of lab

Wanneer u rekening houdt met het aantal virtuele machines per gebruiker of per lab, zijn er drie belangrijke aandachtspunten:

• De totale kosten die het team kan besteden aan resources in het lab. Het is eenvoudig om veel machines in te stellen. Om de kosten te beheren, is één mechanisme het aantal VM's per gebruiker of per lab te beperken
• Het totale aantal virtuele machines in een lab wordt beïnvloed door de quota op abonnementsniveau die beschikbaar zijn. Een van de hoogste limieten is 800 resourcegroepen per abonnement. DevTest Labs maakt momenteel een nieuwe resourcegroep voor elke VIRTUELE machine (tenzij gedeelde openbare IP-adressen worden gebruikt). Als er 10 labs in een abonnement zijn, kunnen labs ongeveer 79 virtuele machines in elk lab (800 bovengrens – 10 resourcegroepen voor de 10 labs zelf) = 79 virtuele machines per lab passen.
• Als het lab is verbonden met on-premises via Express Route (bijvoorbeeld), zijn er gedefinieerde IP-adresruimten beschikbaar voor het VNet/Subnet. Om ervoor te zorgen dat VM's in het lab niet kunnen worden gemaakt (fout: kan ip-adres niet ophalen), kunnen labeigenaren de maximale VM's per lab opgeven die zijn afgestemd op de beschikbare IP-adresruimte.

Resourcemanager-sjablonen gebruiken

Implementeer uw Resource Manager-sjablonen met behulp van de stappen in Azure DevTest Labs gebruiken voor testomgevingen. In principe controleert u uw Resource Manager-sjablonen in een Azure-opslagplaats of GitHub Git-opslagplaats en voegt u een privéopslagplaats voor uw sjablonen toe aan het lab.

Dit scenario is mogelijk niet nuttig als u DevTest Labs gebruikt om ontwikkelmachines te hosten. Gebruik dit scenario om een faseringsomgeving te bouwen die representatief is voor productie.

Het aantal virtuele machines per lab of per gebruiker beperkt alleen het aantal machines dat systeemeigen is gemaakt in het lab zelf. Deze optie beperkt het maken niet door omgevingen met Resource Manager-sjablonen.