3.3 工程和技术领域的实践

BizDevOps在工程和技术领域的核心目标是：建设组织的技术工程体系，保障并持续提升业务的持续响应和交付能力。

为此需要关注：

图3-9：BizDevOps模型的技术和工程部分

在BizDevOps概念模型中，我们把工程和技术域分成两个2个核心域⸺应用管理和变更域，业务发布域。

1.应用管理和变更域

变更请求是这个域的核心作业对象，它指的是为实现特定的产品需求或修复缺陷，应用所要做的变更。变更请求的实现是从设计、编码、提交、测试直至部署的完整过程。变更请求和应用这两个概念，后续会给出完整定义。

应用管理

和变更域的目标是：以应用为核心，有效聚合和管理研发资产，定义和管理应用的变更流程，保障对变更请求的持续响应和持续部署。

2.业务发布域

（系统或版本的）发布是这个域的核心作业对象。一个发布通常是基于发布计划生成，并按发布单元所定义的集成发布流程，完成多个变更请求的集成、验证和对外发布。关于发布和发布单元，后续会给出完整定义。

业务发布域的目标是：适配业务特征定义和管理业务的集成发布流程，制定发布计划，保障高效、高质量和持续的业务响应和交付。

以上两个域，分别对应两个关键实践：

图3-10：OAM模型*（来源https://github.com/oam-dev/）定义了应用的声明方式，并以应用打通部署、应用运维和基础设

运维

接下来的两节将分别介绍这两个实践。

应用为核心的研发资产和流程管理

在数字化进程中，保障和持续提升业务交付能力，是企业核心挑战之一。交付能力的提升是一个持续的过程，需要全链路上各个角色的高效协同。而在云时代，“应用（Application）”是工程上打通各个角色协作的关键，开发、测试和运维的工作都应该围绕应用展开。

应用是云原生环境下最基本的部署单元和运维对象，它由1到多个组件构成，运行在特定的基础设施之上，对外部提供服务或功能。应用拥有自己的代码、配置和数据，可以被单独变更、部署。应用之间应该是松耦合的。关于应用的管理，本白皮书承接了OAM (Open Application Model，开放应用模型)模型标准。OAM模型认为应用是开发者、应用运维、基础设施运维的共同的工作对象，不同环节基于应用拉通并有效协作，成为一个高效工作的整体。

图3-10：OAM模型*（来源https://github.com/oam-dev/）定义了应用的声明方式，并以应用打通部署、应用运维和基础设施运维

如上图所示，OAM模型中应用的声明定义了应用的部署组件、发布策略、运维策略等。BizDevOps将应用管理的范围延伸到研发阶段，这样在OAM打通部署、应用运维和基础设施运维的基础之上，进一步向前打通应用的开发环节。 为此，应用应该：

应用响应来自外部的工作请求，我们称其为变更请求。上图表达了变更请求在工程活动中的位置。对外，变更请求承接了产品需求针对某个应用的所有需要进行的技术活动；对内，变更请求归属于特定的应用，遵循应用所定义的研发变更流程，并以统一的流程聚合开发、集成、测试、部署等技术活动。

变更请求：为实现特定的产品需求或修复产品中的缺陷，某个应用所需要完成的工作。变更请求的实现，是包含设计、编码、提交和部署等在内的完整过程。与分散的技术任务不同，变更聚合了为响应特定产品需求，应用上所发生的所有技术活动。

如下图所示，在BizDevOps模型中，我们将创建变更请求作为工程和技术活动的起点，而变更请求则遵循应用所定义的变更流程，聚合包括设计、编码、测试、部署等在内的研发活动。这一机制打通了从需求协作到工程部署的链路，持续改进变更流程的效率和质量是工程效能的基本保障，也是高效业务发布的基础。

以应用为核心聚合和管理研发资产，定义、管理并持续改进应用的变更流程，实现对（来自业务和产品 的）变 更 请 求 的 持 续 响 应 和 持续部署，它是BizDevOps中工程交付效能的基本保障。

适配业务特征的持续业务交付

图3-12：BizDevOps概念模型中关于业务发布和交付的部分

BizDevOps实践的最终目的是提升业务交付能力。在工程和技术上，业务交付体现为版本或业务的持续发布。

发布是指：按照一定的流程，将某个发布单元（如产品和系统）中开发完毕的功能，分发到目标环境中，并使之对外部可见和可用的过程。

发布具备如下特征：

• 发布由发布计划生成，发布计划通常源自业务的版本规划，它规定发布的业务内容，如：包含哪些业务或产品需求，缺陷修复等

• 发布是针对某个发布单元的。发布单元可以是单个应用，也可以是一组应用的组合而成的产品、系统等

• 每次发布通常会发布一系列开发完毕的变更请求，这些变更请求都属于发布单元所涉及的应用

• 发布要遵循发布单元定义的集成发布流程。发布流程通常由流水线承载，如：集成阶段流水线、发布阶段流水线等，这些流水线可以被编排而成为整体的发布流程，并生成发布的制品

发布：可见和可用的过程。 指将开发完成的功能，分发到目标环境，并使之对外

发布单元：是发布的最小粒度，它可能是单个应用，或有多个应用组成的产品和系统。发布单元下的变更请求需要一起集成、验证、部署后才能共同发布，发布单元定义自己的集成发布流程，以保障发布的可控性和质量。

图3-13：业务交付的标准过程模型

上图是业务交付的标准过程模型，描述了业务交付中涉及的概念和流程。其中，一个业务版本包含1到多个业务需求，每个业务需求拆解为1到多个产品需求；产品需求又被拆解为1到多个应用的变更请求；变更请求按所在应用的变更流程开发完毕后，成为发布流程的输入。

发布则是以发布单元为单位的，一个发布单元包含1到多个应用，这些应用中的变更请求必须在一起集成和验证后才能够发布，并生成统一的发布版本。发布需要遵循发布单元所定义的集成发布流程，流程中的步骤可能是自动触发和运行的，如：流水线驱动的自动测试或部署；也可能是手工的，如人工的测试和线下的审批。上面的标准过程模型，并不刻意区分交付是传统的批量交付或敏捷的持续交付，也就是在一些标准中所声称的稳态交付模式和敏态交付模式。我们认为，敏态和稳态并不是泾渭分明的两种方式，而是一个连续的过程，任何业务都有变得更敏捷的权利和需求。

基于上面的标准过程模型，发布模式更偏向批量、强管控的稳态发布，还是灵活和持续敏态发布，主要依赖于下面三个要素：

要素一：发布单元的粒度大小

在稳态模式下，发布单元的粒度通常较大，比如多个应用甚至多个子系统构成发布单元。一个发布单元下的所有变更请求需要联合发布。敏捷的持续发布模式，寻求减小发布单元的粒度，最极致的敏捷状态是单个应用可以作为发布单元单独发布。减小发布单元的粒度也是有前提的，它需要各个发布单元之间的解耦，包括技术上的解耦，各个发布单元可以独立验证，但依然可以保障系统的质量。实现这一点需要持续的工程和技术能力的改进。

要素二：发布的批量大小

在稳态模式下，通常会以大版本的形式成批量的集成、验证和发布，每个版本发布的间隔从数周到数月不等，发布的内容则包含这段时间内积累的所有待发布的需求。敏捷的持续发布模式寻求减小需求发布的批量，最极致的敏捷状态是单需求发布。

减小发布批量并非全无代价。当单次发布的成本较高时，减小发布的批量会带来额外的成本。同时，研发的模式也会制约发布批量的减小，比如：在瀑布研发模式下，需求批量开始和批量完成，批量地发布也就成了自然选择。

要素三：集成发布流程的灵活性和速度高低

集成发布流程指的是发布单元发布前所必须遵循的流程，如：对变更请求的集成、在测试环境上的部署和验证、业务的验收、生产环境的部署、灰度或全量发布，以及相关的检查和审批等。在相对稳态的模式下，集成发布流程通常比较复杂，且耗时长。比如，繁杂的集成工作，过度依赖集成发布阶段的测试来保障质量，大量长耗时的手工工作，各个节点需要严格的人工审批，以及过多的返工和问题排查等。敏捷的持续交付模式，则希望尽量降低集成发布流程的复杂度，缩短发布的耗时。最理想状态下，发布工作能够自动完成，耗时极短（比如在数分钟内完成），并能够保障发布的质量，即使出现问题也能够及时发现和自动回滚。

提高发布的灵活性和效率也是有前提的，它要求我们不断进行质量保障前移，提高待集成制品的质量，减少发布过程中所需要的验证工作，并尽量让发布过程自动化，不断提高这一过程的质量、效率和可观测性。

以上三个要素，在保障交付质量的前提下，共同决定组织的持续交付水平，我们称之为“持续交付的三要素”。持续交付的目标非常直接，那就是持续地交付业务价值。其中，业务价值的载体是业务需求，而持续指的是在需要的时候随时可以交付，而非受制于批量要求、复杂的发布流程、落后工程能力等。

图3-15：按应用部署，按需求发布，发布流程最小化是持续交付的理想模型

上图是持续交付的理想模型，它与前文的标准模型是兼容的，是标准模型下的一个特殊版本。它可以表述为：

达到理想状态固然不易，但在实现上是可行的，卓越级的互联网产品一天能完成几十到几百次发布，通常就是以达到这样的状态为支撑的。然而对于任何组织，持续交付能力都受制于两个方面的因素。

第一个制约因素是业务的特征

例如：客户侧部署的软件产品，就很难做到在生产系统上的持续部署。尽管远程升级、无感知发布等技术降低了发布成本和风险，但与互联网产品相比，持续发布要困难许多。此时，首先应该追求内部版本的持续交付，持续获得质量反馈，并降低客户侧发布的风险，并在此基础上不断降低客户侧交付的成本，为持续交付创造条件。

第二个制约是团队技术和工程能力

例如：如果团队自动化水平低，单次集成和验证的成本过高，此时一味的降低发布的批量是不现实的；技术架构上不能解耦，发布单元间的解耦就无法实现，频繁发布或带来负面影响；应用级别的质量不能保障, 又缺乏全链路的质量验证能力，一味简化集成发布流程，反而可能适得其反，损害质量和效率。

综上所述，持续交付能力体现为高质量持续交付业务价值的能力，持续交付能力的建设是一个渐进的过程。组织的交付模式需要与业务特征相匹配。在此基础上，组织应该不断提升技术和工程能力，在保障质量的前提下，向持续交付的目标迈进。交付模式应该随着技术和工程能力的提高而不断进化，上面的持续交付的理想模型则为进化提供了方向。

适 配 业 务 特 征，定 义 和 管 理 业 务交付流程，保障高效、高质量业务交付的同时, 不断进化持续业务交 付 能 力 。这 是 组 织 打 造 业 务 持续交付能力的目标和努力方向。