Heroku Deployment

This page documents deployments using dpl v1 which is currently the legacy version. The dpl v2 is released, and we recommend useig it. Please see our blog post for details. dpl v2 documentation can be found here.

Deploy Custom Application Names
Deploy Specific Branches
Run Commands
Deploy build artifacts

Travis CI can automatically deploy your Heroku application after a successful build.

To use the default configuration, add your encrypted Heroku api key to your .travis.yml:

deploy:
  provider: heroku
  api_key:
    secure: "YOUR ENCRYPTED API KEY"

If you have both the Heroku and Travis CI command line clients installed, you can get your key, encrypt it and add it to your .travis.yml by running the following command from your project directory:

travis encrypt $(heroku auth:token) --add deploy.api_key

travis command defaults to using travis-ci.org as the API endpoint. If your build runs on travis-ci.com (even if your repository is public), add --pro flag to override this:

travis encrypt $(heroku auth:token) --add deploy.api_key --pro

You can also use the Travis CI command line setup tool travis setup heroku.

Deploy Custom Application Names #

By default, we will try to deploy to an application by the same name as the repository. For example, if you deploy an application from the GitHub repository travis-ci/travis-chat without explicitly specify the name of the application, Travis CI will try to deploy to a Heroku app named travis-chat.

You can explicitly set the name via the app option:

deploy:
  provider: heroku
  api_key: ...
  app: my-app-123

It is also possible to deploy different branches to different applications:

deploy:
  provider: heroku
  api_key: ...
  app:
    master: my-app-staging
    production: my-app-production

If these apps belong to different Heroku accounts, you will have to do the same for the API key:

deploy:
  provider: heroku
  api_key:
    master: ...
    production: ...
  app:
    master: my-app-staging
    production: my-app-production

Deploy Specific Branches #

If you have branch-specific options, as shown above, Travis CI will automatically figure out which branches to deploy from. Otherwise, it will only deploy from your master branch.

You can also explicitly specify the branch to deploy from with the on option:

deploy:
  provider: heroku
  api_key: ...
  on: production

Alternatively, you can also configure it to deploy from all branches:

deploy:
  provider: heroku
  api_key: ...
  on:
    all_branches: true

Builds triggered from Pull Requests will never trigger a deployment.

Run Commands #

In some setups, you might want to run a command on Heroku after a successful deployment. You can do this with the run option:

deploy:
  provider: heroku
  api_key: ...
  run: "rake db:migrate"

It also accepts a list of commands:

deploy:
  provider: heroku
  api_key: ...
  run:
    - "rake db:migrate"
    - "rake cleanup"

Take note that Heroku app might not be completely deployed and ready to serve requests when we run your commands. To mitigate this situation, you can add a sleep statement to add a delay before your commands.

Error Logs for Custom Commands #

Custom Heroku commands do not affect the Travis CI build status or trigger Travis CI notifications.

Use an addon such as Papertrail or Logentries to get notifications for rake db:migrate or other commands.

These add-ons have email notification systems that can be triggered when certain string matches occur in your Heroku logs. For example you could trigger an e-mail notification if the log contains “this and all later migrations canceled”.

Restart Applications #

Sometimes you want to restart your Heroku application between or after commands. You can easily do so by adding a “restart” command:

deploy:
  provider: heroku
  api_key: ...
  run:
    - "rake db:migrate"
    - restart
    - "rake cleanup"

Deploy build artifacts #

After your tests run and before the deploy, Travis CI will clean up any additional files and changes you made.

Maybe that is not what you want, as you might generate some artifacts (think asset compilation) that are supposed to be deployed, too. There is now an option to skip the clean up:

deploy:
  provider: heroku
  api_key: ...
  skip_cleanup: true

Conditional Deploys #

It is possible to make deployments conditional using the on option:

deploy:
  provider: heroku
  api_key: ...
  on:
    branch: staging
    rvm: 2.0.0

The above configuration will trigger a deploy if the staging branch is passing on Ruby 2.0.0.

You can also add custom conditions:

deploy:
  provider: heroku
  api_key: ...
  on:
    condition: "$CC = gcc"

Available conditions are:

all_branches - when set to true, trigger deploy from any branch if passing
branch - branch or list of branches to deploy from if passing, defaults to master if no branch is specified.
tags - when set to true, Travis CI only deploys on tagged builds. Due to a limitation, this condition must be paired with `all_branches` set to true. Otherwise the default condition for branches will interfere with the tags condition.
condition - custom condition or list of custom conditions
jdk - JDK version to deploy from if passing
node - NodeJS version to deploy from if passing
perl - Perl version to deploy from if passing
php - PHP version to deploy from if passing
python - Python version to deploy from if passing
ruby - Ruby version to deploy from if passing
repo - only trigger a build for the given repository, to play nice with forks

Deploy Strategy #

Travis CI supports different mechanisms for deploying to Heroku:

api: Uses Heroku’s Build API. This is the default strategy.
git: Does a git push over HTTPS.

It defaults to api, but you can change that via the strategy option:

deploy:
  provider: heroku
  api_key: ...
  strategy: git

Use the .gitignore on git strategy #

When you use any of the git strategies, be mindful that the deployment will honor .gitignore.

If your .gitignore file matches something that your build creates, use before_deploy to change its content.

Run Commands Before or After Deploy #

Sometimes, you want to run commands before or after deploying. You can use the before_deploy and after_deploy stages for this. These will only be triggered if Travis CI is actually deploying.

before_deploy: "echo 'ready?'"
deploy:
  ..
after_deploy:
  - ./after_deploy_1.sh
  - ./after_deploy_2.sh