Movatterモバイル変換

This article discusses how to use Azure DevTest Labs for several different development, test, and training scenarios. Here are some popular DevTest Labs scenarios:

Developers need many, sometimes different virtual machines (VMs) and environments as they iterate on apps.
Testers use many identical or different VMs and environments for performance testing and sandboxed investigations.
Teachers and trainers periodically need new classroom, lab, and hackathon VMs and environments.

The following sections describe how DevTest Labs supports these scenarios, while helping lab owners and administrators control lab access and costs.

Lab creation

Labs are the starting point in DevTest Labs. After you create a lab, you can:

Add lab users.
Create preconfigured VMs that any lab users can claim.
Define images, formulas, and templates for lab users to quickly create their own VMs and environments.
Use configuration and policies to manage the lab and control costs.
Integrate with Azure DevOps to support DevOps scenarios.
Link to public and private Git repositories for access to artifacts and Azure Resource Manager (ARM) templates.

The following diagram shows how lab owners can configure policies and provide resources for lab users:

Diagram that shows a lab owner configuring policies and providing resources for lab users.

To create a lab in Azure DevTest Labs, you can use any of the following methods:

Azure portal |Bicep file |ARM template |Terraform |PowerShell with Azure REST API

You can also automate lab creation, including custom settings, with a reusable ARM template. For more information, seeARM templates in Azure DevTest Labs.

Add a virtual network to a lab

DevTest Labs creates a new virtual network for each lab. If you have another virtual network configured with Azure ExpressRoute or site-to-site virtual private networking (VPN), you can add it to your lab and create lab VMs in that virtual network. For more information, seeConfigure a virtual network in Azure DevTest Labs.

Add users to labs

Lab owners can add users to labs by using the Azure portal or a PowerShell script. For more information, seeAdd lab owners, contributors, and users in Azure DevTest Labs. Lab users don't need to have an Azure account as long as they have a Microsoft account.

Lab users can view all lab resources, such as VMs, policies, and virtual networks. Lab users can't modify policies, or access VMs that other users create or claim.

Configure lab policies to control costs

To monitor and control costs, lab administrators and owners can:

Limit the number of VMs each user can create or claim.
Allow only certain virtual machine (VM) sizes in the lab.
Configure autoshutdown and autostart policies to stop and restart all VMs at particular times of day. VM autoshutdown doesn't apply to platform-as-a-service (PaaS) resources in environments.
Use Microsoft Cost Management to track environment costs.

Development and test VMs

Developers and testers might need many identical VMs for performance or load testing, or might need different types of VMs for different projects or iterations. DevTest Labs users can create, configure, and access VMs on demand to meet their needs. Starting with common VM images promotes consistency across teams.

In DevTest Labs, developers can:

Quickly provision VMs on demand, orclaim existing preconfigured VMs.
Self-service their own VMs without needing subscription-level permissions.
Directly usevirtual networks that lab owners and admins set up, without needing special permissions.
Easily customize their VMs byadding artifacts as needed.

Create VMs

Lab users can create lab VMs in minutes by choosing from a wide variety of ready-made Azure Marketplace images. To learn about making selected Marketplace images available for lab users, seeConfigure Azure Marketplace images.

Lab owners can also install needed software on a VM, save the VM as acustom image, and make the image available in the lab. Lab users can use the custom image to create VMs that have the software preinstalled. For more information, seeCreate a custom image.

You can use animage builder to automatically build and distribute your custom images regularly. This configuration-as-code solution eliminates the need to manually maintain VM images, by keeping the base OS and components up to date. For more information, seeAzure VM Image Builder.

Use reusable formulas for VMs

A DevTest Labsformula is a list of default property values for VMs. A lab owner can create a formula in the lab by picking a VM image, a VM size based on CPU and RAM, and a virtual network. Lab users can see the formula and use it to create VMs. For more information, seeManage DevTest Labs formulas.

Use artifacts for VM customization

Lab users can addartifacts to configure their lab VMs. Artifacts can be:

Tools to install on the VM, like agents, Fiddler, or Visual Studio.
Actions to run on the VM, like cloning a repo.
Applications to test.

Many artifacts are available out of the box. You can also createcustom artifacts if you need more customizations. You store custom artifacts in a private Git repository you connect to your lab, so all lab users can add the artifacts to their VMs. For more information, seeCreate custom artifacts for DevTest Labs andAdd an artifact repository to a lab.

You can add an Active Directory domain-join artifact to join VMs to an Active Directory domain at creation. This artifact applies only to domains.

Multi-VM environments

Many development and test scenarios require multi-VMenvironments equipped with PaaS resources. Examples include Azure Web Apps, SharePoint farms, and Service Fabric clusters. Creating and managing environments across an enterprise can require significant effort.

With DevTest Labs, teams can easily create, update, or duplicate multi-VM environments. Developers can use fully configured environments to develop and test the latest versions of their apps. DevTest Labs environments ensure consistency across teams.

By using ARM templates to deploy environments, you can:

Repeatedly deploy multiple preconfigured VMs in a consistent state.
Define infrastructure and configuration for Windows or Linux environments.
Provision Azure PaaS resources and track their costs.

For more information, seeUse ARM templates to create DevTest Labs environments.

Give users Contributor rights to environments

By default, DevTest Labs creates environments in their own resource groups, and DevTest Labs users get read access to those environments. With read-only access, users can't add or change resources in those environments. But developers often need to investigate different technologies or infrastructure designs.

Lab owners can allow users more control by giving them Contributor rights to environments. Contributors can add or change Azure resources as necessary in their own development or test environments. For more information, seeConfigure environment user rights.

Classroom, training, and hackathon labs

DevTest Labs is well-suited for transient activities like workshops, hands-on labs, training, or hackathons. In these scenarios:

Training leaders or lab owners can use custom templates to create identical, isolated VMs or environments.
Trainees canaccess the lab by using a URL.
Trainees can claim already-created, preconfigured machines with a single action.
Lab owners can control lab costs and lifespan by:
- Configuring policies.
- Setting VM expiration dates.
- Deleting VMs and labs when the activity is over.

Delete labs and VMs

Lab owners can manage costs by deleting labs and VMs when they're no longer needed.

Set expiration dates on VMs.
Delete labs and all related resources.
Delete all lab VMs by running a single PowerShell script.

Proof of concept and scaled deployments

To start exploring DevTest Labs, organizations can useproof of concept andscaled deployments.

Proof of concept uses concentrated efforts from single teams to establish organizational value.
A scaled deployment uses weeks or months of reviewing and planning to deploy DevTest Labs to an enterprise with hundreds or thousands of developers.

While an immediate scaled deployment sounds tempting, this approach often fails without a proof of concept. It's best to start small, learn from a single team, repeat the same approach with a few more teams, and then plan a scaled deployment based on the knowledge gained.

For a successful proof of concept:

Pick one or two teams.
Identify the teams' scenarios, such as developer VMs or test environments.
Document current use cases.
Deploy DevTest Labs to fulfill the teams' scenarios and use cases.