Use Non-Ruby Deploy Hooks

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:

APP_ROOT/ 
   deploy/  
    before_bundle  
    after_bundle  
    before_compile_assets  
    after_compile_assets  
    before_migrate  
    after_migrate  
    before_symlink  
    after_symlink  
    before_restart  
    after_restart 

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 because 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.

Environment Variables

The following environment variables are available to the deploy hook scripts. For example, in a bash script you could access the application name via $EY_DEPLOY_APP.

• EY_DEPLOY_ACCOUNT_NAME

  The name of the account that owns the application.

• EY_DEPLOY_APP

  The name of the application: e.g. myapp

• EY_DEPLOY_CONFIG

  A JSON blob containing the deploy configuration information.

• EY_DEPLOY_CURRENT_NAME

  If the server is a utility instance, this is the name of the server. It is unset for all other server types.

• EY_DEPLOY_CURRENT_ROLES

  The roles of the server the hook is being run on.

• EY_DEPLOY_ENVIRONMENT_NAME

  This is the name of the environment that the application is deploying on: e.g. myenvironment or myapp_staging.

• EY_DEPLOY_FRAMEWORK_ENV

  The value for RAILS_ENV et al. This is copied into RAILS_ENV, RACK_ENV, NODE_ENV, and MERB_ENV.

• EY_DEPLOY_RELEASE_PATH

  The full path to the directory containing the release of the application that is being deployed.

• EY_DEPLOY_VERBOSE

  1 if the deploy is being done with verbose logging, 0 otherwise.

  ---

  If you have feedback or questions about this page, add a comment below. If you need help, submit a ticket with Engine Yard Support.