Virtual machines
An Azure VM is a scalable, on-demand computing resource provided by Azure. Azure virtual machines provide the flexibility of virtualization without the need to purchase and maintain the real hardware that runs it.
Artifacts
Artifacts are tools, activities, or software that may be added to lab VMs before or after they are created. Artifacts, for example, can be:
- Agents, Fiddler, and Visual Studio are examples of tools to install on the VM.
- VM actions, such as cloning a repository or joining a domain.
- You wish to test applications.
Base images
A base image is a VM image that includes preloaded and configured applications and settings. Base images minimize the speed and complexity of VM construction. Lab owners can select which basic pictures to make available in their laboratories. Users in the lab can construct VMs by selecting one of the various bases.
Claimable VMs
Lab owners or administrators can prepare virtual machines (VMs) with particular base images and artefacts and store them in a common pool. These claimable virtual machines are listed in the lab's Claimable virtual machines list. When a VM with such a setup is required, any lab user can claim it from the claimable pool.
When a lab user claims a VM, it is added to that user's My virtual machines list, and the user takes ownership of the VM. Other users can no longer claim or configure the VM.
Custom images and formulas
Custom images and formulae are tools in DevTest Labs for quick VM generation and provisioning.
- A custom image is a VM built from an existing VM or virtual hard drive (VHD) and might include software and other artefacts. Users in the lab can construct identical VMs using the custom image.
- A formula is a set of default settings for lab VM properties such as base image, VM size, virtual network, and artefacts. You can make VMs with the same attributes without having to define them every time. When you make a VM from a formula, you can leave the default values alone or change them.
Environments
An environment in DevTest Labs is a grouping of Azure platform-as-a-service (PaaS) resources, such as an Azure Web App or a SharePoint farm. ARM templates may be used to design environments in labs. See Using ARM templates to generate DevTest Labs settings for further details.
Distributed and collaborative development of Azure DevTest Labs resources
Distributed collaborative development allows several teams or individuals to create and manage a code base. The capacity to produce, distribute, and integrate knowledge is critical to the development process's effectiveness. This essential development idea applies to Azure DevTest Labs. There are numerous sorts of resources in a lab that are typically shared among laboratories within an organization. The many sorts of resources are divided into two categories:
- Internally stored resources within the lab (lab-based)
- Resources are kept in external repositories linked to the lab (code repository-based).
Lab-based resources
Custom virtual machine images
You can have a centralized source of custom images delivered to laboratories nightly.
Formulas
Formulas are lab-based and lack a distribution mechanism. Lab members do all formula development.
Code repository-based resources
There are two characteristics based on code repositories, artifacts and environments. This article discusses the capabilities and how to most effectively set up repositories and workflow to enable the customization of accessible artefacts and environments at the organization or team level. This process is based on a common branching technique for source code management.
Key concepts
Metadata and scripts are examples of artefact source information. Metadata and Resource Manager templates, as well as any supporting items like PowerShell scripts, DSC scripts, Zip files, and so on, are included in the source information for environments.
Repository structure
The most popular source code control (SCC) setup is to create a multi-tier structure for storing the laboratories' code files (Resource Manager templates, metadata, and scripts). Create distinct repositories for storing materials handled by the various levels of the business:
- Corporate resources
- Resources available across business units/divisions
- Team-specific materials are available.
Each of these levels is linked to a distinct repository, with the primary branch having to be of production quality. Each repository's branches would be for developing those unique resources (artifacts or templates). This structure is compatible with DevTest Laboratories since it allows you to link numerous repositories and branches to the organization's labs simultaneously. To minimize misunderstanding when there are similar names, descriptions, and publishers, the repository name is mentioned in the user interface (UI).
The figure above depicts two repositories: a business repository managed by the IT Division and a division repository managed by the R&D Division. This layered structure enables development while maintaining a better quality at the main branch while having numerous repositories linked to a lab enables greater flexibility.
Integrate DevTest Labs and DevOps CI/CD pipelines
DevOps is a process that combines software development (Dev) with system operations (Ops) (Ops). The system provides new software features, upgrades, and repairs that align with corporate objectives.
The DevOps methodology also includes:
- Creating new features in response to goals, use trends, and consumer feedback.
- When problems arise, repair, recover, and harden the system.
The continuous integration (CI) and continuous delivery (CD) pipeline is one component of the DevOps approach. A CI/CD pipeline is a process that transports information, code, and resources from a source control commit through a sequence of processes to create the system. Build, test, and release are all steps.
Azure DevTest Labs may be used in CI/CD processes. This article explores the use of DevTest Labs in business CI/CD build and release processes.
Benefits of DevTest Labs in DevOps workflows
A lab should concentrate on a team working on a specific feature. This shared focus allows for more rapid transformation while restricting negative consequences to a smaller population. Changes or problems occur in the lab without affecting anything else.
The shared focus enables the sharing of domain-specific resources such as tools, scripts, and Azure Resource Manager (ARM) templates. Developers may leverage shared resources to construct virtual machines (VMs) with the necessary code, tools, and settings. ARM templates generate lab VMs and lab environments using Azure resources. The templates generate resources dynamically or by generating base pictures that have been customized.
For example, the product is a standalone system installed on the customer's computer. DevTest Labs can construct lab VMs with customer applications, artefacts, and configurations loaded for rapid inner loop code testing.
Here are some advantages of employing laboratories in DevOps workflows:
- Focused access: Using a lab as a component links a specific environment with a restricted number of people. A lab is typically given to a team or group working in a shared area or on a single feature.
- Infrastructure replication in the cloud: A developer may easily build up a development ecosystem that includes a developer VM with source code and tools. A developer can also establish an environment equivalent to the production setup for speedier inner loop execution.
- Pre-production environments: For asynchronous testing, a lab in the CI/CD pipeline can operate many separate pre-production environments at the same time. You may deploy and manage various support infrastructures in a lab and create agents. development.
Use labs in CI/CD pipelines
The CI/CD pipeline is a fundamental component of DevOps. The pipeline combines code from a developer's pull request with existing code before deploying it to the production ecosystem. Not all resources must be in a lab for DevTest Labs integration. For a more durable resource, you might, for example, put up a Jenkins host outside the lab. Here are some examples of how laboratories may be integrated into the CI/CD workflow.
Build
The build process generates a bundle of components for testing and releasing. Building infrastructure dynamically provides you with better control. Labs may be used as destinations for build agents and other support resources in the build pipeline. DevTest Labs can restrict lab access, increasing build agent security and lowering the potential of accidental corruption.
Because a lab can have several environments, each construction can execute asynchronously. The build ID is a piece of environment data that uniquely identifies the resources in a given build.
Test
A CI/CD pipeline may automate the creation of DevTest Labs resources such as virtual machines (VMs) and environments for automated and manual testing. The pipeline generates VMs with various custom test setups using build information artefacts or formulae.
Release
Before deploying the code, the release process might employ DevTest Labs for verification. The procedure is identical to that of testing. DevTest Labs should not use production resources.
Customization
Azure Pipelines, an Azure DevOps Services component, includes activities for manipulating VMs and environments within specified laboratories. One method for managing the CI/CD pipeline is with Azure Pipelines. A lab may be integrated into any system that allows you to use REST APIs, run PowerShell scripts, or use the Azure CLI.
Some CI/CD pipeline managers already include open-source plugins for managing Azure and DevTest Labs resources. To meet the demands of the pipeline, you may need to apply custom scripting. When carrying out a task, employ a service principal with the proper role, Contributor, to gain access to the lab.
Frequently Asked Questions
What is Release in Azure DevOps?
Releases, also known as Release Pipelines, enable you to provide software to consumers at a quicker and less risky rate. Release pipelines enable you to fully automate software testing and delivery at several phases before production.
Explain variable and variable groups in Azure DevOps.
Variables allow you to save data that may be utilized in many processes. All variables may be changed and saved as strings. Variable Groups enable the usage of variables across different pipelines. Secrets can be stored in variable or variable groups.
How can we prevent the deletion of resources within a lab?
We recommend that you configure adequate lab permissions so only authorized users may delete resources or alter lab policies. Developers should join the DevTest Labs Users group. We propose that you only have two lab owners. To avoid corruption, this regulation extends to the code repository. Lab users have access to resources but cannot change lab policies.
Conclusion
This article extensively discussed the Azure DevTest Labs, its Environment, Labs based resources and its integration with Azure DevOps. We hope this blog has helped you enhance your knowledge relating to Azure DevTest Labs.
Check out our Azure CDN, Azure Media Service, and Azure Storage Monitoring articles. Practice makes a man perfect. To practice and improve yourself for the interviews, you can check out Top 100 SQL problems, Interview experience, Coding interview questions, and the Ultimate guide path for interviews. Do upvote our blog to help other ninjas grow. Happy Coding!
34+ registered 
