Deployment (v2)
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.
How to opt in to v2 #
In order to use version v2
of our deployment tooling, please add the
following to your .travis.yml
:
deploy:
provider: <provider>
# ⋮
edge: true
Supported Providers #
Continuous Deployment to the following providers is supported:
- anynines
- AWS CloudFormation
- AWS CodeDeploy
- AWS Elastic Beanstalk
- AWS Lambda
- AWS OpsWorks
- AWS S3
- Azure Web Apps
- Bintray
- Bluemix CloudFoundry
- Boxfuse
- Cargo
- Chef Supermarket
- Cloud 66
- Cloud Foundry
- Convox
- Datica
- Engine Yard
- GitHub Pages
- GitHub Releases
- Gleis
- Google App Engine
- Google Cloud Storage
- Google Firebase
- Hackage
- Hephy
- Heroku
- Launchpad
- NPM
- Netlify Drop
- OpenShift
- packagecloud
- Puppet Forge
- PyPI
- Rackspace Cloud Files
- RubyGems
- Scalingo
- Script
- Snap Store
- Surge.sh
- TestFairy
- Transifex
To deploy to a custom or unsupported provider, use the after-success build step or script provider.
Pull Requests #
Note that pull request builds skip the deployment step altogether.
Maturity Levels #
In order to communicate the current development status and maturity of dpl’s support for a particular service, the respective provider is marked with one of the following maturity levels, according to the given criteria:
dev
- the provider is in development (initial level)alpha
- the provider is fully testedbeta
- the provider has been in alpha for at least a month and successful real-world production deployments have been observedstable
- the provider has been in beta for at least two months and there are no open issues that qualify as critical (such as deployments failing, documented functionality broken, etc.)
Dpl v2 represents a major rewrite, so support for all providers has been reset to
dev
oralpha
, depending on the test status.
For all levels except stable
a message will be printed to your build log
that informs you about the current status.
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 <PROVIDER_NAME>_PASSWORD <password>
In order to encrypt option values when adding them to your .travis.yml
file
use travis encrypt
:
travis encrypt <password>
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.password <password>
Conditional Deploys #
You can deploy only when certain conditions are met.
Cleaning up the Git Working Directory #
By default your Git working directory will not be cleaned up before the deploy step, so it might contain left over artifacts from previous steps.
For many providers and deployment targets this is not an issue or even intended.
If you do need to clean up the working directory from any changes made during
the build process, you can add the following to your .travis.yml
file:
deploy:
provider: [your provider]
cleanup: true
Please note that the previous version of dpl, our deployment integration tooling, used to reset your working directory and delete all changes made during the build using
git stash --all
. In order to keep changes one had to opt out usingskip_cleanup: true
. This default turned out to be useful only for very few providers and has been changed in dpl v2. You still might find external tutorials or posts mentioningskip_cleanup
.
Running commands before and after the deploy step #
Sometimes you want to run commands before or after deploying.
You can use the before_deploy
and after_deploy
steps for this.
Please note: 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
Deploying to multiple targets #
Running multiple deployments to different providers (or the same provider with
different configurations) is possible by adding configurations to the deploy
section as a list. For example, if you want to deploy to both s3 and Heroku,
your deploy
section would look something like this:
deploy:
- provider: s3
access_key_id: <AWS access key id>
secret_access_key: <AWS secret access key>
# ⋮
- provider: heroku
api_key: <Heroku api key>
# ⋮
Running an edge version #
If you contribute to or experiment with dpl, our deployment tooling, make sure you use the edge version from GitHub:
deploy:
provider: <your-provider>
edge:
branch: master
source: <GitHub handle>/dpl # only needed for forks of travis-ci/dpl
You can find more information about contributing to dpl here.