Just for code vs or an evolving standard? •


Last month, Microsoft said “dev containers have become widely useful for scenarios beyond VS Code” and introduced an open source dev container specification that formalizes a configuration file called devcontainers.json and features it supports.

Remote development is a hot area of ​​development tools. Microsoft’s GitHub has codes. Jetbrains has an IDE backend that runs remotely, allowing developers to code locally while compiling and debugging on the remote machine. Gitpod, a pioneer of this approach, integrates with GitHub, Gitlab, and Jetbrains Gateway, and creates development environments in remote containers.

The appeal of remote development is not just the ability to work from any machine, but also to have predictable, repeatable, and disposable development environments, rather than the traditional development PC with all sorts of tools and dependencies installed.

Diagram from Microsoft explaining the roles of development containers

A key part of this process is defining the target environment, which in most cases is based on one or possibly multiple containers. The starting point is the container image, but it’s also necessary to configure the container with mount points, environment variables, startup tasks, port forwarding, and other customizations.

Visual Studio Code used DevCconners.json, developed for the extension of remote containers published for the first time in 2019 and now also used in Codespaces.

At the same time that Microsoft introduced the Open Source Development Containers specification, it also released a CLI (Command Line Interface) as a reference implementation. With the CLI installed and a DevContainers.json configured, a developer can start a development environment on the local PC just as easily as the codes, hooked to the same GitHub repository.

But is the Microsoft-sponsored development containers specification just for Microsoft or something that will be widely adopted? Gitpod has its own YAML-based equivalent, .gipod.yml, but users found the differences a source of friction, which led Gitpod co-founder Sven Efftinge to work on devcontainer support. json, even before Microsoft’s recent announcement.

“Given the dominance of VS Code and GitHub in the developer world, VS Code’s devcontainer.json format will eventually become a quasi-standard. Supporting it will allow us to lower the barrier of entry for teams already using it so they can easily spin up their development environments in Gitpod,” Efftinge said last year.

Users like the idea, with one even finding the lack of interoperability a blocker, saying “after running into this problem I ended up losing interest in Gitpod and not going any further I never ended up getting .gitpod.yml to work.”

Another remarked that it would be “nice if there was an open governance group that maintains standards like these for development tools.”

Docker was cooler on the idea, with a spokesperson telling us it was “all Microsoft” and pointing us to its Compose spec, while also pointing out that it’s collaborating. Docker has its own support for development environments in Docker Desktop, but this is currently only for local use. Dev environments use VS Code though, and devcontainer.json is not an alternative to Compose but can work with it.

Microsoft told DevClass that its goal is to “enable anyone in any tool to set up a consistent environment with development containers, including tools beyond VS Code or Microsoft”, and stressing that “we Let us not consider this specification as a vs code concept only. ”

The company also mentioned the importance of specifications for continuous integration and testing as well as development, and that “having an agreed structure of this development-specific data is good for everyone.”

That said, the spec contributors seem to be All-Microsoft and the only “support tools” currently listed are vs code and the new CLI so it can’t yet be described as a ban industry project. Another point of interest is that the specification includes a proposal to add “features”, which define the capabilities to be added to a container, and inevitably there will be some debate over what belongs in the container image of base and what would be better to add later. .

The notion of a common specification is appealing though, giving developers the freedom to use different tools as well as develop locally or remotely.


About Author

Comments are closed.