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.
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.
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.
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.
Now every developer at HashiCorp knows that you `git clone` any project in the company, and `vagrant push` to deploy. It doesn't matter how it works under the covers.
Example: We just changed Vagrant itself to `vagrant push` to deploy Vagrant: `vagrant push www`, `vagrant push docs`, `vagrant push release`. This all does different things.
We already have a standard for that. It's called "make" to build, and "make deploy" to deploy. Put a Makefile next to your Vagrantfile like you should have done in the first place. :)
I definitely see your side of the argument, and we certainly have Makefiles in our projects too. Vagrant Push provides a way for an organization or team to choose what is best for them and lower the barrier to entry for developers on a project.
git hooks are another option, as are shell aliases, SCM integration, CI/CD systems, etc. This seems like yet-another-layer-of-abstraction to cover for bad / misunderstood / underutilized abstractions under it.
The idea is that Vagrant is a single workflow for development environments. "vagrant up" to work on any application, "vagrant share" to collaborate on any application, "vagrant push" to deploy (or start to deploy) any application.
EDIT: @ossreality: Your comments are showing up as dead. But I want to respond to you. As I mentioned here, `vagrant push` is glue to real deployment tools. How are you deploying your complex application now? You would hook up `vagrant push` to that. "vagrant push" itself is not a deployment framework.
1) It was never that great an idea in the first place. It's OK-ish for command line, text based interfaces, but its tedious and limiting for more complicated stuff and it results in tools that lack a coherent story to work together, especially if each of the tools is made by a different entity, with different APIs, flags, etc.
2) It's still here for Vagrant. Vagrant doesn't try to do the deployment. Just provides a command that can call your preferred deployment tool that just does "deployment well".
So... if I have some docs in markdown, and a server-config to serve static assets -- it'll upload the config and the markdown, but not the generated html/css/js? The idea is that the server knows what to do with the git repo?
Or am I just being difficult now? (I honestly can't really tell -- I also have a hard time seeing how to make use of this. Not that it matters - if it works for you, then great ;)
We are currently using a solution called Jenkins which serves our purposes very well because of it's maturity and the flexibility that it provides. Other than the simplicity of the deployment command, after configuration, I fail to see the benefit of this tool, especially at such an early stage.
Under the covers, it is a completely different protocol.
Very cool, I'm excited to try this out.
There is a lot of churn in the provisioning and orchestration tools like chef and docker and others. The tension is between an inherent utility in these tools (it makes managing/deploying services easier!) and their desire to lock people into a platform. Vagrant captures a middle ground in the midst of that churn.
when you run 'vagrant up' for the first time, you end up with a provisioned host. Why not say that 'vagrant up' in a local vm is the same as 'vagrant push staging' to some random host. In either case we end up with something modeled by the vagrant file? I know other people would say no, but please consider going into competition in the dev-ops space as a wrapper to the churn, a nice abstraction on the ambitions of others. As an itinerant developer, I just want a Vagrantfile :)
Because ignoring the "leaky abstractions" meme Spolsky pushed, all and every progress in computing has been thanks to increasing abstractions.