diff --git a/website/www/source/blog/2014-12-12-vagrant-push-to-deploy.html.md b/website/www/source/blog/2014-12-12-vagrant-push-to-deploy.html.md new file mode 100644 index 000000000..5fdd0fc9d --- /dev/null +++ b/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. + + + +### 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!