持续交付，也是一种思维方式
乔梁约 7 分钟持续交付可能不符合你对软件开发方法的设想，但它是最有效的软件开发方法之一。无论我们正在开发什么类型的软件，应用持续交付都会带来更好的结果。我们能够创建更高质量的软件，更有效地创建软件，并在此过程中享受更多的乐趣。公司雇我们来做这些事情，他们可以因此赚更多的钱。《DevOps报告》的数据首次表明，这种软件开发方法的真正影响，这种影响已经被大多数最优秀的软件开发公司所实践。
我认为应用科学的工程思维来解决软件问题是持续交付的基础。但是，这一切意味着什么，以及如何才能实现这一切呢？
嗨，大家好，我是《持续交付2.0》的作者，乔梁。今天我们来谈谈「持续交付」。
软件交付速度和质量至关重要。然而，当软件开发过程容易出错时，我们应该如何快速而高效地生产软件呢？
软件的独特之处在于，它的创建成本很高，但复制成本几乎是免费的。一旦我们获得了代表软件系统的字节码，我们就可以以微不足道的成本复制和分发它们。这在人类历史上，软件产品是一种非常罕见的生产现象。
我认为所有这些都可以归结为：软件开发基本上都是在学习和发现的过程中进行的。为了实现它，我们需要专注于管理软件开发的复杂性。如果不学习一些技巧，我们就不会擅长学习和发现。同样地，如果不学习如何管理复杂性，我们也不会擅长管理软件开发。
持续交付提供了一种结构化的开发方法，可以帮助我们实现软件开发的这两个基本原则。首先，我们需要变得不那么主观。大多数软件开发从某个地方的一群人想出一个有用的想法开始，然后他们或另一组人提出一些关于他们可能如何实现的想法，并创造一些软件来交付它。这里的困难在于，这些想法本身可能是不好的，甚至是错误的。也许，并没有人对我们软件背后的商业想法感兴趣，或者竞争对手有更好的或类似的想法，他们用了比我们更好的实现方式击败了我们。
假如我们的软件不起作用，或者使用起来令人不舒服，怎么办？如果我们在软件开发的早期阶段遗漏了一些东西怎么办？如果我们认为，解决这些问题的唯一方法是更加努力地思考，更加努力地做计划，直到让我们的计划肯定奏效，那么，很可能这种方法并不奏效。因为，无论我们的软件设计多么好，总有一些事情是我们意想不到的，甚至是压根不可能知道的。
因此，我们不应该假设我们的计划是正确的并且已经知道答案。相反，我们应该从假设我们可能是错误的开始，即我们的产品想法或解决方案想法可能是错误的。
如果是这样，我们该如何继续进行？我们如何才能有效地找出自己在哪里犯了错？我们该如何快速且经济地恢复？
事实上，如果出现错误，我们应该聚焦于快速学习。我们可以冒着其中一个实验可能失败的风险，开始进行一系列小型实验。如果这样做，我们会学到很多东西。我们必须进行评估并控制变量，以便能够理解实验结果。我们希望能够专注于我们想要学习和尝试的东西，并找出如何准确和精确地学习这些内容。为此，我们需要控制变量，几乎所有事情都需要版本控制。这听起来很熟悉，因为这是科学的基本原理和人类最好的问题解决技术。我们需要将这种思维应用于软件和软件开发中。
持续交付是软件开发的一种整体方法。我们可以从这里开始，将我们的想法转化为实际的工作软件，并将其交给用户使用，以验证它是否实际上有用。我们可以收集用户反馈，并理解哪些想法是好的想法，哪些想法是糟糕的想法，并针对好的想法进行优化。我们需要衡量从想法到工作软件交到用户手中需要多长时间，这个时间在持续交付术语中被称为“周期时间”。
我们将尽力缩短周期时间，直到我们能够以某种方式工作，使我们的软件始终是可发布的，并且让周期时间短行令人难以置信。
我们的目标是在一天内从创意到可工作的软件交付给用户，理想情况下不到一小时。事实上，采用实验性方法来减少周期时间将帮助建立敏捷精益开发和持续交付的原则，以减少周期时间的浪费。
如果团队过大，我们就不太可能有短而高效的有效周期。如果需要协调团队的工作，那么团队就需要自治。我们必须对自动化测试、自动化部署管理和配置管理有一个很好的声明，并结合在一起，产生高质量的输出。
我们可以验证这些输出对用户是否有用，并在不必要时快速了解。我倾向于使用这张图片作为持续交付的图标。
它显示了三个外部反馈循环，其中一个是从想法到有价值的工作软件的关键反馈循环在用户手中，另一个是测试驱动开发的快速、短暂的反馈循环。在这两者之间，我们使用像可执行验收规范这样的做法来对我们的系统的开发有更广泛的看法。
持续交付是一种基于迭代和反馈的软件开发方法，因此还有很多反馈循环，但这三种主要的反馈捕捉到了本质，即我们试图从根本上实现持续交付，以改进我们的软件开发方法。
总的来说，持续交付这个术语源于敏捷宣言的第一条原则，即“我们最优先的是通过早期和持续交付有价值的软件来满足客户”。这是持续交付的基本理念。我们致力于优化这一理念，确保我们的软件始终可发布，以便我们可以快速、高效、廉价地将其交付给我们的用户。持续交付是持续集成思想的一个很好的扩展，持续集成是一种专注于开发团队的技术实践，已经实践了很多年，它是在本世纪初开始流行起来。
随着支持持续集成的工具的出现，开发人员得到了更多反馈，例如代码编译和测试运行的结果。持续交付是一种全面的软件开发方法，它需要协调和整合软件开发的各个方面，才能将想法持续交付给用户。
这要求我们擅长一些技术实践，并且需要适当的组织支持和结构，以及适当的开发和组织文化。
同时，持续交付需要建立良好的心理模型，即：每次我们提交一个更改，就要生成一个发布候选版本。我们的流程和整个开发体系的其余部分就是要证明该发布候选版本不适合投入生产。虽然你觉得这听起来有问题，但这是我们从科学中学到的思想之一：我们永远无法证明我们的软件是完美的，无论我们进行多少测试，因为我们可能会错过某些东西。但如果测试失败，我们就知道我们的软件并不完美。
这已经足够了。我可以放弃这个发布候选版本，因为它立刻表明了我们需要处理的自动化测试质量，或严重的问题。我们将使用这些测试来模拟我们的系统，如果测试失败，我们将放弃该发布候选版本，回到起点，提交新的变更，修复问题或将其还原到用户手中，交付价值。我们将专注于努力实现这一点。
最终，我们会创造一个可重复、可靠的发布软件的过程。这意味着我们将对几乎所有事情使用自动化。如果我们要自动化所有事情，我们将把所有事情都保持在版本控制中，加快这个过程。
所以，会启示我们，如果有任何困难和痛苦的事情，它会迫使我们直接面对它，解决困难和痛苦。这通常是通过自动化方式，但也可能是通过过程，直到优化其他类型的过程。
（图片来源于网络）
我们的目标是从一开始就建立质量的过程，并在方法中不断改进其中一个个问题。从历史上看，我们往往倾向于使用某种临时指标来衡量，例如完成了哪几个模块，定义或计算代码行、功能点或特性点。实际上，在持续交付中，这类想法都不起作用。我们将避免这些问题。相反，我们将以小步骤工作。在每次变更后，我们的软件都将是可发布的。因此，我们将工作到一个可发布的结果，并且将工作到一个完整的水平。这会告诉我们，我们是否做完了，不是吗？
因此，持续交付可以说是一种思维方式，它强调应用科学推理来解决软件开发之外的实际问题，这是工程学的核心。为了实现持续交付，我们使用像部署管道这样的工具来集中和托管自动化部署管道，从提交到可发布的结果。我们接受更改，并通过对其运行一大堆测试来尝试并拒绝它。如果在管道传输结束时无法拒绝更改，那么它是可以发布的，无需额外的工作。
持续交付的技术实践集中在三个关键想法：应用科学原理和实验工作，创建一台机器一个部署管道来控制变量并自动化几乎所有事情，以小步骤工作并评估每个提交到发布的步骤的可发布性。持续交付鼓励专注于软件的可测试性和可部署性，这两个方面推动我们创建更模块化的内聚系统，以便更好地关注属性分离和改进。问题分解是管理复杂性的最佳方法，七种基本技术可以帮助我们实现持续交付：缩短周期时间、自动化几乎所有事情、控制变量、以小步骤工作、基于证据的决策、在小型授权团队中工作并将精益和敏捷的原则应用于工作方式。
推荐阅读（点击标题即可跳转）