Dev containers to the rescue

Ahoy devs!

What if you could write a few lines of code while waiting at the dentist?

What if setting up the project for the first time was a non-event instead of a minor trauma?

What if the frustration of a project failing to build on a single developer's machine was eliminated?

Dev containers to the rescue!

What if you could bundle your dev environment with your code?

Using human-readable configuration files that are versioned alongside the project's source code, we determine which OS version, system packages and libraries, utilities, filesystem mappings, open ports, and supporting services will be included in a dev container.

So that a portable, reproducible development environment follows you from machine to machine and into the cloud.

Why are containers better for development than virtualization solutions?

It's because containers aren't really virtualization. Containers are like a computer inside a computer. A container works by generating an isolated set of namespaces rather than attempting to emulate a machine. Included are the filesystem, the network, the process table, and everything else that makes up a functional OS.

You can make it simpler for others to contribute to your open-source projects. You can verify that every CI test can also be done locally. You may share your development configurations and scripts with your fellow devs with a GitHub push. You could even spin it on a designer's workstation so they can test visual changes locally across in-house codebases without knowing the backend tech stacks.

Problems should be reproducible

Have you ever had a developer on your team start having problems that no one notices?

After much debugging, it was discovered that they had gotten a system upgrade incompatible with one of the libraries on which the project is based. Nobody could help them because... it worked on their machine!

Using dev containers regularly can significantly reduce the "works on my computer" syndrome.

Onboarding new devs

A puzzling, time-consuming, and frequently out-of-date onboarding process is the standard on most teams.

You're a champion if you can get a portion of the project's test suite running during your first week of onboarding!

With dev containers, you can get new hires up and running in an hour instead of days.

Shift between projects

Because a dev container is dedicated to a single project, the appropriate version of the environment can be installed with it. If this necessitates compiling the runtime from the source, this can be incorporated into the development container.

Distribute vital utilities

Once a project is configured on a machine, we forget the checklists and scripts. However, dev containers are recreated regularly whenever they are modified.

A dev container is an executable documentation of what libraries, services, system configurations, open ports, nice-to-have utilities, and so on are used in your project's day-to-day development.

The dev container.json file contains all necessary metadata and settings for configuring a development container for a specific tool and runtime stack. It can be used to establish a dev environment containing one or more containers with tools and services that satisfy the dev spec.

Everyone has access to all of the tests at all times.

We can raise our expectations to everyone can run all the tests, all the time, with a dev container that everyone shares and that is also utilized in CI. They may still run faster in parallel on CI, but passing the integration tests becomes everyone's responsibility.

Because dev containers can bundle up not just a little machine for developing the app itself but also the constellation of supporting services required to operate the app, they can handle the entire testing cycle.

IDE in the Cloud

Cloud-based programming with solutions such as Codeanywhere, Gitpod, or GitHub Codespaces is a thing now and will only get more popular.

The dev container in Codeanywhere cloud IDE can have a base level of project-specific settings and plugins, but you can also add your own settings, plugins, colour schemes, keybindings, and so on top of that.

Remote pair programming is possible in cloud-based development environments.

What if open-source projects included dev containers that made casual contributors effective immediately? Casual contributors may find it much more inviting!

Similarly, your team is not required to settle on a single editor. Dev container-aware configurations for various IDEs can be included in a project.

Certain technologies, once matured, irrevocably alter the developing state of the art.

This is the developer experience of the future. You can start enjoying the future today by utilizing containers for the development and flexibility of cloud IDEs.

Reposted to Blog