在过去的几个月里，我们一直在重写当前的代码库 dpl，我们的部署工具，并发布了新的主要版本：dpl v2。
几乎每一行代码都经过了修改，代码质量、测试覆盖率和测试质量都有了很大的提高，许多支持的服务提供商和志愿者贡献者也参与其中。我们很高兴看到这个庞大的社区努力改进和现代化 dpl，并为您提供最佳的部署体验。
这个工作的主要 pull request 的 diff 统计数据，可以大致了解其规模。
在这大约 16,000 行代码中，不到 7,000 行是实现代码，其余的是文档、测试等。
今天，我们发布了 dpl v2.0.0-alpha.1 作为开发者预览版，并希望您能试用它。
您可以通过在您的 .travis.yml 文件中添加以下内容来选择加入。
deploy:
- provider: [your-provider]
edge: true
...在我们可以发布稳定版本之前，此版本不会成为默认版本，但一如既往，我们非常感谢您的早期反馈。我们很乐意欢迎您加入 社区论坛，分享您的想法。
在此过程中，近 30 个 pull request 已经被移植并合并到新的代码库中。如果您有任何尚未解决的公开问题，请提醒我们。
我们为 dpl 提供商（每个服务“插件”）实施了一个成熟度模型，这将有助于我们以编程方式传达对提供商稳定性的预期，例如，在您的构建日志、我们的自述文件和命令行工具的帮助输出中（例如，如果在 Travis CI 之外使用）。
该模型包括 4 个级别
dev - 提供商处于开发阶段（初始级别）alpha - 提供商已通过完整测试beta - 提供商已处于 alpha 阶段至少一个月，并且已经观察到成功的真实世界生产部署stable - 提供商已处于 beta 阶段至少两个月，并且没有开放的错误可以被归类为严重错误（例如部署失败、文档功能故障等）。根据上述标准，大多数提供商目前都处于 alpha 阶段：它们是先前功能的完整测试移植，但我们尚未看到任何真实世界的生产部署。少数提供商处于 dev 阶段，因为我们需要端到端的集成测试，将其部署到相应服务。
您可以在自述文件中的 支持的提供商 下查看您喜欢的部署提供商。
以下是如何帮助我们推动工作进展
alpha 阶段移出。dev 阶段的提供商之一。您可以帮助我们以自动化方式进行实际的测试部署。请在 社区论坛 中告知我们。
由于这是一个新的主要版本，它也是（相当罕见地）让我们纠正早期决策的机会，这些决策后来被证明并不那么好。
Dpl v2 包含两个重大变更，至少从技术角度来看是重大的。我们预计这不会真正影响许多部署，但有时事物可能表现略有不同，因此我们称它们为“重大变更”。
它们是
cleanup: truekeep_history: falseskip_cleanup 现在已弃用，cleanup 默认值为 false。默认值曾经是 true，因此您必须使用 skip_cleanup 选择退出...并且已经被 大量 使用。从任何剩余的构建工件中清理工作目录，只对少数提供商有意义，因此我们改变了此默认值。
如果您需要在构建后清理 Git 工作目录，您现在需要使用以下内容来选择加入
deploy:
- provider: [your-provider]
cleanup: true此外，对于 GitHub Pages 提供商，原始的默认行为是将新的孤儿分支 git push --force 到您的目标存储库和分支（例如 gh-pages），从而擦除该分支上的 Git 历史记录。
由于这通常不是期望的行为，因此后来添加了一个选项 keep_history，以避免破坏该默认行为。
我们借此机会改变了此默认值：提供商 pages 现在默认情况下将保留目标存储库和分支的现有历史记录。
如果您出于任何原因需要您的部署擦除该历史记录，从 dpl v2 开始，您将需要选择加入
deploy:
- provider: pages
keep_history: false我们重写代码的目标是保留现有功能，而不是改变它。但仍有一些值得一提的功能变更。
npm 提供商现在支持指定自定义注册表，例如 MyGet 或 GitHub。OpenShift 提供商已经过时一段时间了，现在已恢复。Open Shift 的 API 已经改变，我们已经与 OpenShift 团队合作，用全新的实现来替换它，该实现适用于 OpenShift v3。GitHub Pages。到目前为止，在使用某些提供商时，部署失败并不总是会使构建失败或出错。这意味着，如果您的部署失败，您可能不会收到通知。
从 dpl v2 开始，部署失败始终会使构建失败。
在少数几种情况下，您 确实 希望静默忽略部署失败，您可以使用以下命令选择退出使构建失败。
deploy
- provider: [your-provider]
allow_failure: trueDpl 是一个用 Ruby 编写的开源项目，始于 Travis CI 的早期阶段。它是社区驱动的，但由 Travis CI 开发人员维护，并且已被许多其他平台（例如 GitLab）改编和使用。
Dpl 支持 40（四十）个部署提供商，其中许多是我们是在过去的 6 年中您贡献时才了解到的。
所有这些累积的领域知识都物超所值。它使您能够部署到任何这些服务，而无需学习太多关于底层工具的信息，也无需经历在 Travis CI 上手动设置事物的麻烦。
Hiro 在处理这种持续涌入的知识和变化方面做出了出色的工作。我们喜欢将他的职位视为多年来一直坐在独角兽仙尘混乱的接收端。
但是，我们并非总是能够在保持代码质量高、测试一致性和完整性以及所有功能与相应服务的变化保持同步方面做得最好。
在多元化的社区环境中维护集中式代码非常有教育意义且有趣，但也可能具有挑战性。贡献有时来自不太熟悉 Ruby 的开发者，而且经常来自具有不同风格和方法的开发者。当然，如果它们能添加到现有功能或新功能中，我们仍然会接受它们。
我们经常会急于接受 pull request，而且并非总是能够抽出时间和资源来帮助重构、清理代码并消除一致性问题。
因此，我们决定是时候重写代码了。
由于这是宣布开发者预览版的公告，我们认为向您提供一些更详细的技术信息会很有趣。
我们重写代码的目标是保留现有功能，但提高代码质量、可维护性和一致性。
以下是简而言之的底层变化。
dpl gem 中，并且由给定提供者类所需的 Ruby gem 现在使用 Bundler 的 内联 策略在运行时（而不是加载时）安装和加载。这简化了很多事情，并且消除了我们构建子 gem 的需求，这是我们之前处理不同提供者实现需求之间的不兼容性的策略。所有这些都很棒，因为
要求指定所有选项使我们能够以编程方式了解我们实际支持的选项。这意味着我们现在可以自动生成 README，并自动验证 deploy 部分在 构建配置格式规范中，以及文档。
使用丰富的命令行解析器可以显着减少实现代码，并强制执行在处理未知选项、缺少选项、格式错误的值等方面的一致行为。
将 shell 命令和面向用户的日志消息与实现代码分离，可以实现一些小的改进。它可以轻松地概述给定提供者类使用的命令，比较消息并发现措辞中的不一致之处。它还使实现更加专注于逻辑，这有助于模式识别。
提供有意义的 DSL 意味着实现者不必过分担心我们的特定实现需求，而可以更多地关注他们需要提供的逻辑和行为。这对我们很重要，因为它在非常多样化且有些混乱的社区环境中强制执行一致性，从而通过强制执行标准来降低沟通的复杂性和工作量。（它还需要为贡献者提供更好的文档，我们希望通过投入大量工作来解决 README、 CONTRIBUTING 指南和 rubydocs。）
我们想向那些投入时间和精力与我们一起改进 dpl 的人表示衷心的感谢。
衷心感谢