[TomFrost]

Member of the DevLab team here :)

Compose is actually part of the reason we wrote this tool. We tried so hard to make it make sense for a TDD workflow, but it was always cumbersome.

Compose wants you to build your application into a container, and build and run that container every time you have a task to run. This takes time and a fair amount of cleanup, especially when you want a clean environment to run your tests that doesn't persist to the next run. DevLab just wants you to specify the environment to plug your application into, and doesn't build a container at all.

The result is:

- No manual cleanup

- No pile of images or processes that stack up

- Your project doesn't have to be a Docker project. It doesn't need a Dockerfile. You can use this for something you plan to clone on an EC2 node and run from an upstart script.

- No Vagrant/Ansible/Chef/Puppet, server config, anything. You pick out an image that matches your environment's needs (node:4.2, wordpress, go, etc., hub.docker.com is a great place to start) and DevLab plugs your app into it.

- More development-oriented features outside of the pure Docker ecosystem that Compose stays confined to. For example, soon, Mac users running docker-machine will get to enjoy ports bound to localhost much like Linux docker users do [1].

To get this functionality outside of Compose, we had a monolithic makefile to maintain all of this for us. It wasn't DRY and it wasn't smooth. I hope you enjoy DevLab!

[1] https://github.com/TechnologyAdvice/DevLab/pull/10

[kanzure]

> build and run that container every time you have a task to run

You don't have to rebuild each time, just use docker-compose rm -f and then run again. The old containers will be nuked, built docker images will be kept.

[TomFrost]

Fair point; I was speaking more toward the case of needing a rebuild any time your container gets changed, due to the change-on-run ethos of DevLab versus the change-on-build ethos of Compose.

But where cleanup really comes into play is when you have multiple tasks. You can specify multiple command paths in Compose, but each one will be a newly built image. With DevLab, you could `lab install` a node project, followed by a `lab lint`, or a `lab test`. You could `lab build` to compile your app at any time. And when you do this, whether it's the first time or the twenty-first time, overhead versus what you'd experience locally is just a second -- and the only image you have is your environment container. No build process, ever.

[kanzure]

Sounds like you could get the same benefits by installing sshd into each container and using ssh to execute inside of a single container, rather than using docker/compose "commands". This would allow you to keep your `pip install` updates, and only when you run `docker-compose rm` would the changes be nuked. Would that fit the workflow you've been talking about? Thanks!

[ksafranski]

DevLab also gives you the ability to switch containers at runtime (something that would require reconfig of compose). For example, if you're testing on node:0.12 and want to see if it works in node:4 you can simply run:

'lab test -f node:4'

There's no additional overhead or cleanup, or modification of files.

[ksafranski]

Additionally, Compose required our team to be more knowledgeable about Docker which (while not a bad thing) meant it wasn't as easy for more junior dev's, or those with no Docker experience, to quickly get rolling.

DevLab allowed us to get everyone on the team using containerization and now (after a few weeks rolling on DevLab) dev's are feeling comfortable with the core concepts and know how to work with Docker when they need to get more "bare metal" with it.