[Rezo]

I'd be interested to know if and how people are integrating Docker into their edit-compile-test development cycle?

For me personally, the time it takes from performing an edit to seeing your change "live" on a developer's machine is extremely important. To this end we've spent some effort in making our own services and dependencies run natively on both OS X and Linux to minimize the turnaround time (currently at around 4 seconds).

Docker fixes the "works on my machine" problem, which is worth tackling but not something you run into too often, but (in my admittedly limited experience) introduces pain into the developer's workflow. Right now, I'm leaning towards enforcing identical environments in CI testing and production via Docker images, but not necessarily extending that to the developer's machines. Developers can still download images of dependencies, just not for the thing they're actually developing. I'd love to hear alternative takes.

[viktorbenei]

We do a really simple trick. We have one Dockerfile, which we use for dev and for production, every configuration difference is handled through environment variables (which is easy to manage with docker-compose, Ansible, etc.), so you can run the same image everywhere and change the environment configuration to switch between dev/test/prod.

So to solve the live reload problem we do only one thing in development which we don't do anywhere else: the Dockerfile copies all the current source files into the image, but we run the container with a mounted volume of the source code - which in dev mappes exactly the same way the Dockerfile defines the src copy.

This way when you create the image and start the dev container it won't change anything, but as the src is mounted on top of the included src in the image the regular (Rails) auto reload works perfectly.

For test and prod we just simply don't do any volume mounting at all, and use the baked in src directly.

Easy and fast everywhere, all you have to control is how and when the images are created (ex: we do a full clean checkout in a new directory before building a test image, to ensure it only contains committed code. EDIT: by test I mean for local testing, while you're working on revisions, a CI server does the automatic testing).

[nickstinemates]

I spent a lot of time thinking about this and working on it. My github account hasn't been active very much over the past year, but the docker fundamentals are there.

I would love to find the time to modernize in the context of machine/swarm/compose.

One of the thoughts[1] was using docker volumes as sophisticated pipes to other docker processes, allowing for a different kind of blog/publish/editor workflow while being agnostic in tools (blog engine, editor [web or some other mechanism]) for how the content is actually created.

Needless to say, there are many aspects of Docker I find really powerful, and I particularly delight in taking an existing workflow and modernizing it in that context.

Long winded context, but, suffice to say, a 4sec turnaround time would be way too long for me personally. I know first hand as well as through all of the talks on Docker out there it is possible to get near realtime updates of your app in local dev.

1: https://github.com/keeb/blog