Docker introduces developer environments in containers

Virtual DockerCon kicked off today, at which the company introduced Docker Development Environments, calling them "the foundation of Docker's new collaborative team development experience." In the past Docker containers have been mainly for deployment of applications, but the Docker Development Environment extends that to... ( …

[Anonymous Coward]

Personally, I've found the Remote Containers extension for VS Code to be really quite nice so far (for Python at least)

[Joe W]

It definitely could be useful in our shop. I need to push some people towards docker, but they are willing anyway.

In contrast to one colleague who did complain about me introducing version control systems... I hate working on that project (also because of the legacy "code" in it and the inability of those involved to see that it is complete crap), and when (not if) they drive it against a wall I'll be far away from it and drink to their demise.

[Warm Braw]

I hate working on that project

Sounds like you're more in need of an aversion control system.

[iron]

Any dev who complains about using version control should be encouraged to find a different carreer. Perhaps as Health Secretary, I hear total incompetance is an asset in that job.

[Anonymous Coward]

definitely! i work for an entire department that refuses to implement any form of documentation or version control. every project is a raging dumpster fire with multiple fragmented versions of code as well as in-house development tools and it's impossible to work collaboratively.

[Hogbert]

Sounds scary. We require useful descriptions on code check-in and having the full change history is so very useful.

Maybe you could start using local GIT instances to maintain projects, then slowly introduce others to the benefits it brings.

[iron]

I have to agree with the dev quoted in the story, I don't see the point and what problem are they trying to solve?

> An example might be a Git project where there is production branch which needs maintaining, a development branch for the next version, and an experimental branch for trying out some new ideas... Switching between these on one machine could be complex, particularly if the dependencies are different

Total BS. Switching branch is a simple git operation and your tooling should handle the dependencies.

I work on a lot of different project types... web, mobile, serverless, command line, etc. I set up my environment once and I'm done so I struggle to see the point of something like this.

[christianlc]

> Total BS. Switching branch is a simple git operation and your tooling should handle the dependencies. I work on a lot of different project types... web, mobile, serverless, command line, etc. I set up my environment once and I'm done so I struggle to see the point of something like this.

So if your stack consists of proxy, application, datastore, search, job server and an event streamer/bus, and your ops team updates configuration anywhere in that pipeline, your tooling will handle any/all cases?

I think the point of this tool is to streamline and encapsulate the orchestration of an entire stack against something like k8s, so the devs don't have to think about it; just a guess, so correct me if i am wrong and sorry or the rhetorical bitchiness above.

[KSM-AZ]

I just don't get docker...

I can build a tiny vhost, or... I can build this chrootie kind of thing that adds a mangement layer, and requires skills to implement. Enjoy, I'd rather just have a normal machine running my app.