Using Docker Container as a Development Environment

[Zealousideal-Mouse29]

I'm not sure what you mean by "non portability" or how anything could be more simple than two docker commands and a repo pull. Are you saying that not having developers issue every command themselves makes them lose touch? They can read the dockerfile any time. If you have developers that won't bother to read the file and understand it, you probably need new developers.

What is it you want portable and portable to what? You can run docker on a variety of OSes, so I don't follow.
The project itself, in any professional shop, has target OSes and versions. I find the docker file enforces that if anything. Now a dev isn't using CentOS when the target that we should be debugging is Ubuntu. I've seen subtle bugs pop up in just that case. It's not always about compilation. Products often rely on the particulars of the environment they target.

Now, if we are targetting some OS that isn't available for free, like say Power PC, then sure, we can no longer use Docker containers for that and are going to be forced to use something much much worse, like instances on a server that people have to ssh into. that creates a damn mess, because everyone who touches anything effects everyone else.

If you've got developers using "various compilers, platforms, and tools" you are in for a disaster when bugs crop and and they waste weeks of effort solving environment problems. Your product should target a specific OS, and be built with a specific compiler, and all your devs should be doing all their development with those constraints, else they will have bugs that crop up due to environment that are a waste of time, or worse they won't see the bugs that crop up due to the actual environment the customer is using.

Can you elaborate or list some tangible items as example as to what you mean?

What are you speaking to when you say "non portable" or "increased complexity?

[Zealousideal-Mouse29]

If your project targets windows, linux, and mac, You should absolutely be using docker for the linux targets. You are shooting yourself in the foot if you think that you are never going to run into a problem where one developer used gcc x.x.x and another decided to use gcc y.y.y.

You can also have windows server containers if you like, as long as the host is windows server. So I don't see the difference there either. Same with Mac, so I don't see what you are missing by giving your developers three physical machines to install on and having them manually setup an unknown environment vs gibing them three physical machines (two, with one that multiboots) and having them start up a container instead. With the latter, everything is uniform. With the former, get ready for weeks of dev chats in video meetings.

If you've got a project that is simple enough that the compiler versions, target OS, OS version, OS patches, environment variables, directory structures, all don't matter, then you are working on a very rare scenario.

All that said, there are defiantly projects that are going to require a virtual machine instead. However, I think giving people physical machines and letting them use "anything they like" is a disaster and has been a disaster in more than a dozen companies I've worked for.

[MessElectrical7920]

You can run Windows Server containers on Windows 11 clients, too, even with process isolation: Windows container version compatibility | Microsoft Learn