我分享这些并不是为了羞辱或责备任何人，相反，每个团队都充满了聪明的人，试图利用我们当时拥有的工具和限制来做正确的事情。在过去的二十年里，我们共同学习了很多关于如何交付软件的知识，我们可以使用这些示例来探索为什么您希望为您的服务进行持续部署。

在我职业生涯的早期，我支持一个开发团队，该团队计划在一周中规定的一天进行部署，当天晚些时候不可避免地进行回滚，并在本周晚些时候部署修补程序。这听起来像是一种批评，但事实并非如此。该团队试图以每周的节奏交付商业价值——这在每季度甚至每年发布的时代几乎是闻所未闻的。这发生在 2000 年代初，自动化测试框架几乎不存在，Subversion 源代码控制工具刚刚发布。该团队没有自动构建或测试，可执行文件是手动（通常由我）复制到目标服务器的。当我写下这篇文章时，我不禁对这个系统的运作印象深刻。找出问题所在很容易，但他们做对了什么？

1. 变更集很小，不到几个开发人员一周的变更量。
2. 客户的反馈是即时的。
3. 在部署之前可以进行回滚并进行测试。

我在 BlackBerry 工作的一项服务已不再使用，每季度发布一次，采用传统的开发完成代码锁定、漫长的测试阶段以及在可怕的 0200-0400 周末更改窗口中非常复杂的手动部署过程。尽管每个版本都经过了数千小时的测试，但几乎每次部署都会导致回滚或多个修补程序来解决出现的问题。这项服务面临的最大挑战是变更集的庞大规模，其中包含二十个或更多开发人员三个月的工作。没有人能够理解更改的范围，尽管有一支庞大且技术精湛的 QA 团队，但这使得每次部署都存在风险。

与我在 Arctic Wolf 的最新经历相比，我们实施了持续部署，并且几乎每小时都会根据最新更改重新部署一些服务。该系统并不完美，我们肯定有错误进入生产环境，但除了少数例外，我们发现修复错误并部署该更改几乎总是比尝试回滚部署更容易。

持续部署可以为您带来什么

我可以写一整本书来介绍实施持续部署的优势，但为了读者的利益，让我们探讨风险、质量、成本、速度、幸福感和安全性。

风险较小

几十年前的变革管理理念是，变革是稳定的敌人，这一理念在一些较老的组织中仍然普遍存在，并在 2000 年代初的 BlackBerry 中使用。为了维持服务的正常运行时间为五个九，必须限制变更并仔细控制变更。不幸的是，这与产品和开发团队发布新功能或修复错误的需求发生了直接冲突。在我的第二个例子中，冲突显而易见——运营团队在严格的 SLA 驱动下，有责任提供极其稳定的服务。产品和开发团队必须发布新功能，结果是不频繁但非常大的变化，以及两个团队之间不可避免的冲突。

通过持续部署，变更集应该很小但很频繁，并且新功能会以易于理解的小批量方式引入。当出现不可避免的问题时，团队可以很快缩小导致问题的确切变化范围。较小的变更集可以降低大规模停机的风险。

为了实现持续部署，有一个基本假设，即您的软件可以通过蓝/绿部署和零停机时间以滚动方式进行部署。这也意味着您的基础设施是使用基础设施即代码定义的，不需要手动干预即可部署。这也降低了风险，因为部署是自动化的、可重复的和可测试的。

更高品质

一套可靠的自动化测试是实施持续部署的关键要求。如果您的团队致力于使这些测试保持最新，则应该在部署之前捕获回归，从而产生更高质量的软件。我曾经无意中听到一个团队说“我们不相信我们的测试”，因此又恢复到手动测试，并每周部署一次或更短时间。由于他们是手动测试，因此他们在速度和质量方面都遇到了困难。一旦他们重新控制了测试套件，他们的速度和质量就恢复了。

更低的花费

多项研究表明，错误从开发人员转移到客户手中的时间越长，修复成本就会呈指数级增长。开发持续部署所需的自动化测试肯定会产生前期成本，但错误会在开发周期的早期被发现，从而从长远来看降低总体成本。

更快的上市时间

将我的黑莓示例与其他两个示例进行比较，客户可能需要长达六个月的时间才能看到新功能或错误修复。在另外两个示例中，团队可以更快地提供新功能，只需几周甚至几小时。

DORA 的四个指标之一（有关更多详细信息，请参阅下面的衡量成功）是“变更交付时间”，或者从提交代码到部署到生产所需的时间。假设其他指标也一致，这个数字越低越好。能够在数小时内向客户部署变更的组织比需要六个月的组织要成功得多。

更快乐的团队

我最喜欢的 Slack 反应之一是“#YOLO”图标，我的同事会用它来表明他们已经审查并批准了 GitHub 拉取请求。它部分是用来开玩笑的，因为每个人都非常关心我们正在部署的服务，但它也部分是对 CI/CD 管道和测试基础设施以及我们对其的信任的认可。我作为领导者的既定目标是，开发人员应该能够合并他们的代码更改，然后离开去吃午饭，相信 CI/CD 管道会正确构建、测试和部署更改，如果出现严重错误，要么回滚更改或通过 PagerDuty 调用它们。这是一个崇高的目标，但我认为我们还没有完全实现这一目标。事实上，我和我的同事通常会在变更推出时对其进行跟踪，但我希望我们有信心自动化会发挥作用。