> And also makes it easy to test with different database versions, gives you 5 minute onboarding for the new devs on team (run this docker compose and you have

> And also makes it easy to test with different database versions, gives you 5 minute onboarding for the new devs on team (run this docker compose and you have everything in place). It's eerie that I had this experience 5 minutes ago, in a stand-up onboarding meeting for a new colleague: they ran into issues when trying to launch the project through the IDE run configuration (IDE version, plugins, project configuration etc.) but the container based approach that I introduced just in case about a year ago just worked, the first time. Provided, I actually went the extra mile and documented how to authenticate with the necessary private repos etc., so one could follow a short list of steps bit by bit. > Lets you test your software in exactly the same environment as in production. I'd say containers are good for this, but not perfect. Depending on what you're developing and how, you might still run into stupid issues: mostly in setups where you use Windows for your development box and bind mount files, the permissions will get screwed up, as will line endings. Here's an example: https://blog.kronis.dev/everything%20is%20broken/containers-are-broken https://blog.kronis.dev/everything%20is%20broken/containers-... I'd say the best possible developer experience nowadays is along the lines of: - have GNU/Linux distro X as your developer workstation - have the same GNU/Linux distro X as the base for your containers (a more cut down version, but with same package repos) - still ship software in containers, ideally run those on nodes that have some GNU/Linux distro That's why I primarily base all of my container images on Ubuntu nowadays, same OS as my workstation. It's not efficient or optimized, but it's good enough, predictable and mostly free of headaches: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-for-all-of-my-containers https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo... I can just install some software on the workstation and have it run basically the same as it will in the container, same install instructions and everything (though maybe less focus on clearing up package caches not to bloat container layers, which doesn't matter outside of those). Sometimes that is useful for local debugging or launching things directly with IDE integrations, as opposed to trying to get remote debugging working (though things like DBs, Keycloak, Redis etc. are still better in containers, I'm talking more about back end/front end tooling/runtimes). If you go to this other post of mine, it actually has an example of this: https://blog.kronis.dev/articles/a-week-of-linux-instead-of-windows https://blog.kronis.dev/articles/a-week-of-linux-instead-of-... (search for "Being able to run the same thing inside of containers and on the host system.") At this point I'm basically unironically shipping my dev box, sans dotfiles. It doesn't scale, but it's the least painful dev and ops experience I've had in years. One can probably take elements from this for more sane and enterprise setups, too (such as focusing on GNU/Linux instead of Windows for development, or at least something with a similar file system).