It's also very good for CI, to put all the dependencies and the entire build process in code that way. In the pre-docker days, you had a lot of configuration management inside the CI agents. Nowadays, often all that they need to do is be able to run Docker (+ manage secrets and a few other things) and you're good to go.
I have never liked Docker for local development, apart from running external dependencies (e.g. have postgresql and redis launch through docker-compose in a standardized way). Local development of company code should not use Docker, too much hell with caching and (as OP notes) discrepancies between developer environments.
(On that note, I have found that developers typically use Docker very different from people that work on CI / deployments -- more often than not, I've seen devs just have continuously running docker containers, executing all kinds of commands on them, save/loading them, etc, without using any Dockerfile at all. That just makes me irk, I don't understand that type of flow)
Local development is way easier with Docker for certain things. It’s great to have known and consistent package versions, a build process that’s documented by the nature of dockerfiles, and having a fairly standardized deployment method.
There’s been plenty of times in my work history where I had to take what was a legacy application nobody knew anything about and went through the process of deploying it using a container. The biggest problem was figuring out how to get the thing to actually run; “I don’t even know anything about Scala. What the heck even is sbt, no clue.” But just starting out with a blank image where I can install random things that don’t affect my machine is great, and once I finish the process now everybody knows how it’s deployed; it’s in the Dockerfile. If I want to explain it in a readme, I copy and paste what I have in the dockerfile and expand on it, going step by step. When that image is deployed in an EC2 instance running our standardized AMIs, I know it’ll work; I’ve tested it. Converting that deployment image to run unit tests just means changing a few commands in the dockerfile, and now Spinnaker can run tests before the image is deployed anywhere. Easy pickle.
At my current job, we do not currently have a process like that. We have Jenkins workers where we occasionally have to install different packages that the devs need in order for their build process to work as expected, and we have to have Jenkins workers specifically for that team. If they ran their builds in a container instead, we wouldn’t have that issue. At my previous role, our Jenkins nodes were regular EC2 instances running our standard AMIs and the dev teams built their code inside a container. When I had to build Python packages, it didn’t matter what Python packages were on the system, or that the EC2 instance didn’t have Python-dev and GCC installed. Build happens in a container. I know the build will succeed because I tested it locally on my machine.
I have never liked Docker for local development, apart from running external dependencies (e.g. have postgresql and redis launch through docker-compose in a standardized way). Local development of company code should not use Docker, too much hell with caching and (as OP notes) discrepancies between developer environments.
(On that note, I have found that developers typically use Docker very different from people that work on CI / deployments -- more often than not, I've seen devs just have continuously running docker containers, executing all kinds of commands on them, save/loading them, etc, without using any Dockerfile at all. That just makes me irk, I don't understand that type of flow)