This page documents deployments using dpl v1 which currently is the default version. The next major version dpl v2 will be released soon, and we recommend starting to use it. Please see our blog post for details. dpl v2 documentation can be found here.
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
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.
Deploying 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
Deploying 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 deploy.
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 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
sleepstatement 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”.
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 api_key: ... run: - "rake db:migrate" - restart - "rake cleanup"
Deploying build artifacts #
After your tests ran 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 pushover HTTPS.
It defaults to api, but you can change that via the strategy option:
deploy: provider: heroku api_key: ... strategy: git
git strategy #
When you use any of the
git strategies, be mindful that the deployment will
.gitignore file matches something that your build creates, use
before_deploy to change
Running commands before and after deploy #
Sometimes you want to run commands before or after deploying. You can use the
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