Zum Hauptinhalt wechseln

 Subscribe

Azure DevTest Labs is an Azure service that enables IT admins to create cost-controlled, self-service labs for developers and testers to quickly create environments in Azure, while minimizing waste and optimizing cost. We announced the service general availability last May and have since continued to expand on how to solve our customers’ real life scenarios. Today, as Microsoft Build 2017 is happening in Seattle, we would like to take this moment to look back all the key functionalities we've shipped since the Connect() conference last November, and explain how they can help you in various scenarios.

Targeted scenarios

Our customers have been using DevTest Labs in the following scenarios:

  • Developer machines
  • Test environments
  • Training/education
  • Trial/hackathon/demo

In the developer machines scenario, DevTest Labs makes it very easy for IT teams to enable a cost-controlled, self-service environment for developer teams, including a set of out-of-the-box cost control policies, visibility to lab spending and projection, and various options to set up labs. Developers have the flexibility to quickly compose their own development machines on demand by using the reusable templates, such as Azure Marketplace images, custom images, formulas, and Azure Resource Manager templates, and artifacts under the policies defined by the IT team. The needs are satisfied for both IT teams and developers. The IT team gets the control, and developers are happy about the agility.

Figure 1: Use DevTest Labs for developer machines

Similar, in the test environments scenario, you can test the latest version of your application by quickly provisioning Windows and Linux environments using reusable templates and artifacts. DevTest Labs provides a rich set of REST APIs, including a .NET SDK, CLI commands, and pre-made VSTS tasks that help you to easily integrate with your deployment pipeline to provision on-demand environments. You can also scale up your load testing by provisioning multiple test agents in the lab. Once the testing is done, you can also create your golden image from testing machines and make the image available immediately for all the lab users through a single step.

Figure 2: Use DevTest Labs for test environments

In addition to Dev/Test environments, you can also create pre-provisioned environments for training and education. In the classroom scenario, a set of identical VMs are created in a shared VM pool before the class starts. Students in the class simply click a button to get a VM as needed. All the VMs can be automatically cleaned up after the class. Check out the guidance Use Azure DevTest Labs for training for more details.

Figure 3: Use DevTest Labs for training/education

Similarly, in the trial/hackathon/demo scenario, lab users pick a machine from the VM pool in DevTest Labs as needed. Once the event is over, the lab can automatically clean up all the VMs for the next event.

Figure 4: Use DevTest Labs for trial/hackathon/demo

What's new since last November

In order to better serve the above scenarios, we shipped the following key features since November:

  • Managed disks support: With this support, storage and cost management in Azure DevTest Labs becomes easier. Prior to the introduction of Managed Disks, when you created more than a few dozens of virtual machines in a single lab, DevTest Labs created additional storage accounts to host those VMs OS disks to optimize the disk read/write performance. It also replicated custom image VHD files across all those storage accounts to minimize the VM creation time, given the latency in cross-storage VHD copy when creating VMs.

    Managed disks simplify this story by automatically managing storage accounts in the cloud instead of in customers’ subscriptions. Disk read/write performance and VM creation time are both optimized without you managing any storage accounts nor replicating the custom image VHD file.

  • Claimable VMs: With this, lab admins can prepare VMs and put them in a shared VM pool; lab users can then pick, also know as “claim”, a VM from the pool for them to use without spending any time to create it from scratch.
    Figure 5: Claimable VMs
    This is very helpful for a couple of different scenarios:

    In test scenarios, claimable VMs that are installed with the latest build for testing can be generated automatically from the release pipeline. Developers and testers can then claim VMs with their desired build from the pool for further testing or validation without waiting for VM provisioning.

    In the training/education scenario, claimable VMs make it easier for trainers and teachers to get all VMs ready before a class. Because all the VMs for the same class are identical, students can ask the lab to pick a random VM from the pool for them at the beginning of the class.

  • Batch creation of identical VMs: It’s very likely that you want to create multiple claimable VMs that are identical, so that different lab users can claim their own VMs with the same configuration, e.g. testing the same build, VMs for students in the same class, etc. DevTest Labs supports the creation of multiple, identical VMs from the same VM image and artifacts all at once. The only additional thing you need to do is to provide the number of VM instances in the advanced settings when you create a VM. Of course, the VM quota policies set at the lab level still applies regardless of how many VMs you are going to create.
    Figure 6: Create multiple identical VMs in a batch
  • VM auto-expiration: In order to make VM clean-up easier, you can now also set an expiration date/time when you create a VM. At the specified expiration date/time, DevTest Labs automatically delete the VM. This capability enables you to fully focus on creating the right VM without taking any extra effort later to manage the VM retirement.
    Figure 7: Create a lab VM with an auto-expiration date/time
  • Shared public IP address: In the case that a lot of public-facing VMs need to be created in a lab, DevTest Labs provides a solution to share the same public IP address with those VMs. It can help you reduce cost and avoid exceeding the public IP address quota in your Azure subscription. Once a VM uses a shared public IP in the lab, it will be automatically assigned to a unique port number, which will be used together with the shared public IP address when you connect to that VM. Lab admins can control whether lab users can use this functionality or not through the lab settings.
    Figure 7: Create a lab VM using the shared public IP address

To learn more about these features and other functionalities we've enabled since last November, please read our main announcement on the Azure DevTest Labs team blog. You can also watch a live demo for all of these features through our Build 2017 video session: Azure DevTest Labs Updates.

To get latest information on the service releases or our thoughts on the DevTest Labs, please subscribe the RSS feed of this team blog and our Service Updates.

The release of this feature is just one stop. There are still a lot of things in our roadmap that we can’t wait to build and ship to our customers. Your opinions are valuable for us to deliver the right solutions for your problems. We welcome ideas and suggestions on what DevTest Labs should support, so please do not hesitate to create an idea at the DevTest Labs feedback forum, or vote on others’ ideas.

If you run into any problems when using the DevTest Labs or have questions, we are ready at the MSDN forum to help you.

  • Explore

     

    Let us know what you think of Azure and what you would like to see in the future.

     

    Provide feedback

  • Build your cloud computing and Azure skills with free courses by Microsoft Learn.

     

    Explore Azure learning


Join the conversation