Developers today typically work on multiple projects simultaneously, with each project requiring different tools and configuration requirements. Being able to have a dedicated environment explicitly configured to that project unlocks enhanced developer productivity and reduces outside noise, allowing developers to focus just on the work they are doing. This also extends to developers who may not work in a project often, and the burden to have their environment ready at any point in time to contribute to that project can lead to an increase of cognitive load. Ideally, a developer would be able to create a new environment, do whatever work is necessary (review a Pull Request for instance) and when the environment is no longer needed, it can be deleted. This idea can be coined as an “ephemeral environment”. In this blog post, we will investigate how we can satisfy this goal with Microsoft Dev Box and the new feature “Teams Customizations”

This blog post is a continuation from a previous blog post where we talked about Teams Customizations for Microsoft Dev Box and how they accelerate the developer onboarding experience, as well as empower leads for developer teams to ensure all the right tools and settings are present when a developer joins the team and begins work.

For an example of how the concepts from both these blogs can be realized, take a look at this end-to-end video of using Teams Customizations to make the life of developer teams a little better.

Standard PR Review Workflow

Now we have Teams Customizations configured for our project, and developer teams can create dev boxes with all the needed tools to complete their work. Let’s take an example. Our team has a workflow where a senior member of team performs code reviews when a pull request is opened in our code base. The typical workflow to validate a pull request before we merge those changes is as follows:

• Ensure all automated tests are run (this can be validated in GitHub Actions)
• Check out the pull request to validate the change meets the needs of the request
  • This usually is done by opening the solution in Visual Studio 2022 and debugging it

This process is essential to ensure that multiple developers have seen the code that will be merged in and prevent the possibility of introducing bugs into our code base.

The problem with this process

This process is not without faults. It can be quite challenging for developers to validate a pull request, especially if it is a fairly large change. This is due to the fact that developers are typically working on their own pull requests for new features or bug fixes. So in order to checkout that pull request, a developer will need to get to a comfortable point to either commit the active changes they have, or rely on stashing those changes via Git. This breaks a developer out of their flow and doesn’t facilitate being able to switch contexts back and forth.

A potential solution

hile a routine experience, this process is not ideal for developers. It can be quite challenging for developers to validate a pull request, especially when it is a fairly large change. This is because developers are typically working on their own pull requests for new features or bug fixes. As a result, if I want to check out someone else’s pull request, I will first need to get to a comfortable point to either commit the active changes I’m working on or stash those changes via Git. Unfortunately,, this breaks me out of the flow and makes it hard to switch contexts back and forth between my own PRs and my teammates’ requests. This is just one example of how my productivity can be decreased when having all my development work done in one environment.

A better way to balance different developer activities

We’ve been thinking about how to make this transition between workflows better for developer teams, and we came up with a solution. Since we are already using Dev Box to do our development work, we can also use it to create environments for review tasks. We can also streamline the process to ensure the review environment has the latest version of our code base, along with the branch that has work in the pull request cloned onto the machine. To accomplish this, we will leverage dev box customizations for individuals, which allows a developer to upload bespoke customizations when they create a new dev box.

Here’s what the workflow for reviewing a pull request looks like:

• Developer gets notified that a PR has been created
• Developer will obtain a generated customization file
• Developer will create a new dev box using the Developer Portal and include that customization file when creating

The above workflow will leverage GitHub Actions, which we already have configured to our code base when commits or pull requests are open. We will create a new workflow that generates a customization file that has the relevant git commands needed to checkout that PR, which in this case is fetching the origin of the new pull request and checking it out local. That GitHub workflow would look like below:

This workflow will run every time a new pull request is opened OR when commits are made to that the origin mapped to that pull request. When the workflow runs, it will do the following things

• Get the number of the pull request using GitHub Actions event information
• Update a template yaml file that contains placeholders with that pull request number
• Upload that newly updated yaml file to GitHub Artifacts so others have the ability to download it
• Add information about the artifact that will show up on the GitHub Action Summary page. That may look like this

Now all the developer needs to do is download the artifact via the link, go to the Dev Portal which is linked in the summary, and create a new dev box with that customization file. Here is what that experience would look like:

Once the dev box is created, the developer can connect to it via the Windows App and validate the branch for the pull request is already checked out. Here is an example of that using git bash and Visual Studio Code.

Conclusion

With Microsoft Dev Box and Teams Customizations, developer teams can build processes to more seamlessly review and test changes that are made in specific pull requests, limiting the need for developers to switch the context of their environment. Little things like this improve the day-to-day developer experience and this is just one way you can use ephemeral environments with Dev Box today, and on step closer to the dream of having completely ephemeral environments, where a change can trigger the creation of an environment, and after that change is reviewed, the environment is no longer needed and can be deprovisioned. To learn more about the inner-workings of how Teams Customizations can make this happen, take a look at the docs and provide feedback to the team.