I'm having a hard time understanding what this does and what it buys me. If I am understanding correctly, they have added a new subcommand, but you pretty much have to make it do anything useful yourself (if you fall outside of their limited set of plugins). Is this a correct assessment?
This is correct. The benefit is technology abstraction for the developer. To use our own tools as an example: our open source docs is deployed to Heroku, our binaries go to Bintray, our services go to Atlas.
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.
> 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.
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. :)
Sure :), but that's yet-another-thing you need to manage. You could put all that logic in a Vagrantfile. It's about reducing the number of touch points.
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.
"OOH man, we have all these tools that no one understands anymore! I know, let's make a tool to abstract this away!"
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.
