For organizations with more than a handful of engineers, shouldn't deployment happen automatically through something like a CI server? Do we really want every engineer deploying code directly themselves? How do the currently available `vagrant push` deploy strategies handle concurrent deploys happening from different people?
I realize that a lot of this is left open to allow custom plugins/strategies to do more complex things (like automated deployment), but I question the practice of encouraging workflows where developers deploy themselves rather than just pushing code revisions.
Or by "deploy", are we referring to deployment to a local development environment? The distinction is an important one in my opinion.
Agreed. While cool at first glance, this feature is virtually useless to me, because if I want to do things properly, I need to make sound deployment system, and by no means pushing upstream stuff from your local machine is sound. And in fact it doesn't matter how many developers on your project can make releases, they never ever should do this that way.
It is an obvious must that you have to be able to answer the question "what runs in production right now", anytime. There's one way to do that: deployment starts from your git/svn/whatever-vcs repository, not from some untracked code on any developer machine.
That is very, very preferable even if there's only one almighty developer (you) on the project, and total must if you have a couple more developers with different access rights — like, it's quite possible you don't want every developer to know password to the DB (or some payment system, or something even more scary) on production, which you'll store in some configs outside of VCS. Or maybe there're simply some tweaks on production system which are not possible to reproduce on development/staging. So you'll have to run some more custom actions on every deployment and, again, in centralized fashion, not just from some developers vagrant instance.
Using vagrant this way is essentially the same as encouraging everyone to SSH to prod instances themselves.
In this case, "vagrant push" should interact directly to your CI. It is named "push" for this reason and not "deploy", although the blog post title uses the word "deploy" since it is the end goal (the push should lead to the deploy).
Example: "push" might not send any code, so much as signal to the CI that that commit is meant to be deployed (if it were to pass). Or, "push" might send code directly to a CI. It is really up to you.
"push" doesn't require it go direct to production, and doesn't encourage that (or actively discourage that). It is just meant as a workflow mechanism to unify how deployments are started.
Everything you mentioned seems to be accomplished with a simple "git push". When git (or similar VCS) is involved, the push of a new revision of the codebase should (in my opinion) be what triggers a CI build/deploy. As mentioned in krick's comment, the codebase (specifically the branch that is tracked for releases) is the authoritative place to know what code is running on production.
Otherwise, we have a disconnect between what's in the codebase and what's running on production, and we must ask the question "did the latest code get deployed yet?" or "who is responsible to 'vagrant push' this revision?" - all of which can be avoided by letting the VCS workflow determine all of that.
I love vagrant for what it does best: simplify development environments. I fear that the "push" functionality is treading into unrelated territory. The problem is not what technically happens with a "vagrant push", but rather the idea of "starting deployments" (as you said) from individual developers in their local development context. In my opinion, developers don't initiate deployments; deployments happen passively in response to code changes - assuming it passes any relevant tests/conditions.
I realize that a lot of this is left open to allow custom plugins/strategies to do more complex things (like automated deployment), but I question the practice of encouraging workflows where developers deploy themselves rather than just pushing code revisions.
Or by "deploy", are we referring to deployment to a local development environment? The distinction is an important one in my opinion.