Azure DevTest Labs is a new developer service available on the Azure platform that provides a cloud service solution for creating and using Dev and Test lab environments. There are some issues with doing Dev and Test environments on premises: it can take a long time to get an infrastructure, the cost is significant, and so is the time and effort in creating a production-like environment. A lot of organizations are moving towards the cloud for Dev & Test environments; this is because the environment can be procured quickly, it has a lower cost, can be scaled as necessary, and the developers can start working directly with the production-like environment.
To do this with Azure, Microsoft provides Azure DevTest Labs. The lab is actually an additional construct in Azure, where particular Azure features can be subset for the Dev and Test teams to work in. Azure’s services can be selected based on exactly what the client and project requires, templates can be created and reused, and quotas and policies can be set for the lab. Azure DevTest Labs was offered as a beta-trial for users in late 2015, and is now openly available for usage as both a free trial and as a paid service. Like with Azure’s standard service, containers are supported in DevTest Labs as well.
Selecting a VM
From the main lab panel, you can directly select a virtual machine (VM) that you would like to work with. You can either choose from the VMs currently assigned to you or select an available VM from the lab that isn’t currently assigned to a team member.
The first thing that can be set for the lab is quotas. In the quota settings, you can set a monthly budget, the maximum amount of VMs per user, and the maximum allowable VMs for the lab.
For the budget, there is a usage chart that displays how much has already been spent, when it was spent, how much of the budget is remaining, and a projected out-of-budget date based on the usage history.
For the maximum allowable VMs per team member, it can be set as a general limit or can be tailored to individual team members; this is helpful when some team members require significantly more VMs than others because of their role, such as a team member running performance tests. The team total is also an important moderation measure for efficiency and cost, regardless of how many VMs an individual role may require. This should be calculated to be equivalent to the maximum amount of VMs per each person, but each lab should consider their own circumstances and set it up accordingly.
In settings tab, you can modify next parameters:
- Monthly budget that you plan to spent.
- The max number of VM’s per User.
- The max number of VM’s per User.
As an admin of the lab, you can also set which VM sizes can be used by the team when they’re setting up their VMs.
If you’d like to create your own VM rather than using one of the available ones that are already set up, you can do that as well. You can select a template for the new VM and provide it with relevant details such as name, login, size, and artifacts to install. The user interface can be easy to use if set up right, but it may require a team member to initially set up quotas, policies, and templates for your lab so that they can be reused as many times as needed.
Artifacts are components and tools that you have associated with your lab. From the artifacts tab, additional components can be added to the VM such as MS Office to customize what you want included in your Dev and Test lab. Likewise, parameters can be set for the installation of the artifacts.
Adding a new artifact is relatively straightforward:
- In first field you will be required to input an Artifact Name.
- Type the Artifact Description.
- Browse or upload the Script. The script is the most critical field, as it needs to actually install the desired component. For specific install instructions, the parameters can be set accordingly. Once the script is written and the artifact is created, though, it can be reused by the teams for as many VM setups as needed.
- Choose the right Parameters, such as Name, Default Value, Type and mark the check box if this parameter is required or not.
The templates are exactly as they sound – a formatted set of standardized features, and are very useful when the teams need to run identical VMs.
- A template contains a base image (OS); with a template, you’ll want it to install the most volatile components into the OS image, and then install the other, less-volatile components as needed.
- You’ll also have to select a VM size as the standard for that specific template.
- In artifacts, you can select the artifacts that you want associated with the template and the OS.
When you’re ready to create the new VM, there is an option to opt out of a scheduled shutdown for the VM. This is something to consider when running multiple VMs and test environments because some may need to be continuously running to handle information, while others may not. Policies can be set for both idle shutdowns and scheduled shutdowns. So if a VM is not being actively used for a given amount of time, it will shut down and save operating costs. The same can be set so that at a certain time, the VM will always shut down. If this is done, you’ll need to set a restart time as well or manually restart it. It should be noted that you will lose memory state after a shutdown, so plan the Dev and Test team should plan accordingly.
VM statuses can also be monitored through Dev Test Lab, showing how many are active, idle, and shutdown at given times. This can be reviewed to see if policies or usages should be adjusted for operational efficiency, amongst other uses.
Securing the Lab
In the lab, you have user roles. User roles are assigned to team members who are just using the lab, and all other privileges of the lab’s subscription are removed. This means that they will need to go through the lab itself to create VMs and follow policies. You can modify their permissions as appropriate for your situation to allow for things like creating VMs from outside the lab on the subscription.
VSO & TFS Integration
From Visual Studio Build and VS Release Management, Azure DevTest Lab can be integrated with VS Build and VS Release Management. Directly from VS Build and VS Release Management, you can use the command lines and actions on VSO and TFS to invoke environment building in the lab with templates while still applying all of the policies.
Azure DevTest Labs is a subset of Azure services particularly designed for Developers and Testers and their unique team needs. The templates provide methods of being able to quickly set up the environment needed for testing with a simple click and choose system, and is very versatile in its manageability with its quotas and policies. Another benefit to DevTest labs is that once an artifact, template, and/or VM is created and saved, it remains in Azure as a resource management file and can be shared with other teams as desired.