{"id":621,"date":"2025-01-29T17:00:08","date_gmt":"2025-01-30T01:00:08","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/develop-from-the-cloud\/?p=621"},"modified":"2025-03-05T09:51:31","modified_gmt":"2025-03-05T17:51:31","slug":"automating-developer-environments-with-microsoft-dev-box-and-teams-customizations","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/develop-from-the-cloud\/automating-developer-environments-with-microsoft-dev-box-and-teams-customizations\/","title":{"rendered":"Automating Developer Environments with Microsoft Dev Box and Teams Customizations"},"content":{"rendered":"

The following blog walks through the experience of defining and automating the creation of developer environments with the newly announced Teams Customizations<\/a> 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. <\/a><\/p>\n

What are Dev Box Customizations?<\/span>\u00a0<\/span><\/h3>\n

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<\/a> feature. Customizations allow you to either link a customization file (defined as YAML)\u2014via adding a catalog (either a GitHub or Azure DevOps Repository) to the dev center linked to your team\u2019s projects\u2014or upload a customization file directly during the Dev Box creation process. Below is an example of the second option.<\/p>\n

\"Image<\/a><\/p>\n

Introducing Teams Customizations<\/span>\u00a0<\/span><\/h3>\n

As a developer, being able to define your own environment makes it possible to get a setup that\u2019s just right. Plus, it\u2019s 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\u2019t 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.<\/p>\n

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.<\/p>\n

Here is an example:<\/p>\n