持续交付，可以创造更好的软件
乔梁约 6 分钟对于大多数软件开发组织而言，持续交付是一项根本性的变革。它在软件交付的几乎每一个方面都挑战传统思维，而在更广泛的业务层面上，实现这种规模的变革比起它们开始交付的技术背景来说，更为重要。
作为持续交付的倡导者，我,《持续交付2.0》的作者，将会描述这些变革最终将比它们开始交付的技术背景更广泛。
我们最初的目标很简单：优化我们的交付过程，以便于将一个想法尽可能快速、高效和可靠地送到使用者手中。然而，在实践中，这是一个极具挑战性的目标。因为这牵涉到软件开发的几乎每一个方面，我们需要考虑技术变革如何影响我们设计、开发和发布软件的方式。我们还需要考虑组织变革，我们需要更广泛地构建我们的开发组织和组织结构，以便在更多的工作分工中拥有更大的自主权。此外，我们还需要从文化表现的角度来考虑如何在这些类型的组织中进行问题解决和决策的纪律和严谨性。
当我们开始做出这样的变化时，所有这些事情都是具有挑战性和困难的。稳定性和成果规则使我们能够衡量产出的质量和交付产出的效率，这些是决定团队绩效的基本概念。
为了评估技术变革、组织变革和文化变革，我们需要善于利用各种机会进行衡量，这样我们就可以获得有效的高质量、频繁的反馈。
如何提高稳定性和吞吐量？如何提高开发过程的效率并提高输出质量？我认为首先要考虑的是建立一致的度量方法。持续交付中的关键思想之一是部署管道的概念，它从提交到可发布的结果，是衡量该方法效率的完美理想场所。我们可以在各种检查和过程中构建，但我们也可以跟踪效率以实现变革。基于这些指标实现变革的质量是一个强大的想法，因为快速反馈意味着我们清楚我们所处的位置。
假设一个传统组织正在进行软件开发。我们想象一下，这个组织中有一个大型遗留系统，采用广泛的手动测试方法，每个版本都需要很多人或大量时间和精力来验证。在我的经验中，所有这些都是相当自然地发生的，特别是在大型组织中。这种方法的结果通常是正常的，当然，在生产中出现的错误也是常态。无论是什么领域，大多数这样工作的组织在生产环境中都会有相当多的错误。他们正在努力解决这些问题。根据 DevOps 状态报告中得到的反馈，实践持续交付的组织在生产中出现的故障更少，并且他们花在修复上的时间也减少了。
这意味着，平均而言，在这些实践中表现良好的团队比我们传统组织的团队多了44%的时间，可以开发新功能。因为，传统组织如果希望每六个月发布一次，实际上他们的周期可能接近12个月，因为在大多数组织中，新想法和新功能的规划是一个重要的过程。
我们经常对交付的效率感到自责，但如果你从整个软件开发想法的产生来看，这些想法在达到开发团队之前，往往需要花费几个月甚至几年的时间来酝酿。
作为一个软件开发过程的关键点，当我们开始为这样的传统组织工作时，我们应该采取什么措施来尝试和提高系统的稳定性和吞吐量呢？我们可以做的第一件事是建立一个基线来衡量这些方面。因此，我们需要尝试并找出我们当前的衡量指标，包括我们的稳定性和吞吐量，然后，这将为我们提供一个机会来确定我们是否正在随着我们的技术、文化或组织的变化而进行改进。
（图片来源于网络）
一个好的起点可能是进行一些价值流分析。设想一下，我们对生产系统进行只有一行代码的变更，并想象这行代码被验证，并以正常方式走过整个开发与发布过程的每个阶段，就像对软件开发过程进行痕迹分析一样。其中，我们要特别注意的是，一些瓶颈和一些较慢的点，或更昂贵的活动，它们发生在哪里。然后你可以识别这些瓶颈，并尝试找出加速它们的方法。可以采用基于试验性证据方法来尝试弄清楚如何才能消除瓶颈，并开始工作。
通常，在大型组织中，你需要同时进行多个方面的工作，但始终使用稳定性和吞吐量来尝试和衡量变更的影响，使这些演变成为一系列小步骤，而不是需要几个月才能完成的宏伟计划。
一个好的起点是考虑尽可能地减少手工测试，直到根本无法再减少为止。手工测试总是很费力、昂贵、容易出错，因为人类不擅长重复性、反复做同样的事情，这是一种滥用。对于人类来说，这是一项痛苦的工作，本质上是要求一个机器人按照脚本进行一些手动测试，所以我们想尝试并使用一些强大的技术来消除这种情况。有一些强大的技术让我们能做到这一点。
另一个经常需要考虑的关键地方是：开始考虑如何在规划阶段就减少管理费用，尤其是在大型组织中。因为在这些组织中，软件开发已经长出了一种制度性板结组织。你会发现，规划活动需要组织中非常有经验的非常高级的人付出巨大的努力，但往往没有发挥什么实际优势，因为通常他们在这个阶段只是提出计划，还没有完成呢。
所以我们可以应用敏捷计划技术来减少他们的开销，并从定期的大规模计划方法上转移到更频繁的更小规模且更本地化的计划方法。这是组织变化之一，也是提高功能效率的非常常见的方法。
还有一个需要考虑的是：提高整体的测试自动化，并不是取代手动测试，而是开始能够从使用文本作为可执行规范的自动化测试和作为数据规程的一部分的持续集成来驱动软件开发。
我们可以考虑使用自动化配置管理和部署。这是因为我们需要管理自动化测试基础设施，并更快地获得反馈。然后，我们还要开始考虑我们的部署流水线的范围，以及是什么构成了可发布软件单元。
也许我们可以进一步模块化我们的软件，或投资于软件工程基础设施，以获得足够的推动力，来实现持续交付的快速反馈。所有这些做法都是通过提高反馈渠道的速度来实现的。
因此，如果能遵循我之前提供的建议，专注于速度，每天可以多次尝试编写可发布的软件，并发布它，我们就能在所有方面都以良好的工作行为来驱动。让一个没有遵循敏捷思维、DevOps思维、精益思维和持续交付原则的复杂系统，在一个小时内为生产环境准备出可发布软件，这是几乎不可能的事，很难想像出来。
所有这些原则都是基于快速高质量反馈的想法。如果你听取了我的建议，并尝试应用实验性的方法来加快速度并提高反馈质量，来推动改变你从部署系统中获得的东西，以便每天可以多次获得可发布的软件单元，那么，你会发现，如果团队规模太大，就不可能做到这一点。团队可能无法有效地协作来实现这一点。在团队之间存在紧密耦合的情况下，你不可能在需要管理的地方实现这一点。如果没有良好的软件体系结构和部署、配置管理，就无法真正实现这种非常快速的高质量反馈。这些可能都是先决条件。
非常重要的是，它允许我们使用很多工具来推动这些更好的组织行为。在大型组织中一下子实现这种改变是不可能的。好消息是，你不需要在持续交付的旅程中一次对所有步骤都改进。请相信我，仍然有一些组织在使用版本控制这方面存在问题。所以，最先进行的就是做好版本控制。 同样地，如果你没有实施持续集成，那么现在开始吧，这也是一种改进。部署自动化基础设施也同样重要。
所有这些东西都代表着一种改进。你不必一步完成所有这些，但逐步改变是持续完整性改进方法的基本部分，这是持续交付的核心。
推荐阅读（点击标题即可跳转阅读）