Clone this wiki locally
First up we need to create ./deploy.conf for our staging environment
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 firstname.lastname@example.org: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 email@example.com:my/repo.git path /var/www/foo.com post-deploy ./restart
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
deploy(1) moves on and performs the initial clone the repo into
Example Rails Deploy
Here is an example deploying a Rails app to a Passenger server:
[production] user deploy host www.example.com repo firstname.lastname@example.org: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 email@example.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
./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.