In past blogs, I have discussed development containers (dev containers) in detail, from explaining their general mechanics to showing how they can bolster a team’s build automation. As a brief recap for the uninitiated: dev containers are a way of encapsulating a developer’s setup into a container, typically a Docker container. As a practical example, rather than forcing a new teammate to manually install and configure all the necessary tooling before contributing to a project, they can leverage a team’s devcontainer.json definition file to quickly spin up a fully configured development environment.
Microsoft has championed this workflow over the past few years, offering tight integration with tools like VS Code and Codespaces to make containerized development as seamless as possible. At the time of writing, the developer experience has reached a point where I honestly prefer to operate within a dev container for certain types of projects. When I open a team’s codebase within VS Code and it informs me that they have provided a dev container to use, I have higher confidence that I’ll be using the same versions of their tools and seeing the behaviors that they expect.
I’ve even come to trust these setups more than an equivalent set of Dockerfiles or docker-compose scripts, just because the simplicity of the ecosystem makes it more likely that everything is well-maintained and configured correctly. It’s easy to see how these standardization and automation benefits can be a huge boost to teams…once they’ve adopted the right tools to integrate with them.
But what if you don’t want to use VS Code?
