4 ms·

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 bi

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.

sneak 12y ago
> 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. :)
- sethvargo 12y ago
  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.
  - seanp2k2 12y ago
    "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.
- amadeus 12y ago
  Oh shit, this guy is smart as fuck!
gtaylor 12y ago
I can respect that. It's a somewhat unexpected development, and I don't think our usage case lines up with this, but I can appreciate the intent.

sneak 12y ago

> 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. :)

sethvargo 12y ago
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.
- seanp2k2 12y ago
  "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.
amadeus 12y ago
Oh shit, this guy is smart as fuck!

gtaylor 12y ago

I can respect that. It's a somewhat unexpected development, and I don't think our usage case lines up with this, but I can appreciate the intent.