Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vagrant Push – One Command to Deploy Any Application

vagrantup.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Vagrant Push – One Command to Deploy Any Application

#21

Post by amadeus »

sneak wrote: post #11
mitchellh wrote: post #5

Earlier quoted context omitted.

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 `v…

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

Oh shit, this guy is smart as fuck!

Re: Vagrant Push – One Command to Deploy Any Application

#23

Post by sethvargo »

denom wrote: post #7

I love the combo of vagrant and chef for provisioning. Is it possible to use the existing provisioning code in the context of a push block? Very cool, I'm excited to try this out.

Interesting question. Vagrant push exists outside of the context of a provisioner, so I don't see what you would be provisioning in the push section. Chef will provision the VM, but the push strategy is pushing the contents of the current working directory to some external destination (like FTP or Heroku). Does that help clarify?

Re: Vagrant Push – One Command to Deploy Any Application

#24

Post by [deleted] »

coldtea wrote: post #12
kasabali wrote: post #2

What happened to "one thing and well"? Vagrant is exceptional in what it does but I can't see why anybody should use it as their deployment tool among myriad of deployment tools.

> What happened to "one thing and well"? 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 tr…

[deleted]

Re: Vagrant Push – One Command to Deploy Any Application

#25

Post by dperfect »

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.

Re: Vagrant Push – One Command to Deploy Any Application

#26

Post by krick »

dperfect wrote: post #25

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 compl…

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.

Re: Vagrant Push – One Command to Deploy Any Application

#28

Post by gtaylor »

mitchellh wrote: post #5
gtaylor wrote: post #3

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 `v…

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.

Re: Vagrant Push – One Command to Deploy Any Application

#29

Post by e12e »

mitchellh wrote: post #18
MikeKusold wrote: post #15

I've watched the videos and read the docs, but I'm still a little confused about this feature. How does it know what files to push? Does it diff the base vagrant image? If my application has package dependencies, does it push those too? What about if I need to restart a service as part of the push?

Good question. It does a few heuristics depending on the strategy in use. But it has some VCS detection in it so if you're using Git it'll only upload files in the Git index (staged/committed/not ignored). There are also glob-based include/exclude filters you can specify. If all else fails, then yes, it uploads everything.

> it has some VCS detection in it so if you're using Git it'll only upload files in the Git index (staged/committed/not ignored)

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 ;)

Re: Vagrant Push – One Command to Deploy Any Application

#30

Post by denom »

sethvargo wrote: post #23
denom wrote: post #7

I love the combo of vagrant and chef for provisioning. Is it possible to use the existing provisioning code in the context of a push block? Very cool, I'm excited to try this out.

Interesting question. Vagrant push exists outside of the context of a provisioner, so I don't see what you would be provisioning in the push section. Chef will provision the VM, but the push strategy is pushing the contents of the current working directory to some external destination (like FTP or Heroku). Does that help clarify?

Makes sense. I am put-off by the complexity surrounding the initiation of host provisioning. Writing recipes is a breeze with berkshelf and vagrant. But diving into "real" provisioning tools is a pain for me.

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

Post reply on HN