Home

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.

Deploy

Now that we have set up our environment, we can deploy our app to our staging server with the following command:

$ deploy stage
... deploying origin/master
HEAD is now at 1bb798d Release 2.3.10
... deploy complete

The next important step, is to create a post-deploy command, typically used to signal a restart. For example if you utilize cluster you may want the post-deploy script at $path/restart.sh to signal a graceful restart via SIGUSR2.

In our config we simply supply the path:

post-deploy ./current/restart.sh

or perhaps a command similar to below:

post-deploy cat shared/pids/master.pid | xargs kill -s SIGUSR2

deploy hooks are executed relative to path, meaning the current deploy is located at ./current.

Reverting

To revert or "roll back", we can simply invoke:

$ deploy stage revert

deploy(1) appends the commit shas to $path/.deploys, which allows us to roll back one or more releases. Below we roll back two releases:

$ deploy stage revert 2

Debugging

To check out the verbose deploy log simply:

$ cat /tmp/deploy.log

We can check what the current commit sha is by executing:

$ deploy stage current
1bb798d

Or run arbitrary commands relative to path:

$ deploy stage run cat shared/logs/workers.error.log