Travis

Heroku Deployment

This page documents deployments using the next major version dpl v2, which currently is in a beta release phase. Please see our blog post for details. The current default version is dpl v1. Check dpl v1 documentation here.

Be sure to read the v2 deployment overview.

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

For a minimal configuration, add the following to your .travis.yml:

deploy:
  provider: heroku:git
  api_key: <encrypted api_key>
  edge: true # opt in to dpl v2

Alternatively, you can use username and password:

deploy:
  provider: heroku:git
  username: <username>
  password: <encrypted password>

Status #

Support for deployments to Heroku Git is in alpha. Please see Maturity Levels for details.

Known options #

Use the following options to further configure the deployment. Either api_key or username and password are required.

api_key Heroku API key — secret, type: string
username Heroku username — type: string, alias: user
password Heroku password — secret, type: string
git Heroku Git remote URL — type: string

Shared options #

strategy Heroku deployment strategy — type: string, default: api, known values: api, git
app Heroku app name — type: string, default: repo name
cleanup Clean up build artifacts from the Git working directory before the deployment — type: boolean
run Commands to execute after the deployment finished successfully — type: string or array of strings

Environment variables #

All options can be given as environment variables if prefixed with HEROKU_.

For example, api_key can be given as HEROKU_API_KEY=<api_key>.

Securing secrets #

Secret option values should be given as either encrypted strings in your build configuration (.travis.yml file) or environment variables in your repository settings.

Environment variables can be set on the settings page of your repository, or using travis env set:

travis env set HEROKU_API_KEY <api_key>

In order to encrypt option values when adding them to your .travis.yml file use travis encrypt:

travis encrypt <api_key>

Or use --add to directly add it to your .travis.yml file. Note that this command has to be run in your repository’s root directory:

travis encrypt --add deploy.api_key <api_key>

Specifying the application name #

By default, your repository name will be used as the application name.

You can set a different application name using the app option:

deploy:
  provider: heroku
  # ⋮
  app: <app_name>

Running commands #

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

deploy:
  provider: heroku
  # ⋮
  run: rake db:migrate

It also accepts a list of commands:

deploy:
  provider: heroku
  # ⋮
  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.

Deploying branches to different apps #

In order to choose apps based on the current branch use separate deploy configurations:

deploy:
  - provider: heroku
    # ⋮
    app: app-production
    on:
      branch: master
  - provider: heroku
    # ⋮
    app: app-staging
    on:
      branch: staging

Or using YAML references:

deploy:
  - &deploy
    provider: heroku
    # ⋮
    app: app-production
    on:
      branch: master
  - <<: *deploy
    app: app-staging
    on:
      branch: staging

Error Logs for Custom Commands #

Custom Heroku commands do not affect the Travis CI build status or trigger Travis CI notifications, because Heroku’s CLI always exits with 0, even if the command failed.

As an alternative, you can 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” or similar messages.

Restarting 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
  # ⋮
  run:
    - rake db:migrate
    - restart
    - rake cleanup

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
  # ⋮
  strategy: git

Using .gitignore on the 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.

Pull Requests #

Note that pull request builds skip the deployment step altogether.

See also #