As a modern DevOps team you need different kind of environments during the realization of a software system. The availability of environments is of great importance for the speed of delivering that piece of value for the business. With this availability is often the problem which slows teams down. Often the environment is too late or the environment is wrong configured or both at the same time. Leading to frustration in the team and with the business.
Cloud.
Azure can be a solution for the environment needs of a team. When the team has access to an Azure Subscription than they can take care themselves of the creation and configuration of environments. A team member can create an environment the moment he or she needs it.
With this self-servicing capability, the team not only faster value to the business. But, also other cloud benefits like lower cost en less risk can be fulfilled.
Team environments.
A DevOps team needs different types of environments for their activities (read: Cloud usage flavors for Development and Test teams.). Team members need a desktop machine with their favorite development tools on it. For integration and validating an integration and test environment is needed by the team. Next to these two environment categories a team needs environments for their DevOps activities like CI and CD, but also for their task board, bug tracking database and load tests.
Every type of environment can be consumed from the Cloud and use different cloud provider capabilities. Most DevOps tools are available as a SaaS offering. For example, Visual Studio Team Services. Desktop machines with the IDE on it are hosted on an IaaS offering. The type of cloud platform usages of the Integration and Test environments depends on the type of system that is build. It can be PaaS, IaaS, a SaaS extension or Serverless.
Every environment type has its own characteristics en will have their specific benefits from the Cloud. An IaaS team member desktop machine makes it very easy and fast to onboard new team members. Ask yourself how long does it take for a new team member when entering the team room to make the first meaningful activity for the system. Like code push or test run, and investigate what slows this down, often the request for hardware, the installation and configuration of the machine takes days.
An Integration and Test infrastructure in the Cloud has the benefit that the team can provision this them self, multiple times a day and relieving the internal datacenter. A team also has the capability to run experiments. For SaaS based DevOps tools, the biggest benefit is in time. The team can simply use the DevOps tools they need, without losing time in setting up and configuring the DevOps tools.
Azure DevTest Lab.
Azure has a specific DevTest Lab service to manage team environments.
Via the Azure portal a DevTest Lab can be made. The most important configuration option is the storage type. The storage type is of importance because environments created and maintained in this DevTest Lab use the same storage type, which influences the speed and costs.
Why a specific Azure Resource as DevTest labs to manage environments? Team members with access to an Azure subscription can also make environments when the need them.
To answer this question, we need to look at the special needs these DevOps environments require.
DevOps Environment Needs.
To fulfill the benefits, cheaper and faster, the cloud promises when using your teams DevTest environments on it, more is needed than only co-admin rights on an Azure subscription by team members. (read: Insight and Self Servicing needs for Dev & Test Teams)
Not every team member is experienced with the possibilities of azure, building this knowledge slows the team down. another example that the ‘cloud promises’ needs support is on the costs. Team members will forget to switch of environments, which will make the costs go up constantly. These are two examples a DevTest Lab can help a DevOps team with will using the cloud for their environments..
Machine templates.
Azure DevTest labs offers support for provisioning new environments based on templates. These templates can be created by a DevTest Lab owner and used to create an environment by its members.
Azure Virtual Machine Images are the basis for a DevTest Lab Template. Azure marketplace contains many default images which can be used for a DevTest Lab template. All Azure Marketplace Images are available except several with specific license requirements.
A DevTest Lab administrator, probably a team members with knowledge about the system to be developed and the needs of the development environment, will create and configure the lab by selecting marketplace images and make them available via templates.
A selection of images made available for team members to create environments for their project.
(Administrators and member rolls can be configured at DevTest Lab level via ARM settings.)
Artefacts.
When a DevTest Lab user wants a Lab VM, it is often not enough to use a template with a base image. For example, when the team wants to use the environment for a browser tests, specific browsers are needed on the environment, or when a team member wants to use the environment for development activities specific development tools like Visual Studio, Fiddler and Notepad++ and Slack are wanted.
These additional artefacts can be added by the Lab user during the creation of an environment.
A DevTest Lab administrator can make Artefacts available for Lab users while configuring the Lab by adding an Artefact repository to it.
An artifact repository contains a directory structure ( on GIT or GitHub) with JSON and PowerShell files which can be attached to a DevTest Lab.
The structure of the JSON not too complex. Parameters, necessary when there is input necessary for a PowerShell script execution, will be visible in the DevTest Lab UI. A type of SecureString will be shown as a password input field.
An example of an Artifact repository can be found on GitHub.com/Sogeti. A public repo 
on https://github.com/Azure/azure-devtestlab.git.
A Cloud expert can make these artifact repositories and make them available to multiple DevOps teams.
Also read: How to troubleshoot failing Artifacts in AzureDevTestLabs
This one is an interesting DevTest Lab artifact repository: https://github.com/Azure/azure-blockchain-projects adding blockchain implementations as artifacts.
Roles.
A DevTest Lab requires different roles, with different knowledge and responsibility areas (read: Azure Dev/Test Lab on Azure Management Knowledge needs.). A Cloud expert will create reusable artefacts and helps a team with the setup and usages of environments in the cloud. This Cloud expertise is platform specific and offered to multiple teams. Often it takes too much time as a DevOps team to build up this deep technical knowledge for the time of a project.
The cloud expert delivers its knowledge via a service delivery model, supporting teams. The DevOps teams themselves have two other DevTest Lab roles. The DevTest lab administrator, the one who creates and configures the lab and the DevTest lab user, the team member who knows when a specific environment is needed
The amount of activities on a DevTest Lab also difference per role. A DevTest Lab user will create on a regular base different environments, starts, stops and deletes them per sprint. While an DevTest Lab administrator probably once every project or maybe once every release configures DevTest lab templates.
The DevTest lab user will work the most with the lab, this work should be than be done as easy as possible with the least amount of steps.
Custom Images.
A team needs multiple time a sprint the same type of environment. For example, all team members need a same development environment, or there is a need for multiple build servers, or multiple times a sprint there is a need for a clean test infrastructure. All these environments are specific for the project and it would save time for the DevTest Lab user when there are ready to use images of them.
Custom images are base images with custom software installed and configured on it, they can be used to create new instances.
The creation of custom images is already available from the early beginnings of Azure as a cloud platform. Microsoft Azure makes it easy to create them. Simply select a Lab VM, go to settings and select the option, ‘Create custom image (vhd)’.
During the creation of a Custom Image there is an option to execute ‘sysprep’. This removes all system specific settings and configuration. For example, users settings.
When a custom image is creation. a DevTest Lab user can select it to create a new Lab VM with the same software and setting on it.
A DevTest Lab administrator also can upload custom image via PowerShell, which are available the same way for the lab user.
Formulas.
Azure DevTest Lab formulas is another way to make the live of the DevTest Lab user easier. A Lab VM can be created based on a formula with predefined artifacts. A formula describes the steps to create a new Lab VM and executes these steps on a base image during the creation of the Lab VM.
A formula can be made by selecting an existing Lab VM, which is created via the selection of artifacts (see previous paragraph). The formula will contain these artifacts and the parameter values will this Lab VM was created.
With formulas a DevTest Lab user can easily create exactly the same environment based on a clean base image, this is the main difference compared with custom images.
Machine templates, custom images, artefacts and formulas help DevTest users to create new environment. The cloud expert can make the artefact repositories, custom images and upload them, the DevTest Lab administrator configured the Lab by selecting the artifact repository and makes image available for the lab users. The lab user will be with these capabilities faster and more consistent in creating environments for the team.
Policies.
With Base Images, Artifacts, Custom Images and Formulas team members can easily and in a consistent way create new environments the moment they need them. With this the promise of faster enabling team members is fulfilled. But, to also make the use of the cloud for DevTest environments cheaper, faster creation of them isn’t enough.
A DevTest Lab administrator can set several policies to keep the cost in control.
VM Size Policies.
The maximum size a Lab VM can be configured can be set. The Lab admin can control that team members are not allowed to create Godzilla sized and prized VM’s.
Next to the size of the Lab VM, an administrator also can set a maximum policy on the amount of Lab VM’s a user can create.
Auto start and shutdown policy.
The auto start en shutdown policy helps team members to the optimize usages and the costs of Lab VM’s. for example, when a Lab VM is used a team member desktop who is working weekdays from 9 to 5 a scheduling can be configured that the Lab VM is only On during these working hours. A team member never would forget anymore to shut down his VM, resulting in unnecessary costs. It is important to not forget the schedule, for example when you are heavy in work and the automatic shutdown is triggered, losing all your work.
In the DevTest Lab is main screen and overview of Lab VM’s is shown with the information if the machine is started or stopped and if an automatic start or stop is scheduled. Auto stop is very useful when you only use a machine on an adhoc base.
Costs
Setting policies on costs is important for a DevTest lab because so many VM’s are created, stopped started and deleted that it is very hard to control the costs. Having a policy and insight what the costs are given the team (and manager) a more comfortable feeling in using the lab (read: Make your team cost aware … cost driven development.). The experience is that when it is unclear what the costs are that team members don’t dare to create more Lab VM’s.
In a graph the estimated costs for the billing month is shown. Per day the real costs are updated. Keep in mind that the costs are not aware of an Enterprise Enrolment with usages discount benefits. (more: Why Cost Thresholds?)
A soft costs boundary can be set on the chart, this give an idea which day this boundary is reached.
Next to costs per month also an overview of the costs per resource is available.
Policies on costs, size, amount and schedule are helping the team to use a DevTest Lab in an efficient way and keeps the costs in control.
Read: Two more things to keep your cost on track in DevTest Labs
Integration
A DevTest lab as a standalone solution is already valuable for team to provision fast and flexible environment. An integrated solution, connected to the CI/CD pipeline and toolchain is even more powerful. An integrated solution can automatic make environments the moment they are needed and remove them when the task is done.
A scenario where the build makes a package of the system, installs it on a Lab VM and again makes a new image from ready to be used by team members for validating or for automatic validating is very nice costs efficient solution.
PowerShell
For Azure DevTest Lab there are several Azure PowerShell commandlets available on GitHub.
https://github.com/Azure/azure-devtestlab/tree/master/PowerShell/AzureRM.DevTestLab
- · Get-AzureRmDtlLab
- · Get-AzureRmDtlVMTemplate
- · Get-AzureRmDtlArtifact
- · Get-AzureRmDtlVhd
- · Get-AzureRmDtlVirtualMachine
- · New-AzureRmDtlLab
- · New-AzureRmDtlLabStorageContext
- · New-AzureRmDtlVMTemplate
- · Add-AzureRmDtlVhd
- · Start-AzureRmDtlVhdCopy
- · New-AzureRmDtlVirtualMachine
- · Remove-AzureRmDtlVirtualMachine
Enough for now to support the described scenario.
Build Task
An even easier integration is the VSTS Build Task to create Lab VM’s during build. These tasks can be found in the Visual Studio Team Services marketplace. https://marketplace.visualstudio.com/items?itemName=ms-azuredevtestlabs.tasks
Read: Using VSTS Release Management for Continuous Deployments to AzureDevTestLabs and General availability of Azure DevTest Labs – VSTS extension
Conclusion.
Azure DevTest Labs offers support for teams in the creation and usages of environments. It will make teams faster, efficient and more flexible.
Azure Dev Test Labs is in development the main focus is on Lab VM’s, IaaS. I expect in later stage also other Azure resource types will be supported (like in OneShare) and more configurable policies will be supported. Maybe even a mobile app (see bottom of this post).
Related post: The Time of DevTest Labs is over. DevOps to the Max.
