That Makefile is... weird. Why issue a "make sub-target" command? Makefiles are all about understanding dependencies, so you should actually be doing

    target: dependency
        <commands>

...instead of

    target:
        make dependency
        <commands>

Doing it this way actually breaks dependency checks. It's just plain wrong.

Here's a "proper" Makefile, complete with conditionals, expansion, etc.:

https://github.com/rcarmo/sushy/blob/master/Makefile

...and here's one of my Go Makefiles (no sub-targets here, but does vendoring in a way that's quite similar to what Go 1.5 turned out to adopt)

https://github.com/rcarmo/go-rss2imap/blob/master/Makefile

(edit: whitespace)

One thing to point out specifically about "proper" Makefiles: the author should be marking his `.PHONY` targets (https://www.gnu.org/software/make/manual/html_node/Phony-Tar...) and giving sources. This gives you incremental builds for free.

One of my Makefiles: https://github.com/liveplant/liveplant-server/blob/master/Ma...

Definitely open to feedback on the above. Seems like my Makefile doing pretty much the same thing as yours @rcarmo.

good call on the .PHONY.

Thanks rcarmo for bringing this up. You're right, it is a better, and the only right, approach to declare the dependencies like you proposed. I've updated the code!

Worth checking out docker-compose for more complex setups (if you need a Redis and PostgreSQL database running for example). I have been using it for Node.js development for the past few months and it is really a life changer especially if you are working on multiple projects concurrently. Pro-tip: `echo "alias dc=docker-compose" >> ~/.zshrc`

Yeah. I've been using fig for a while now (and will eventually replace everything with compose), and it's simpler than Vagrant for reproducible environments.

There is one little caveat when using boot2docker, in that when you're running tests on a separate terminal you need to be careful to remember to do $(boot2docker shellinit) _and_ expose container ports so that they're visible outside the boot2docker VM - so check your IPs and make sure your containers log the environment variables they're using for links, so that you can check where to connect your tests :)

Yeah $(boot2docker shellinit) is a bit annoying but I use tmuxinator which does it for me with `pre: boot2docker up && $(boot2docker shellinit);`. You could also add it to your .bashrc/.zshrc.

For automated tests, I simply have a test service which I start with `docker-compose up test` and I can link services my tests need from inside `docker-compose.yml`.

For manual testing, I added `192.168.59.103 docker` to my `/etc/hosts` file (the boot2docker IP doesn't seem to change) and expose ports on the boot2docker VM though that means I can't test two containers which expose the same port simultaneously.

Yes, docker-compose (https://docs.docker.com/compose/) is just great. Another sweet tool, but I haven't used it in production yet, is empire (https://github.com/remind101/empire) for deployment (AWS centric).

Has one of you tried xhyve? https://coreos.com/blog/coreos-and-xhyve-tech-preview/

Haven't heard but thanks for pointing out. It might be pretty useful actually as I develop on OS X and use CoreOS in production.

And if it is faster than boot2docker with VirtualBox, great!

Why "FROM tianon/true" ? "FROM scratch" would be even smaller. That's what we use in the docker swarm image: https://github.com/docker/swarm-library-image/blob/master/Do...

An improvement I'd make to this is not sending the current directory to docker, but rather a directory containing just the binary. That way you don't send a massive context to docker which you just throw away. (Especially in go projects which vendor in a lot of dependencies)