In a given calendar year, our staff can be working in a LOT of different development environments. While Axian as a whole tends to focus on Node.js, Java and .NET runtimes/toolchains, we are also often found working with systems that comprise everything from Python, to Golang, Ruby and beyond!
Needless to say this can create a dizzying number of (potentially conflicting) libraries, frameworks, and runtimes to keep tabs on (pyenv, nvm, goenv, rbenv anyone?).
Over the last 29 years, we’ve tackled this problem with everything from virtual machines, soft/physical machine images, shared environments, and now…containers!
Dev Environments: All we need to do is document this…
Developing in Containers
For the longest time, getting a full featured development environment hosted entirely in a container has been a bit of a pipe dream. While it’s easy to mount file systems in containers to share source code (nevermind I/O lag in certain OS’), enabling typical IDE capabilities like debugging and hosting/serving web applications from inside the container have been complicated to assemble and maintain. In 2019, this got a LOT easier with Visual Studio Code and a suite of Remote Development extensions produced by Microsoft and the open source community at large.
Essentially the development environment looks as follows:
VS Code Remote Containers: Sample development environment
Using the above, our target host environment has now been simplified down to:
- Visual Studio Code
- Docker Desktop
- Git Client
…and that’s it! We install the Remote Containers extension and we’re off to the races. This has dramatically simplified onboarding time as the development environment is now dictated by a source controlled Dockerfile and not a set of wiki instructions to be manually replicated/followed.
When someone onboards onto a project where the development environment has been containerized, they receive the following instructions:
- Clone down the repository
- Open the folder in VS Code
- Remote Containers extension notices that this is a containerized development environment and checks to see if a matching Docker image has already been built
- (Optionally) If no such image exists, one is built
- Production work begins!
VS Code Remote Containers: Building Dev Container for the First Time
Everything happens in that container. Hosting, debugging, compiling, even terminal/powershell sessions take place in that container. This not only simplifies onboarding onto projects, it keeps a pristine host OS that doesn’t need to be rebuilt every 18 months because the dev environment became too exotic to troubleshoot. Trust me, IT will thank you. Developers will thank you.
In fact, receiving all these accolades from groups that are normally stingy with praise will likely feel uncomfortable for a hot minute. You’ve been warned! 😀
Other Remote Development Scenarios
It’s impossible to talk about Remote Containers without touching on some of the sibling extensions. This same paradigm (pushing the dev environment into a container) ALSO exists for Windows Subsystem for Linux and SSH!
That’s right, assuming you have a Magic environment that’s troublesome to reproduce/containerize but you can still SSH into it, you still have a pretty full featured development environment using the same principles as above. Also, those who have wanted to develop on the smallest machine possible (Macbook/Air, or a 13″ XPS anyone?) the water has never been warmer. Since VS Code runs on MacOS, Windows, and Linux there are a LOT of host devices this can be piloted from (we still haven’t tried this from a Raspberry Pi :-D). The point is that your limitations on dev environment are now more related to keyboard and monitor real estate than CPU, Memory, Disk.
VS Code Remote SSH: Sample development environment
What’s Next
We continue to apply this paradigm to more projects and are now looking at leveraging Windows Containers to help with some of our more exotic project environments (think older Windows Server dependencies). There’s definitely an inflection point where diminishing returns start to materialize, but for any project where a lot of production staff are going to need to be onboarded and the development environment needs to be kept in sync/versioned over time, this technique offers a very quick recapture on time invested vs. time saved.
Works on my machine!
-Tyler