Heroku Deployment
This page documents deployments using the dpl v2. Please see our blog post for details. You can check previous dpl v1 documentation here.
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.