持续部署 vs 持续交付， 什么时候发布

关于持续交付，我最喜欢的描述之一是：持续工作，并使你的软件始终处于可发布状态。然而，这并没有说明什么时候真正将更改发布到生产环境中。在谈论连续交付时，最常见的假设之一是它实际上意味着持续发布。因此，我们需要决定发布什么以及多久发布一次更改。

嗨，我是《持续交付2.0》的作者乔梁，欢迎订阅我的公众号。

接下来，我想探讨一下发布到生产环境的决定。一个思考持续交付的好方法是，我们正在努力最大化反馈，但具有不同级别的反馈对我们是很重要。

我们对变更质量的技术反馈感兴趣，我们可以从效果中获得最好的快速有效的部署流水线。这来证明：我们正在构建正确的东西吗？

但我们也要对我们创建的产品的反馈感兴趣。它要回答的是：我们构建的东西是正确的吗？

部署流水线为我们提供了一种可重复的可靠方式来确保我们构建正确的东西。如果你听取我的建议并组织你的部署流水线，使其从提交到可发布的结果，现在流水线为我们提供了关于可发布性的明确声明。如果你的变更通过部署流水线，并且在部署流水线中表现得很好，这将使我们处于向前开发的绝佳位置。

但对于另一个问题，即：我们是否构建了正确的东西，唯一的检查方法是发布并查看用户对我们的更改做出了什么反应。

我们在这里谈论的是持续交付和持续部署之间的区别。对于持续交付来说，持续部署是一个有价值的发布策略，但它不是唯一的。我们可以通过持续交付确保我们在定义上是一致的。如果流水线指示我们的更改已经通过，没有更多的工作要做，那么它就是可发布的。

但是，我们可以选择自动启动部署本身或者手工进行交付。对于持续部署，如果所有的自动化都能顺利运行，我们只需要将其发布到生产环境中，这是非常理想的。

很多人认为持续交付的全部内容都在于这些连续部署中。但我认为每个人都有更多的东西，实际上它们是非常密切相关的。当然，在没有持续部署的情况下，你当然可以实践持续交付。但如果不实践持续交付，你就无法真正实践和控制持续部署。

（图片来源于网络）

尽可能地练习持续部署是最好的选择，但这有点太简单了。让我们先放一下这个想法。请记住，所有这些都始于一个正常运行的部署流水线，用以确定软件变更的可发布性。有很多更好的理由倾向于更小更简单的版本。通过增加发布频率，我们不可避免地减少了每个更改的大小。亚马逊平均每11.2秒发布一次更改。自从他们采用了这种方法，修复发布引起的问题的时间减少了90%。这是因为每个更改都更小，如果每个更改都更简单，也的确会更简单，因为隐藏错误的地方更少了。

如果我们知道每一次成功的提交都会被自动推向生产，我们将对每一次提交采取更多的谨慎态度。这里有一些糟糕的数字来证明我所说的。让我们从发布更改的总风险的角度来看一下，发布更改的风险将是某种函数，取决于更改的规模。不可避免地，如果我们生产更多的软件，它出现问题的可能性就会更大。因此，我们可以想象与我们所做的每个更改相关的都有一个小的风险元素。如果我们发布的频率较低，更改的数量较多，那么我们将不得不总结与所有这些更改相关的风险。

但总风险函数的另一个部分也可能是两个或更多的更改以一种令人不快的方式相互作用。该函数的一部分将以指数级而不是线性的方式增加，因此交互作用的风险将取决于更改的数量。更改越多，两个更改发生的可能性就越高，或者说，它们中的更多人将以某种我们没有预测到的令人不快的方式进行交互。

因此，总风险在很大程度上是更改次数的函数，这是计算该风险的一个重要因素。这意味着，从某种程度上讲，更频繁地发布数据的风险较小。将事情分成更小、更简单的步骤是风险较低的策略。这不仅仅是理论。我们从DevOps的状态报告中获得的数据表明，速度和质量之间没有权衡。这当然是违反直觉的，但它还说明了更多的问题。除了降低风险之外，更频繁地在质量上比没有发布的团队得分更高。尽管更频繁地发布也给了我们更多学习的机会，但我认为要想在一系列的工作中取得进展，就是要将小步骤作为持续交付的基础构建块。

大多数情况下，持续部署是最佳策略。然而，并不是所有情况下持续部署都是最好的选择。用“麻烦”一词来描述持续部署的复杂性可能不太准确，但在某些系统中，这种复杂性在于时间是由软件开发团队而不是消费者决定的。例如，沃尔沃卡车公司采用了一种复杂的连续交付实践。然而，对于像卡车司机这样的消费者来说，在冬天的夜晚行驶时，他们可能不想进行软件更新。在这种情况下，更好的策略可能是让消费者决定何时进行更新，以确保安全。

因此，发布决策实际上更多的是一个商业决策而不是技术决策。在某些情况下，由于监管限制或商业原因，可能不适合发布软件。然而，关键是不要回到旧的坏习惯，而是继续工作，确保你的软件处于可发布的状态，以便在你想要发布时能够发布。这是继续练习持续交付的关键。另外，可以向友好的或内部用户发布最低限度可行的产品(MVP)，以收集反馈，以便判断你的产品是否有效。

我们可以采取几种不同的策略来确保我们构建了正确的产品。比如，对于构建交易所，它是金融监管限制的产品。但是，并不是所有的内容都是严格监管的，我们就可以在监管较宽松的方面，快速尝试一些想法。另外，也可以在每周五下午，将系统在内部发布到公司中，让公司所有人都停止工作，不管他们在公司的哪个部门做什么，使用这个系统进行交易。当然是使用代币（而不是真实的货币）进行交易。但，这个预演习系统的确会根据市场的真实价格进行交易。我们从产品的角度了解了大量的东西，从可用性的角度来看，什么是可行的，什么是不可行的。你无法通过猜测来学习到这些教训，只能通过实际使用软件来学习这些教训。

在真实的人类面前，我认为思考这两类不同的反馈是很有用的，持续交付的技术重点和持续部署的产品重点，它们都为我们正在构建的东西提供了宝贵但不同的见解。有了这些信息，我们才可能调整我们的方法，满足我们的业务需求。