znmeb
commented
7 years ago 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.
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:
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?