Best Practices for Docker in Development: Tips and Tricks

You can definitely iterate in whichever way fits your workflow best. What counts is that the Docker containers you deliver from your local environment work seamlessly anywhere else, whether it's on your coworker's Mac or a Linux production server. This consistency helps prevent those frustrating 'it works on my machine' scenarios.

Make sure to check your Dockerfile! There are ways to optimize it so that when you change code, it doesn't keep re-pulling libraries. It’s possible to utilize caching to speed up your builds, which should help alleviate some of the friction you’re experiencing. If debug testing is needed without constant rebuilding, you can shell into a dev container, but just remember it might not fully reflect what you're going to deploy later.

I actually use DDEV for my local development. It's a tool that wraps Docker for easier management of development containers, and you can commit its configuration along with your project. Just keep in mind that the dev container isn't the same as what you deploy, so you need to manage that separately.

One option is to mount your source code directly and rebuild and run it in the container. Have you looked into dev containers? They can simplify the process a lot.

If you're really stuck, I suggest deriving your dev container from the multi-stage build container in your CI/CD pipeline. This way, if something compiles locally, it should also compile when pushed. Use a Docker Compose file to link your source into the container to streamline the build-test cycle.