Dpl (dee-pee-ell) is a deploy tool made for continuous deployment.
Dpl (dee-pee-ell) is a deploy tool made for continuous deployment.
This version of the README documents dpl v2, the next major version of dpl. The README for dpl v1, the version that is currently used in production on Travis CI can be found here.
Dpl is command line tool for deploying code, html, packages, or build artifacts to various service providers.
It is tightly integrated into Travis CI's deployment integration, but also used, and recommended by others, such as GitLab.
It is maintained by Travis CI, largely community driven, and it has existed since 2013. If you find support your preferred deployment target missing, please do not hesitate to get in touch, and we'll help you add it.
Dpl requires Ruby 2.3 or later.
Depending on the deployment target dpl might require additional runtimes (e.g. Go, Node.js, or Python) to be installed. It also might require sudo access in order to install a Debian package.
Dpl is generally optimized for usage on Linux systems.
This version of dpl is currently released as an alpha preview release. In
order to install it, add the --pre flag:
gem install dpl --preDpl is meant and optimized for usage in ephemeral build environments, such as Travis CI, or any other CI/CD pipeline.
Dpl is integrated to Travis CI's build configuration and build script compilation
tooling, so all you need to do is add the proper configuration to your .travis.yml
file. Please refer to the documentation
for details.
For usage outside of Travis CI dpl can be executed as follows. Please refer to the respective providers for details.
dpl [provider] [options]Dpl can be used locally, e.g. on your development machine, but it might leave artifacts that may alter the behaviour of your system. If you encounter this behaviour and it presents a serious issue to you then please open an issue.
Dpl v1 has cleaned up the Git working directory by default, using git stash --all. The default for this option has been changed in dpl v2, and users now
need to opt in to cleaning up any left over artifacts from the build process
by passing the option --cleanup.
The status of the working directory is relevant only to providers that package
and push it to the respective remote service (e.g. heroku when using the
api strategy, package registry providers, etc.). Most providers will either
push the latest Git commit, or pull code from a remote repository.
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 a month, and there are no open issues that qualify as critical (such as deployments failing, documented functionality broken, etc)Dpl supports the following providers:
Support for deployments to Anynines is in alpha. Please see Maturity Levels for details.
…Options can be given via env vars if prefixed with ANYNINES_. E.g. the option --password can be
given as ANYNINES_PASSWORD=.
…Options can be given via env vars if prefixed with [AWS_|CLOUDFORMATION_]. E.g. the option
--access_key_id can be given as AWS_ACCESS_KEY_ID= or
CLOUDFORMATION_ACCESS_KEY_ID=.
…Options can be given via env vars if prefixed with [AWS_|CODEDEPLOY_]. E.g. the option
--access_key_id can be given as AWS_ACCESS_KEY_ID= or
CODEDEPLOY_ACCESS_KEY_ID=.
The following variable are availabe for interpolation on description:
application, bucket, bundle_type, commit_id, deployment_group, endpoint, file_exists_behavior, git_author_email, git_author_name, git_branch, git_commit_author, git_commit_msg, git_sha, git_tag, key, region, repository, revision_type, build_number
Support for deployments to AWS ECR is in alpha. Please see Maturity Levels for details.
…Options can be given via env vars if prefixed with AWS_. E.g. the option --access_key_id can be
given as AWS_ACCESS_KEY_ID=.
…Options can be given via env vars if prefixed with [AWS_|ELASTIC_BEANSTALK_]. E.g. the option
--access_key_id can be given as AWS_ACCESS_KEY_ID= or
ELASTIC_BEANSTALK_ACCESS_KEY_ID=.
…Options can be given via env vars if prefixed with [AWS_|LAMBDA_]. E.g. the option
--access_key_id can be given as AWS_ACCESS_KEY_ID= or
LAMBDA_ACCESS_KEY_ID=.
The following variable are availabe for interpolation on description:
dead_letter_arn, function_name, git_author_email, git_author_name, git_branch, git_commit_author, git_commit_msg, git_sha, git_tag, handler_name, kms_key_arn, memory_size, module_name, region, role, runtime, timeout, tracing_mode, zip
…Options can be given via env vars if prefixed with [AWS_|OPSWORKS_]. E.g. the option
--access_key_id can be given as AWS_ACCESS_KEY_ID= or
OPSWORKS_ACCESS_KEY_ID=.
…Options can be given via env vars if prefixed with [AWS_|S3_]. E.g. the option --access_key_id
can be given as AWS_ACCESS_KEY_ID= or S3_ACCESS_KEY_ID=.
Support for deployments to Azure Web Apps is in alpha. Please see Maturity Levels for details.
…Options can be given via env vars if prefixed with AZURE_WA_. E.g. the option --password can be
given as AZURE_WA_PASSWORD=.
…Options can be given via env vars if prefixed with BINTRAY_. E.g. the option --key can be given
as BINTRAY_KEY=.
…Options can be given via env vars if prefixed with CLOUDFOUNDRY_. E.g. the option --password can
be given as CLOUDFOUNDRY_PASSWORD=.
Support for deployments to Boxfuse is in alpha. Please see Maturity Levels for details.
…Options can be given via env vars if prefixed with BOXFUSE_. E.g. the option --secret can be
given as BOXFUSE_SECRET=.
…Options can be given via env vars if prefixed with CARGO_. E.g. the option --token can be given
as CARGO_TOKEN=.
Support for deployments to Chef Supermarket is in alpha. Please see Maturity Levels for details.
…Options can be given via env vars if prefixed with CHEF_.
Support for deployments to Cloud Files is in alpha. Please see Maturity Levels for details.
…Options can be given via env vars if prefixed with CLOUDFILES_. E.g. the option --api_key can be
given as CLOUDFILES_API_KEY=.
…Options can be given via env vars if prefixed with CLOUDFOUNDRY_. E.g. the option --password can
be given as CLOUDFOUNDRY_PASSWORD=.
Support for deployments to Cloud66 is in alpha. Please see Maturity Levels for details.
…Options can be given via env vars if prefixed with CLOUD66_. E.g. the option --redeployment_hook
can be given as CLOUD66_REDEPLOYMENT_HOOK=.
Support for deployments to Convox is in development. Please see Maturity Levels for details.
…Options can be given via env vars if prefixed with CONVOX_.
Support for deployments to Datica is in development. Please see Maturity Levels for details.
…Options can be given via env vars if prefixed with [CATALYZE_|DATICA_].
Support for deployments to Engineyard is in alpha. Please see Maturity Levels for details.
…Options can be given via env vars if prefixed with [ENGINEYARD_|EY_]. E.g. the option --api_key
can be given as ENGINEYARD_API_KEY= or EY_API_KEY=.
…Options can be given via env vars if prefixed with FIREBASE_. E.g. the option --token can be
given as FIREBASE_TOKEN=.
Support for deployments to Flynn is in development. Please see Maturity Levels for details.
Usage: dpl flynn [options]
Summary:
Flynn deployment provider
Description:
Flynn provider for Dpl
Options:
--git URL Flynn Git remote URL (type: string, required)
Common Options:
--cleanup Clean up build artifacts from the Git working directory before the deployment
--run CMD Commands to execute after the deployment finished successfully (type: array
(string, can be given multiple times))
--help Get help on this command
Examples:
dpl flynn --git url
dpl flynn --git url --cleanup --run cmdSupport for deployments to Git (push) is in development. Please see Maturity Levels f
No open issues yet, or sync has not completed.