[Lazare]

Standardised, platform independent, easy to install and configure tools. If you've got a somewhat complicated dev environment, it's really really easy to tell new developers "look, just install virtualbox, install Vagrant, clone the repo, run vagrant up, and then vagrant ssh". A few minutes later they'll be sitting at an ssh prompt at a fully installed and configured dev server, which is pretty sweet.

Sure, you could do it all with slightly longer and more detailed instructions and more hand rolled scripts, but it would be slower and more fragile. Vagrant doesn't really solve any new unsolved problems, it's just a bit easier than the alternatives.

(Also, I'm not sure I understand your argument against vagrant. Part of the point of vagrant is, yes, to try and maintain the same deployment tools for dev and producton. Why do you think using vagrant makes that harder?)

[antidoh]

Probably my lack of understanding of how vagrant fits and works. But you wouldn't use vagrant to manage a production server, so there's an inevitable difference there.

[Lazare]

Not at all!

See, you wouldn't use vagrant to manage a dev server either. Rather, the idea is that, in dev, you use vagrant to provision a VM (or multiple VMs; you can replicate your whole stack with multiple web servers, database clusters, load balancers, etc.) which is as close to your production environment as possible. Then you manage this dev environment the exact same way you manage your production environment - with chef or puppet.

Vagrant is taking the role of Amazon's EC2 control panel or the order form on your dedicated server providers website. And none of those manage the server; that's chef or puppets job. (Although it does have great integration with chef and puppet.)