website/www: push post

website/www/source/blog/2014-12-12-vagrant-push-to-deploy.html.md

@@ -0,0 +1,122 @@
+---
+page_title: "Vagrant Push: One Command to Deploy Any Application"
+title: "Vagrant Push: One Command to Deploy Any Application"
+author: "Mitchell Hashimoto"
+author_url: https://github.com/mitchellh
+---
+
+Vagrant 1.7 comes with a new command: `vagrant push`. Just as "vagrant up"
+creates a development environment for any application, `vagrant push` is
+a single command to _deploy_ any application.
+
+The goal of Vagrant is to give developers a single workflow to develop
+applications effectively. "vagrant up" creates a development for any
+applications, "vagrant share" enables collaboration for any application.
+Deploying was the next logical step for Vagrant, now possible with
+"vagrant push".
+
+Like every other component of Vagrant, push can be configured using multiple
+strategies. "vagrant push" can deploy via FTP, Heroku,
+[Atlas](https://atlas.hashicorp.com), or by executing any local script.
+Other strategies can be added via plugins and more will be added to core
+as time goes on.
+
+Read on to learn more.
+
+READMORE
+
+### Demo
+
+We've prepared a short video showing Vagrant Push in action.
+
+<iframe src="//player.vimeo.com/video/114328000" width="680" height="382" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
+
+### Push to Deploy
+
+`vagrant push` works like anything else in Vagrant: configure it in the
+Vagrantfile, and it is immediately available to every developer. Push
+configuration is simple and easy to understand:
+
+```
+config.push.define "ftp" do |push|
+  push.host = "ftp.company.com"
+  push.username = "username"
+  push.password = "mypassword"
+end
+```
+
+And then to push the application to the FTP or SFTP server:
+
+```
+$ vagrant push
+...
+```
+
+Multiple `config.push.define` declarations can be in a Vagrantfile to
+define multiple pushes, perhaps one to staging and one to production, for
+example.
+
+### A Single Command
+
+The biggest benefit of Vagrant Push is defining a single command
+to deploy any application. Whether the deploy process is complex or
+is just a simple push to Heroku, developers only need to know that any
+application within their organizations can be deployed with `vagrant push`.
+
+For complicated deploys, the benefit is obvious. For simpler deploys, such
+as a push to Heroku, Vagrant Push is still useful. Besides not having
+to know that Heroku is being used under the hood, Vagrant Push will
+automatically configure your Git remote so the push works. Prior to this,
+you'd at least have to know the Heroku application name and configure
+your local repository to be able to push to it.
+
+Of course, not applications stay that simple, and if your application
+outgrows Heroku, then the deploy process doesn't change with Vagrant:
+`vagrant push`, to deploy any application.
+
+### Push Strategies
+
+Like providers, provisioners, and other features in Vagrant, pushes can
+be configured with multiple _strategies_. Vagrant 1.7 ships with four
+strategies:
+
+  * [Atlas](https://docs.vagrantup.com/v2/push/atlas.html) - Push application
+      to [Atlas](https://atlas.hashicorp.com), a commercial
+      product from HashiCorp.
+
+  * [FTP/SFTP](https://docs.vagrantup.com/v2/push/ftp.html) - Upload files
+      via FTP or SFTP to a remote server. This is great for static sites,
+      PHP, etc.
+
+  * [Heroku](https://docs.vagrantup.com/v2/push/heroku.html) - Push your
+      Git repository to Heroku, and configure the Git remote for you if
+      it doesn't already exist.
+
+  * [Local Exec](https://docs.vagrantup.com/v2/push/local-exec.html) -
+      Executes a local script on the system using a shell, deferring deployment
+      logic to the user. This is for custom behavior or more complicated
+      interactions with systems.
+
+In addition to these built-in strategies, new strategies can be
+[built just like any other Vagrant plugin](https://docs.vagrantup.com/v2/plugins/development-basics.html).
+This allows 3rd parties to extend the capabilities of `vagrant push`, and
+will surely result in future versions of Vagrant shipping with more push
+strategies.
+
+### Next
+
+This is a historic day for Vagrant. Vagrant 0.1 came out and defined
+"vagrant up" to build a development environment for any application.
+Vagrant 1.1 made it possible to have development environments on top of
+any provider (VMware, Docker, etc.). Vagrant 1.5 introduced the "share"
+command to collaborate. And now, Vagrant 1.7 completes the development
+process with "push" to deploy.
+
+The mission of Vagrant has been the same since day one: development
+environments made easy. This mission spans any language choice, any
+provider choice, and likewise any choice of how to deploy these
+applications. Push continues this mission by adding a necessary
+feature to the development workflow.
+
+With Vagrant 1.7 available, we'll be blogging about more of the features
+as well as creeping towards a 2.0!