How to mitigate the extra delay in developing Django code when using Docker?

[MikeTheCanuck]

I’ve been thinking about a related issue and I’m not sure how it’s going to play out in practice, but since we’re on the subject I wonder what your take on the issue is. Let me explain:

We’re building containerized backend stacks for a couple of purposes: to run the containers in the cloud, and to deliver containers and/or images to developers to run on their local machines. Thinking further about the backend developer, I wonder just how useful the Django container really is?

If I’m developing Django code, I’m using a toolchain that runs a live build of my code in the background, and as soon as I save a change to one of the files, the toolchain rebuilds the code and re-launches the background environment for me to immediately see whether it works. [I don’t know if that’s actually true, but it’s the kind of developer workflow I’ve observed of late in the frontend world, and I’d be surprised if it was radically different in backend.]

Now apply this to the container environment:

• I (fork and) clone my project’s repo and run the container build.
• I want to make a change to my code - once I save the change to the local filesystem, I have to re-run the container build before I can submit a query to the API endpoint again.
• Depending on the time-to-build, this could take anywhere from 15 seconds longer to 20 minutes longer (if the emergency response container is any indication).

While we in the devops squad think “containers are the developers’ best friend”, I can imagine developers complaining that this noticeably slows down their feedback loop.

What am I missing? Is there some mitigating factor I’ve overlooked that makes this a non-issue?

[znmeb]

My container process involves frequent local builds (docker build or docker-compose build) for the services and when everything's working, I push to a repo where an automated build of the service images happens using the working code. That's what I thought was the strategy here.