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.
- Requirements
- Installation
- Usage
- Maturity Levels
- Supported Providers
- Contributing to Dpl
- Old Issues
- Code of Conduct
- License
- Credits
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:
<% providers.each do |key, name| -%>
- <%= "#{name}" %> <% end -%>
<% providers.each do |key, name|%>
<%= header(key) %>
<%= help(key) %><%= footer(key) %> <% end -%>
<%= File.read('./CONTRIBUTING.md').gsub(/^#/, '##') %>
If an issue has been left open and untouched for 90 days or more, we automatically close them. We do this to ensure that new issues are more easily noticeable, and that old issues that have been resolved or are no longer relevant are closed. You can read more about this here.
Please see our code of conduct for how to interact with this project and its community.
Dpl is licensed under the MIT License.
This tool would not exist without your help.
A huge thank you goes out to all of our current and past contributors:
<%= contributors %>