Travis

Deployment (v2)

This page documents deployments using the dpl v2. Please see our blog post for details. You can check previous dpl v1 documentation here.

How to opt in to different deployment tooling versions #

In order to use different version of our deployment tooling, please add the following to your .travis.yml:

deploy:
  provider: <provider>
  # ⋮
  dpl_version: <version> # Optional, defaults to the latest stable version

if you want to use the latest edge version of the deployment tooling:

deploy:
  provider: <provider>
  # ⋮
  edge: true

if you want to use other edge version of the deployment tooling:

deploy:
  provider: <provider>
  # ⋮
  dpl_version: <version.beta>
  edge: true

Supported Providers #

Continuous Deployment to the following providers is supported:

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 tested
  • beta - the provider has been in alpha for at least a month and successful real-world production deployments have been observed
  • stable - 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 or alpha, 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.

See Conditional Deployments.

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 using skip_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 mentioning skip_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.