Deploy hooks are scripts that you write which are executed at designated points in the deployment process. This allows you to customize the deployment of your application to meet its particular needs.
For example, if your application uses Resque, then deploy hooks provide a way for you to restart your Resque workers when you deploy a new version of your application. Rollbar users can use deploy hooks to notify Rollbar of a deploy.
For non-Ruby deploy hooks, you can write them in any Unix executable programming language you prefer. You can have a combination of Ruby and non-Ruby hooks. However, only one hook script will be executed per hook point and the Ruby one takes precedence. See Use Ruby Deploy Hooks for Ruby specific information.
Deploy hooks live in the
APP_ROOT/deploy directory of your application. The order in which they run is specified in the documentation for the
ey deploy command.
Important: When you add a new instance, Engine Yard automatically runs the deploy hooks.
input_ref will not be available and the deploy hooks will fail if you use it. This is a known issue and we are working on a fix. In the meantime, confirm that
input_ref is not nil and
repo is nil.
Structure and sequence
To use deploy hooks, create an
APP_ROOT/deploy directory in your application and save named hook files in this directory which will be triggered at the appropriate times during the deployment process. The files are defined as follows and run in the order listed:
Note: For migrations to run, your entire environment must be loaded. So if you have any symlinks that must be created for the application to start properly, put them in
before_migrate. Do NOT put them in
before_symlink runs after the migration.
Any deploy hooks that you have defined are called, even if they are hooking into a step that is not necessary for the deployment. For example,
after_migrate is called even if there are no new migrations in your deployment.
The following environment variables are available to the deploy hook scripts. For example, in a bash script you could access the application name via
The name of the account that owns the application.
The name of the application: e.g.
A JSON blob containing the deploy configuration information.
If the server is a utility instance, this is the name of the server. It is unset for all other server types.
The roles of the server the hook is being run on.
This is the name of the environment that the application is deploying on: e.g.
The value for RAILS_ENV et al. This is copied into
The full path to the directory containing the release of the application that is being deployed.
1 if the deploy is being done with verbose logging, 0 otherwise.