This blog post will be part one of a three-part series on Visual Studios Code Remote – Containers. Prior knowledge of Visual Studios Code editor is recommended to better understand the items discussed in this series; more information can be found here. Part one will explain the general concepts of utilizing VS Code Remote – Containers as a development environment and why this can be beneficial to use in conjunction with projects. Parts two and three will go into more detail about both basic and more advanced setups and configurations that can be utilized for projects.

 

First off, what is Visual Studios Code Remote – Containers? It’s an extension built for the Visual Studio Code editor that uses a Docker container as a full-featured development environment. It will open any folder inside a container to take advantage of VS Code’s full feature set, enabling the creation of a code controlled environment to develop inside. Requirements for this extension typically include Docker Desktop and a glibc based Linux image. More information about the requirements can be found here.

 

Add Repeatability to Your IDE Setup

With VS Code Remote Containers, the advantages in regards to environment repeatability are massive: 

  • It is very easy to repeatedly provision the same coding environment in seconds.
  • The coding environment itself can easily be adjusted and configured all the while having the benefits of being version controlled alongside the rest of the project.
  • Whenever changes are made to the development environment, a developer can rebuild the container to have the newest changes and settings applied.
  • It removes any versioning issues that can easily arise from installing items on different machines at different times.

Having a repeatable development environment allows teams to be able to create a dev container that exactly, or at the very least closely, mimics the same environment that is used to build and deploy the project. This vastly reduces the chances of running into a situation where work is created and tested on a local developers system, but then fails somewhere within the CI/CD pipeline process due to some sort of inconsistency between development systems. The pipeline can fail initially due to package versioning discrepancies and easily be compounded by having multiple developers committing and pushing code for the CI process.

VS Code’s development container uses a fully baked-in image that takes away all of that time spent installing and maintaining language and package versions. A developer no longer needs to worry about dependency issues can crop up between projects running different versions. This highlights another one of the great benefits of working inside a dev container, the ability to develop within a sandbox environment. This allows a developer to start coding on a project with different languages and versions installed inside the dev container compared to what they have installed and configured on their local system.

 

Centralize and Manage VS Code Extensions Seamlessly

A developer can greatly cut down on the number of extensions that are installed and enabled on their local installation of Visual Studio Code. Having a small set of key extensions that are used across all projects cuts down on the IDE clutter and reduces the total number of custom settings needed. This will not only speed up the launch time but also lessen the CPU and Memory load. Additional project-specific extensions and settings can be installed and configured in the project’s development container. For example, installing a collection of Ruby specific extensions along with their respective custom settings. In addition to installing a pack of extensions for the main language, the container can have extensions that are needed to help create and develop just a few files, e.g. Terraform and Markdown. This can be done over and over again for each project and allows for much greater customization for developing multiple disparate projects side by side.

All that is needed to get a project working inside the dev container are two files in a root directory named .devcontainer.

The first, is a file that defines the actual Docker image that is created and from which the project will be developed inside. 

The other file is a JSON file that defines the configuration for the dev container itself.

 From this JSON file, a developer can configure things such as the name of the development environment, point to the Dockerfile, as well as define extensions and settings to be used for the dev container. Once a project has the required files in place, whenever a developer opens the project in Visual Studios Code, they should then be greeted with a pop-up window in the lower right-hand corner asking them if they would like to reopen the project in the Remote Container.

Visual Studio Code Remote Container pop-up window prompting to reopen project in dev container

Alternatively, the dev container can be opened from the Command Palette.

Visual Studio Code Remote Container Command Palette option to reopen project in dev container

Afterward the project is opened and the configurations and settings are applied to the dev container. The developer will then have all of the additional extensions and items installed alongside the docker container at their fingertips to develop the project.

 

Accelerate Developer Onboarding with Remote Container Setup

Seemingly every developer and project owner can benefit from developing their project from within one of these dev containers. It is especially useful for teams with multiple developers, perhaps working in a centralized office, remotely, or a mixture of both, as it creates an idempotent developing environment for anybody who will be working on the project. It is particularly helpful for those who struggle with package installations and the inevitable dependency clash as the dev container will already have these items and potential issues hashed out. This is also a great way to ease the learning curve for new developers to start contributing to team projects as all of the setup legwork to start developing is already completed. Developers can clone a project, open it in the container environment, and then start coding and contributing near instantly. This can be set up in each project’s repository, whether it is private or public. Ideally this will be implemented at the start of each project, but it is very easy to implement at any time to already existing projects. Once this process has proven how useful it is for teams and projects it can be added to the standardization procedures plan for creating and starting new projects.

 

An Agile IDE Strategy

Summing up, the Visual Studios Code Remote – Container extension, when configured and used properly, proves to be an invaluable tool for developers working on a single or multiple projects. It is easy to set up and get started with, it also provides an easily reproducible environment for developers to start contributing to projects with basically zero setups on their part. It takes away all of the potential issues with locally installed system package versions and dependencies that some can run into when getting started with a new project. With this, it drastically reduces the time it takes a developer to get onboarded with a new project or team. Using the dev container lessens the likelihood of any build discrepancies between local dev systems and the CI/CD pipeline. Setup is quite easy and can be configured from the start of a project or added at any point to already existing projects. It also has the benefit of reducing the need for numerous locally installed extensions that could be needed to cover all of the different projects that a developer works on since a base set of extensions can be installed and the project-specific items are tied to the dev container.

 

The next post in this series will dig deeper into more technical aspects of the Remote – Container extension. It will go over the installation and setup process, as well as go over some basic setup items. The aim will be to add some further context by going over actual use cases and some gotchas and findings from initially working with the extension.

 

Stelligent Amazon Pollycast
Voiced by Amazon Polly