Streamline Your Open Source Workflow with DevContainers

If you’re reading this, chances are high that you are a fan of Open Source. That’s not surprising, seeing that Open Source is the lifeblood of our industry. Linux is Open Source for example and most containers running production workloads right now are based on some Linux distribution.

Open Source can also be a great way to kickstart your career, helping to make connections across countries and organizations. And finally, it just feels good to give back to the community.

But unfortunately, Open Source projects are often struggling. Lack of long term commitment being one of the more pressing issues. Since there’s no direct financial incentive, it can be hard for projects to keep people engaged longterm and avoid brain drain, or to get enough people interested in contributing to keep up with turnover.

As Developer Advocate, I am dealing with exactly these issues. The question I most often ask myself is: how can we get more people to learn about and experiment with our projects. And how do I keep the barrier to entry low, so new users and contributors will have a smooth onboarding experience?

You’ve probably heard the developer’s adage “It works on my machine”. Up until recently, that hasn’t been very helpful. But nowadays, you can actually package up your machine and ship it to your colleague!

With remote development environments, you’ll have loads of advantages, such as:

• Isolation

  Your dev environment is not directly dependent on your workstations OS or toolchain

• Portability

  You can take your dev environment from one machine and run it on another.

• Fixed dependencies

  All your developer tools and dependencies can be fixed, so you always know exactly which version of which tools are running

• Explicit setup config

  Every tool installation and configuration is explicit, so it is clear to everyone, what is happening

The basic idea is that you declare your entire development environment in a manifest, such as a yaml or json. This file will hold your entire tool chain, configuration settings and setup scripts. A dedicated service will then spin up a machine, install your dependencies and configure your workspace as defined. All with one single command.

Intrigued? Let’s look at the most popular options in the remote development environment space currently

• GitHub codespaces

  Backed by Microsoft and directly integrated with GitHub, this is probably the most popular tool currently available. It is based on the open devcontainer.json standard developed by Microsoft. 

  However, codespaces itself is proprietary, so there is only little room for customization regarding how or where your devcontainers are running.

• GitPod

  GitPod is an open source tool which allows the creation of on-demand cloud dev environments. To use GitPod, your project will require a gitpod.yml and you need to create an account. All development environments are hosted by GitPod itself, as they have deprecated their self-hosted feature last year.

• DevPod

  DevPod provides an open source alternative to GitHub codespaces. It is also based on the devcontainer.json, so you can easily move your projects from codespaces to DevPod without the need for modification. DevPod is fully open source and with the provider concept you can deploy your development container anywhere you want. All you need is the DevPod cli (there is also a GUI version) to get started.

#How to get started with DevPod

Create a folder .devcontainer at the root of your project

Create a basic devcontainer.json with a standard dev image. For example any from this page https://containers.dev/templates

{
  "image": "mcr.microsoft.com/devcontainers/typescript-node",
}

Or, if you already have an existing project, omit the image property.

Create a Dockerfile in the .devcontainer folder. All the tooling needed to develop, debug and run the application, should go into this Dockerfile

Add a build property to the devcontainer.json and pass in the location of the Dockerfile we just created

{
 "build": {
    "dockerfile": "Dockerfile"
  },
}

Any further setup, configuration etc, can be executed via a postCreateCommand, postStartCommand or postAttachCommand. For example, this is how the vCluster maintainer startup a local kubernetes cluster inside their devcontainer

{
  "name": "Go",
  "build": {
    "dockerfile": "Dockerfile"
  },
  "postCreateCommand": "kind create cluster || true",
}

Now every user is starting out with the same exact environment that is specifically optimized for developing this exact project.

If a user or contributor decides they need to install a new tool to the toolchain, they can open a PR with the suggested change, so the maintainers again have full transparency & power over how to best setup & run the project in development mode.

Taking it one step further

To make the onboarding experience even simpler, you can add a button to your repo’s readme which will automatically open DevPod and start the devcontainer belonging to your project. You can see an example here.

#How To add the button

To add the button you will need to update your README.md with the following:

[![Open in DevPod!](https://devpod.sh/assets/open-in-devpod.svg)](https://devpod.sh/open)

#Conclusion

We are looking forward to helping make the developer experience even easier and reduce the time to first contribution for new contributors. If you have any feedback or questions then join our Slack (slack.loft.sh) and we will be happy to help out.