Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Setup

bronson edited this page · 4 revisions
Clone this wiki locally

Config

First up we need to create ./deploy.conf for our staging environment [stage]. The post-deploy hook command is executed relative to $path/current/, so it's safe to add to our repository. This is typically the most important hook, needed to perform tasks such as [re]starting the server. Generally it is good to have a deployer user, with the requiretty sudoers setting disabled. The ref setting specifies a default GIT ref when not passed via the cli, this is a good idea for a staging environment, as typically you do not do tag-based deployments for such an env.

[stage]
user deployer
host n.n.n.n
repo git@github.com:my/repo.git
path /var/www/staging
post-deploy ./restart
ref origin/develop

In contrast, a production environment (following the staging env in the same file) might look similar to below, omitting the ref, which when not explicitly passed to deploy will default to the latest tag:

[production]
user deployer
host x.x.x.x
repo git@github.com:my/repo.git
path /var/www/foo.com
post-deploy ./restart 

Setup

Once we have ./deploy.conf set up in our repo, we can initiate the deployment process, by invoking the setup command, along with the <env>, which is the staging environment in the case below.

$ deploy stage setup

This process sets up the following paths relative to the config path:

  • $path/shared
  • $path/shared/logs
  • $path/shared/pids
  • $path/source

Then deploy(1) moves on and performs the initial clone the repo into $path/source.

Example Rails Deploy

Here is an example deploying a Rails app to a Passenger server:

[production]
user deploy
host www.example.com
repo git@github.com:bronson/example.git
path /home/deploy/example
post-deploy touch tmp/restart.txt

[production-migrations]
# TODO: if the migration is lengthly, the server might start sending errors.
# probably want to put up a maintenance page before starting migration and take it down when done.
user deploy
host www.example.com
repo git@github.com:bronson/example.git
path /home/deploy/example
# source .bashrc because shell is not interactive and won't automatically load rvm.
post-deploy . ~/.bashrc && bundle && echo "running migrations..." && RAILS_ENV=production rake db:migrate && touch tmp/restart.txt

Run ./deploy production to push out a quick hotfix. If you've changed the database or Gemfile then you need to run ./deploy production-migrations. There's no harm in always running production-migrations, it just takes a little longer.

Something went wrong with that request. Please try again.