Spread the love

 54,961 views

Starting Docker Desktop 3.5.0, Docker introduced the Dev Environments feature for the first time. The Dev Environments feature is the foundation of Docker’s new collaborative team development experience. It provides a simple way for developers to share their work in progress code, connect code into a container to edit it/rebuild it and a way to do this within a compose project using one container as your development environment while still running the others. It keeps your development container backed up, up to date, and provides simple tools to share these with your team so anyone can look at what you’re working on in one click.

It is currently offered as a Preview and shouldn’t be used in production environments. VS Code is the only supported IDE as of now, but you can expect a bunch of other IDE vendors in the near future.

To access Dev Environments, from the Docker menu, select Dashboard > Dev Environments.

Why does your team require Dev Environments?

Imagine your team is working on a Git project that has a development, experiment, and production branch. Your team uses a development branch to build the next version, an experimental branch to try exploring the new ideas, and the production branch that requires maintenance. Switching between these branches on a single machine could be complex and tedious at the same time, particularly if the dependencies are different. The isolation of using a different container for each branch may help.

With Dev Environments, developers can now easily set up repeatable and reproducible development environments by keeping the environment details versioned in their SCM along with their code. Once a developer is working in a Development Environment, they can share their work-in-progress code and dependencies in one click via the Docker Hub. They can then switch between their developer environments or their teammates’ environments, moving between branches to look at work-in-progress changes without moving off their current Git branch. This makes reviewing PRs as simple as opening a new environment.

Dev Environments use tools built into code editors that allow Docker to access code mounted into a container rather than on the developer’s localhost. This isolates the tools, files, and running services on the developer’s machine allowing multiple versions of them to exist side by side, also improving file system performance!  And we have built this experience on top of Compose rather than adding another manifest for developers to worry about or look after. 

How is Dev Environments different from GitPod and GitHub Codespaces?

Good question! If you have ever used GitPod or GitHub Codespaces, you might wonder how is Dev Environments different from these existing ones. If you look closely at GitPod, it is an open-source Kubernetes application for automated and ready-to-code development environments that blends in your existing workflow. It does work very similarly, enables you to describe your dev environment as code and start instant and fresh development environments for each new task directly from your browser. Tightly integrated with GitLab, GitHub, and Bitbucket, Gitpod automatically and continuously prebuilds dev environments for all your branches. As a result, team members can instantly start coding with fresh, ephemeral, and fully-compiled dev environments – no matter if you are building a new feature, want to fix a bug, or do a code review. On the other hand, GitHub Codespaces is a configurable online development environment, hosted by GitHub and powered by Visual Studio Code.

The major difference between Dev Environments Vs GitPod/Codespaces is in the way it runs. GitPod and Codespaces run in the cloud, and collaboration is based on working on the same code repository, whereas Docker Development Environments run locally, and enable sharing of work in progress as a complete working piece.

Getting Started

Step 1. Download and install Docker Desktop 3.5.0 or higher:

Step 2. Install the tools and extensions

Step 3. Start a single container Dev Environment

Go to Dev Environments > Click on Single container dev environment. We will be using an example to try a single container sample of Docker Dev Environments.

In the above example, the names lucid_napier and vigilant_lalande are randomly generated. You’ll most likely see different names when you create your Dev Environment.

Hover over the container and click Open in VS Code to start working in VS Code as usual. You can also open a terminal in VS Code, and use Git to push or pull code to your repository, or switch between branches and work as you would normally.

You can launch the application by running the command “make run” in your VS Code terminal.

Step 4. Access the HTTP application

This opens an HTTP server on port 8080. Open http://localhost:8080 in your browser to see the running application.

❯ curl http://localhost:8080

          ##         .
    ## ## ##        ==
 ## ## ## ## ##    ===
/"""""""""""""""""\___/ ===
{                       /  ===-
\______ O           __/
 \    \         __/
  \____\_______/


Hello from Docker!

Step 5. Sharing Your Dev Environments

If you’re not a member of the Docker Team Plan, then this is the time to upgrade from the free plan to the Team Plan.

If you are a member of the Docker Team plan, you can now share your Dev Environment with your team. When you are ready to share your environment, just click the Share button and specify the Docker Hub namespace where you’d like to push your Dev Environment to.

This creates a Docker image of your dev environment, uploads it to the Docker Hub namespace you have specified in the previous step, and provides a tiny URL that you can use to share your work with your team members. Your team members just need to add this URL in the Create field and then click Create. Your Dev Environment now starts in the exact same state as you shared it! Using this shared Dev Environment, your team members can access the code, any dependencies, and the current Git branch you are working on. They can also review your changes and provide feedback even before you create a pull request!

In the next post, we will use Dev Environments to collaborate on any Docker Compose-based projects. Stay tuned!

References:

Clap


Spread the love

Ajeet Raina

My name is Ajeet Singh Raina and I am an author of this blogging site. I am a Docker Captain, ARM Innovator & Docker Bangalore Community Leader. I bagged 2 special awards last year(2019): Firstly, “The Tip of Captain’s Hat Award” at Dockercon 2019, San Francisco, and secondly, “2019 Docker Community Award“. I run Collabnix Community Slack with over 5300+ audience . I have built popular GITHUB repositories like DockerLabs, KubeLabs, Kubetools, RedisPlanet Terraform etc. with the support of Collabnix Community. Currently working as Developer Relations Manager at Redis Labs where I help customers and community members adopt Redis. With over 12,000+ followers over LinkedIn & close to 5100+ twitter followers, I like sharing Docker and Kubernetes related content . You can follow me on Twitter(@ajeetsraina) & GitHub(@ajeetraina)

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Join Collabnix SlackIt's 100% FREE!

Get chance to chat with 5500+ DevOps Engineers !