Vagrant Push – One Command to Deploy Any Application • Hacker News Board

Re: Vagrant Push – One Command to Deploy Any Application

#31

Post by mitchellh » Sat, Dec 13, 2014, 5:47 AM UTC

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…

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.

Re: Vagrant Push – One Command to Deploy Any Application

#32

Post by seanp2k2 » Sat, Dec 13, 2014, 7:52 AM UTC

sethvargo wrote: post #19

sneak wrote: post #11

Earlier quoted context omitted.

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

Re: Vagrant Push – One Command to Deploy Any Application

#33

Post by cultavix » Sat, Dec 13, 2014, 9:29 AM UTC

I love the VI setup.

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.

Re: Vagrant Push – One Command to Deploy Any Application

#34

Post by dperfect » Sat, Dec 13, 2014, 7:17 PM UTC

mitchellh wrote: post #31

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…

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

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.