Microsoft Dev Box for Microsoft engineers
We’re in an exciting time for technology. But to take advantage of the opportunities, it’s critical for developers to have access to the tools and resources that can help them stay productive and do their best work. At Microsoft, we’re migrating many of our developers to highly productive, cloud-based developer environments to help deliver exciting new innovations across the portfolio of our products. Over the last 5 years, many teams at Microsoft have experimented with various solutions, but in January of 2022, we started piloting Microsoft Dev Box with our Office 365 organization. Now, we’re excited to say that over 9,500 Microsoft engineers are using Dev Box. Microsoft Dev Box will be publicly available on July 2023. Here, we want to share our journey with Dev Box and the key learnings we’ve discovered along the way.
The challenge: Improving the productivity of hybrid developers using legacy development environments
The Development Environment is where developers spend most of their time, and as such, it has a profound effect on their productivity and satisfaction. But at Microsoft, the diversity of our products and services has resulted in thousands of unique and complex development environments. Developers often need the ability to move across different coding environments easily and quickly, to utilize build cache artifacts, and to keep their tools and packages updated and in sync with their project repository and associated CI/CD pipelines. Historically at Microsoft, developers maintained a high-powered, local desktop machine as their development environment. While this has given developers a sense of autonomy and control, it comes with a cost:
- Desktop configuration is left to individual engineers, requiring them to read through team- and project-specific guidance to configure and maintain their environments. Initial startup time often takes several hours or days and can result in small but significant differences across machines.
- Individual developers are responsible for ongoing maintenance to stay in sync with tooling, OS and library updates, and configuration changes introduced by the repository and CI/CD pipeline. This introduces added work for the developer, with larger repositories taking 3+ hours per week just to get current source and building artifacts.
- Niche and legacy tooling adds to the complexity of maintaining a development environment
- Developers must seed their local build environment with build artifacts. Typically this is done by initiating a “clean” local build, which can take upwards of 40 minutes depending on project size and local processing power.
- The cost is further increased when developers need to work across multiple repositories or projects which have different tooling and compliance requirements. At Microsoft, 50% of developers contribute to more than one repository every month.
Unfortunately, it’s not just the productivity loss and developer frustration that makes these machines a problem—every one of the independent environments must also be secure and compliant. Our teams are consistently innovating to face these challenges, but it’s not simply a matter of priority or resources. To address these issues, we need to change the fundamental approach to development environments.
What we have learned about hosted development environments
Across Microsoft, organizations have been looking at ways to migrate developer environments to the cloud, hosting environments on Microsoft VDI solutions. These services provide great solutions for virtualized environments but miss a few key capabilities crucial for developers:
- Building and keeping an image up-to-date with everything a developer needs (configuration, source, packages, binaries) is the key to improving developer productivity and is not a process that most teams have the resources to deliver.
- The image needs to be as secure as source code and cannot drift from GitHub or ADO permissions. This results in significant initiatives outside developers’ core scope and skillset.
- Teams have to contend with unique behaviors for each tool for hardware SKU availability, region support, administration and resource cleanup, governance, and abuse controls.
Our journey from early Dev Box pilots to a company-wide rollout
We started piloting Microsoft Dev Box with a few Office teams in January 2022. Our goal was to learn what it would take to address the core challenges our engineers face and tailor Dev Box into a product that enables developers to do what they love most—writing code! Initially, we ran into many of the same challenges as other teams that were using virtualizing desktops. We had to develop an imaging pipeline, instruct teams on configuring networks, and ensure access to appropriate internal resources. We learned a lot during this period, but a lot of those lessons have been incorporated into the Dev Box roadmap, with Infrastructure-as-code(IaC) team customizations as just one example (which you can sign up for the preview here).
What we started noticing was that even in this early-stage developers were excited to use the product, they already knew what was possible with Dev Box. The real challenge became how we scale this out to the rest of Microsoft.
We started by tying our Dev Box deployments directly to teams and the services/products they build:
- Dev Centers were assigned to an “organization,” a group of teams like the Developer Division, Office, or Intune, that anyone in that organization could use to access a bare minimum set of tools, source, and packages. It wouldn’t represent the full environment, but it provided enough to cut out a few hours of work for any developer.
- Projects were assigned to a “service group,” a smaller group of teams responsible for a product like Visual Studio Code. This is where we would define a “ready-to-code” image that could have a developer coding within just a few minutes. The permissions applied to the project ensure we maintain appropriate access to the source available on the image.
- We set up networks for each Dev Center to ensure users would have secure access to whatever resources they needed, in a region close to their developers, significantly reducing latency. We will be sharing our recommendations for network configuration in an upcoming whitepaper.
- Lastly, we set up the pools under each product so that the developers in each region had access to the image and SKU(definition) to meet their needs.
That might sound like a lot of work, but that’s the great thing about Dev Box. We approached both image creation and deployment using IaC. To set up a project, all a team needs to do is create a pull request (PR), and we create all the Dev Box resources they need automatically. The adoption rate demonstrated how effective this approach can be—in just the last four months, we have increased our usage from 400 developers to just over 9,500.
How Microsoft developers have responded to Dev Box
The most important success criteria for Dev Box at Microsoft is the feedback we get from developers. Is the product helping them to enjoy doing their job or not? In the initial survey, overall satisfaction numbers topped 80%. That isn’t just individuals kicking the tires, over 65% of responses indicated that Dev Box was being used as the primary development environment. Here are a few examples of what we have been hearing:
- “Really liked that the machine was available so fast and it had the enlistments I needed!”
- “Thanks for this exciting dev box infrastructure! In general, I really enjoy them—performance is great, and there is less for me to manage in general”
- “Dev Box finally made me give up my physical machine. It’s an amazing service.”
We have so many more opportunities with Dev Box and would love to add your voices to our own on where we take the product next. Click here to learn more about Dev Box.
Light
Dark