Accelerate developer onboarding with the configuration-as-code customization in Microsoft Dev Box

As developers, we all know how long and tedious it can be to onboard to a new project. We have heard feedback from customers that it can take as long as 3-5 days to get a dev workstation up and running once a machine is in hand. Manual set up of dev environments can be error prone, time consuming (involving many readmes), and be a real point of frustration. The good news is that it doesn’t have to be this way.

 

Instead of waiting to get into the flow and do meaningful work, developers should be able to spend most of their time focused on their code. At Microsoft, we want to make the dev experience better, and one way to do this is by automating setup of developer environments on Microsoft Dev Box with a configuration-as-code model. Today, I am excited to announce that the Microsoft Dev Box configuration-as-code customization feature is now in preview.

 

Configuration-as-code customization overview 

 

Dev Box provides developers with on-demand access to cloud-based workstations that can be preconfigured by dev teams for different projects, cutting developer onboarding times from days to minutes. Now, you can use customization in Microsoft Dev Box to take your workstation the last mile and get a more fully personalized and ready-to-code machine. Dev Box uses VM images to define its ready-to-code dev boxes, and config-as-code customization features build on top of these base images. This enables developers to create custom configurations for their team or themselves that automate common setup and onboarding tasks as code. As a result, the process of defining what you need on a dev box can be as easy as submitting a code change.

 

But customization doesn’t only help streamline dev workflows. It also frees up platform engineers and IT admins from custom image management. And while they don’t need to be involved in dev box customization, admins still control the guardrails in which developers operate, as well as the components they can use in their configurations. It’s this combination of capabilities that helps teams ensure dev boxes meet the unique needs of the project team as well as the compliance requirements of their organization. Read on to learn about how Dev Box customization makes this paradigm of self-service with guardrails achievable.

 

Creating your first customized Dev Box

 

Tasks are the reusable ingredients you can use to author your configuration, and platform admin teams can choose which tasks are available to their developers by defining a Catalog of tasks. A Catalog is a Git repository attached to your dev center and can be hosted in GitHub or Azure DevOps (AzDO). In this case, we’re going to provide a GitHub repository with a standard set of default Tasks to help you get started with the quick start catalog option, which provides four tasks: winget, git-clone, choco, and a generic PowerShell task.

 

All platform engineers have to do to set up a catalog for their developers is:

 

1. Go to the Azure portal, and navigate to your dev center.
2. In the left menu under Environment configuration, select Catalogs, and then select Add.
3. In Add catalog, pick “Microsoft’s quick start catalog” and “Dev box customization tasks” as the quick start catalog type. Then, select Add:
4. In Catalogs for the dev center, verify that your catalog appears. If the connection is successful, Status is Connected.

 

 

The dev team now has a catalog of tasks they can use as building blocks to customize their dev boxes. Tasks run under a system context, and it gives platform administrators the ability to set guardrails and pre-approve allowed tasks for their dev teams. The QuickStart catalog gives you an easy way to get started, but be sure to create and attach your own catalog based on your organizational requirements and policies. 

 

Now developers can author a dev box configuration by creating a Dev Box customization yaml, the new file format you’ll use to customize your dev box. To try this out, you can download an example yaml configuration from our examples repository. This example configuration installs VS Code and clones down the OrchardCore .NET web app repo to your dev box. To create a dev box with this configuration, sign into the Microsoft Dev Box developer portal and use the “Add customizations from file” button to select this file.

 

 

Your dev box will be created with your base image, and the customizations you specify will be applied on top of it.

 

Storing configurations alongside your code in Azure DevOps

 

Team or project leads can streamline onboarding onto a codebase by committing their Dev Box configuration as a workload.yaml to their team’s codebase in AzDO. This will contain all the steps (packages) required to work on it, and make it that much easier for their developers to get started. All developers need to do then is paste in the clone URL with this repository when creating a dev box, and the service will fetch the AzDO repository and apply the configurations defined in that repository’s workload.yaml. With only a few clicks, the team now has access to ready-to-code dev box.

 

 

For this flow, we are using AzDO repositories, but stay tuned for GitHub support coming soon!

 

Authoring Dev Box configurations

 

The core of a file is the tasks section—this is where you’ll specify additional software to install and which settings to apply when creating a new VM.

 

With the Dev Box VS Code extension, writing, testing, and iterating on your configurations from your Dev Box are as easy as hitting F5. There’s no need to create a new Dev Box each time you want to test out a configuration. You can just download the extension from the VS Marketplace. From there, you can use the command palette to understand what tasks are available to you (from catalogs of Tasks attached to your dev center), and copy over snippets to, say, a devbox.yaml. You can execute this yaml configuration on your Dev Box by hitting F5, or by using the command palette (Dev Box: apply configuration). Download the extension here.

 

Using secrets from Azure Key Vault in your configuration

 

But that’s not all. You can also use secrets, such as personal access tokens, from Azure Key Vault in your yaml configurations to clone private repositories (with the git-clone task), or with any custom task you author that requires an access token. First, make sure to give your dev center project’s managed identity the Key Vault Reader role and Key Vault Secrets User role on your key vault, and any user (or group) who should be able to consume that secret when creating a customized Dev Box the Key Vault Secrets User role on that key vault. Be sure to also grant the Secrets User role to each user or user group who should be able to consume this secret during the customization of a dev box. You can now reference this secret in your yaml configuration in this format, using the git-clone task as an example:

 

 

If you wish to clone a private AzDO repository, you don’t need to configure a secret in Key Vault. Instead, you can use "{{ado}}", or "{{ado://your-ado-organization-name}}" as a parameter, and this will fetch an access token on your behalf when creating a Dev Box. The access token fetched has read-only permission to your AzDO repository, and the git-clone task in Quickstart catalog can use this access token to clone your repository. Here is an example:

 

If your organization's policies require you to keep your Key Vault private from the internet, you can set your Key Vault to allow trusted Microsoft services to bypass your firewall rule. 

 

 

Creating Tasks and Catalogs to meet compliance needs

 

Of course, config-as-code customization not only gives developers flexibility to define their dev box configurations. It also gives admins a way to enforce guardrails on these config files and meet their unique needs of the enterprise by defining what can be used in these configurations. Think of it as pre-assembling the sets of available building blocks that teams can use to build their dev box VMs.

 

Platform engineers have a couple options for setting up these building blocks. First, they can create their own repository of tasks in AzDO or github and attach it to a dev center, use the Quickstart catalog, or by create their own private fork of the Quickstart repository (microsoft/devcenter-catalog (github.com)).

 

Second, platform engineers and admins can create their own Tasks using any existing PowerShell scripts they have at their enterprise: all they need to do is create a task.yaml file for a given PowerShell script, and commit both the powershell script and the task.yaml annotating it to the repository that defines your catalog of tasks. For example, this task.yaml calls the powershell script “MyScript.ps1”, and declares parameters that should be passed to the MyScript.ps1, from the devbox.yaml that uses this task:

 

 

For more examples of Tasks, check out our Quickstart catalog repository: devcenter-catalog/Tasks at main · microsoft/devcenter-catalog (github.com)

 

Using the WinGet Config to customize your dev box

 

Last year, the Windows team announced the WinGet Configuration, a config file designed to consolidate manual machine setup and project onboarding to a single command that is reliable and repeatable. WinGet Configuration enables you to take the same config-as-code approach to define the unique sets of software and configuration settings required to get your Windows environment in a ready-to-code state for repos that you work on. These configuration files can also be used to setup a VM in Microsoft Dev Box, by leveraging a WinGet task that we include with the default set of setupTasks mentioned earlier. This is one more way that dev teams can use customizations to combine tasks and get the right configuration for their unique needs.

 

 

Want to learn more?

 

Check out our demo of Dev Box customizations that walks you through the process of how to create a ready-to-code environment.

 

 

Customize your first dev box today

 

Dev Box GA’ed in July 2023, and the Dev Box customization feature is now in preview. We’re excited to open it up to the wider developer community and see how customizations can give you quick access to the exact tools and configurations you need to start coding. If you're new to Dev Box, start a proof of concept today! Follow our Getting Started instructions and set up your instance to try out the new Customizations capabilities. We look forward to hearing about it.

 

Additional Microsoft Dev Box resources: https://aka.ms/DevBox/Resources