The following blog walks through the experience of defining and automating the creation of developer environments with the newly announced Teams Customizations feature in Microsoft Dev Box. This allows developer team leads or managers to define the software installed by default every time a developer creates a new environment, ensuring that every team member has the latest tools and frameworks needed to deliver on a project right away. This automates the typical process of using a combination of custom images, miscellaneous scripts, and manual configuration that is used in most organizations today. Moving to an automated approach enables developer teams to work more efficiently and not have to spend additional time configuring developer environments. If you are new to Dev Box, there may be some concepts that are mentioned below you may not be aware of. To learn more about the core concepts for Microsoft Dev Box, check out our docs page here.

What are Dev Box Customizations? 

With Dev Box, developers have the option to define the necessary tools, frameworks and settings they want pre-configured when creating a dev environment with the customizations feature. Customizations allow you to either link a customization file (defined as YAML)—via adding a catalog (either a GitHub or Azure DevOps Repository) to the dev center linked to your team’s projects—or upload a customization file directly during the Dev Box creation process. Below is an example of the second option.

Introducing Teams Customizations 

As a developer, being able to define your own environment makes it possible to get a setup that’s just right. Plus, it’s great to have the flexibility to upload or add that environment in a repo (either GitHub or Azure DevOps). There is one drawback with this individual approach, however. The responsibility is on the developer to define all the tools that are needed for a particular project. Wouldn’t it be much better if there was a way to define a project-wide customization that would be referenced every time a dev box tied to a particular project is created? This is what using Teams Customizations can do for dev teams, enabling dev leads or managers to define the environment an application is built in and ensuring it is consistent for every developer on the team.

This approach of defining a developer environment per project is similar to the concept of custom images with one large difference. Images can become stale, meaning that tools and packages may have updates that are not part of that image. What Teams Customizations provides is the ability to add an additional layer on top of the image, ensuring the latest versions of the required tools are installed.

Here is an example:

• Base Image contains Visual Studio 2022 and Docker Desktop

• Teams Customization added to install latest version of .NET, NodeJS, and Visual Studio Code with relevant extensions.

In the above example, the items listed in the Teams Customization could be part of the base-image, but once any of those tools require an update, the developer would be responsible for doing that once the dev box is created and they are logged in.

Teams Customizations eliminates the need for developers to make these updates, giving them a “ready to code” environment upon login, so they are that much closer to contributing without dealing with environment configuration. If the developer has additional tools or settings that they would like as part of their environment (for instance having Windows in dark mode, specific Visual Studio Code extensions, or a customized Windows Terminal enabled with Oh My Posh) they still have that flexibility with the individual customizations mentioned above.

Setting up Teams Customizations 

To setup Teams Customizations, we should assume a few things as it pertains to your role on your team and your access in the Azure Portal:

• You are a team lead or dev manager and are responsible for handling new developer or project onboarding

• You are (or have access to someone that is) the owner of a dev center or have write access on the Azure subscription

• You have access to a Git repo (either in GitHub or Azure DevOps) to store customizations that will be added to dev center as a catalog

The first thing you need when setting up Teams Customizations is to enable catalogs per project from within your dev center. That is done from the Settings section of dev center.

Once enabled, you can now add catalogs to your project. Catalogs act as containers for reusable workflows in dev center. They are leveraged by both Dev Box and Azure Deployment Environments. These workflows are stored in code repositories. In our case, it will be hosted on GitHub: isaaclevintest/contoso-co-eShop: A reference .NET application implementing an eCommerce site

In this repo, there are two folders that have to do with Team Customizations:

• .devcenter folder 
  • This folder holds the Teams Customizations themselves. For instance, here we have a customization for our frontend team.

• • This customization references a base image (Windows 11 24H2 in this case) that can be either defined by our IT organization, or one that is provided in the Azure Compute Gallery that we approve of.
  • On top of that base image, we are running three additional tasks
    • Run a winget command with a particular file as input (more on that below)
    • Install the Azure Developer CLI
    • Install Visual Studio Code
    • Install the necessary extensions needed for the frontend team
• .configurations folder 
  • Because Dev Box customizations (both Team and Individual) support PowerShell DSC (Desired State Configuration) for more complex tasks we can leverage DSC to do that additional work. Here is the common-config.dsc.yaml configuration that is referenced in the above customization

• • This DSC file completes the following tasks 

• • • Configures Dev Drive in the environment with a capacity of 50GB 

• • • Installs the Git CLI 

• • • Configures Git to use the default WAM (Web Account Manager) account, which will allow git commands to run successfully.  

If you look in both of these folders, you can see that we also have Teams Customizations for our backend engineering team as well. If you currently use other orchestration tools such as Ansible, you can leverage them as well via Dev Box Customizations.

Add Catalog to our project 

Now that we have a better understanding of what customizations will be run when new dev boxes are created, we can now link the catalog to our dev center project. To do that, we will go to the dev center project we want to add Teams customizations to, then go through the newly enabled catalogs experience for that project. Here is a video of that flow:

In summary, we will do the following things to add our catalog 

• Give the catalog a name 

• Choose Repo (GitHub or Azure DevOps) 

• In our case with GitHub, authenticate either via the GitHub App or a Personal Access Token 

• Pick Repo, Branch, and the path to our customizations folder in the repo

• Add catalog 

After some time, you will see that the catalog has been successfully added and synced. 

If the configuration of Teams Customizations is successful, you can see each individual customization in the Manager Image definitions area of the project 

From here, you have the ability to use Teams Customizations in one of two ways:

• Run the customizations on top of your preferred image (after the environment is created)
• Build an image with those customizations baked into it. This will create a new image that you could extend further if you like.

Create dev box pool for new image definition 

The next step to ensuring Teams Customizations will run when new dev boxes are created is to create a new dev box pool that leverages the recently created image definition that represents our Teams Customization. The following video walks through this process:

In summary, we will do the following things to create that dev box pool 

• Give the pool a name 

• Select the image definition we want the dev box to reference 

• Choose compute and storage of dev boxes that will be created 

• Choose additional settings that meet the needs of your dev box (network, privileges, auto-stop, stop time and licensing) 

• Click Create 

After the pool has been created, we can confirm that there are no errors, and we can create dev boxes with it 

Create dev box with Teams Customizations 

Now that we have enabled Teams Customizations on our project, and completed the necessary steps needed to create dev boxes with those customizations, we can go through the dev box creation process to create a new developer environment with those customizations. Here is what that flow looks like:

In summary, we will do the following steps to create a dev box:

• Give the dev box a name

• Since there is only one dev box pool for this project, there is no dropdown. If you have multiple projects and/or dev box pools, there will be a drop down to select the one that fits your needs

• Click Create

We can verify that our dev box is being created with those Teams Customization even before the dev box creation is done.

 You may recall that these tasks are the same as what are defined in our catalog from above.

Once the dev box is created and ready for use, we can connect to it using the Windows App and confirm that all our customizations have been completed, and we are ready to contribute to the frontend project immediately.

Conclusion 

Teams Customizations empowers developer teams not only to configure the tools needed to complete a project but also enables you to do this in a straightforward and autonomous way. With Dev Box, developers can focus on building solutions instead of managing environments.

You can start working with Teams Customizations today. To learn more about the inner-workings of the functionality, take a look at the docs and provide feedback to the team.