The 3 Musketeers and VS Code Remote Containers

At Amaysim we apply the 3 Musketeers pattern to a lot of our projects, especially for building, testing and deploying our microservices. This makes it easier for new developers joining a team or picking up a project by eliminating the need to install dependencies locally. No more; different versions of NodeJS, Serverless Framework, different test runners etc. making on-boarding really simple. Everything is included and running in isolation in our Docker container.

After spending a few months in our Apps team and seeing how much Flutter and Dart have been integrated into VS Code to make the developers life easier I thought; “how can I take this experience over to my Serverless projects?”. When switching back to building a microservice I missed being able to run tests directly from the code, auto linting on save, all the advantages VS Code extensions can provide when you have the runtime and dependencies running locally.

Enter the Remote Containers extension. It allows a developer to use a container with the IDE running within it. Open any project into a container and take advantage of VS Code's full feature set and extensions.

Getting Started

Be sure you have installed and configured Docker for your operating system.

Install the Remote Development extension pack in VS Code.

Add a .devcontainer/devcontainer.json to your projects repo. This is a config that is committed to the repo and can be updated anytime. It determines how your container gets built and started. But, the exciting part is, it defines the extensions to install by default. Now everyone on the team will have the tools they need built into their IDE as soon as they start working.

A full guide can be found here, but to give you an idea, it looks something like this;

Now when opening your workspace in VS Code you will be prompted to open in a remote container.

Reopen in container from VS Code

This is just a quick primer, take a look at the official docs for a full run though.

Take better advantage of extensions

 So now we can take better advantage of the extensions that auto installed, and don’t worry, they only installed in the container – not your local VS Code. This is great because you don't keep collecting extensions for every different code base.

Extensions in VS Code

Previously to run a set of tests, you would be required to spin up a container and run through every test. With the Jest Runner extension, we can click the Run directly in the code, to run just the required test/s. Obviously, we still have access to all of the make and npm commands while inside the container as well, so the usual test runners still work as expected.

ESLint will lint on save. TypeScript Importer will auto import as we add references to functions or methods in our code.

All of these require NodeJS running, so, sure they can still be used on your machine directly, but you do have to set up an environment which can take time and differs between projects. You can then end up with clashing versions and extensions, and lots of wasted time.

The Pain

We use the Serverless and AWS CLI to run serverless-offline or test deployments to a nonprod environment, currently we duplicate the credentials and keys in the container, but they don't persist and aren't reusable between projects. I am sure we will find a neat solution for this in the future, but it is a bit of a pain point currently.

Another thing that we need to solve is; the speed. Currently its taking a few seconds to kick off tests, this can really slow down your day when running tests often. In comparison to spinning up a container and running all tests, however, it is still faster to be able to run the targeted tests with a running container.

In summary

Amaysim has had a simple, repeatable way to onboard team members to project with the 3 Musketeers pattern for quite some time. Now we also get to enjoy building stuff with an IDE that can actually utilise the tools and extensions as intended, making dev life so much nicer.

The views expressed on this blog post are mine alone and do not necessarily reflect the views of my employer, Optus Administration Pty Ltd

Previous
Previous

Prop-drilling helps our Test Driven Development

Next
Next

Naming Things