4.2 案例二：阿里巴巴，以应用为核心打造持续业务交付能力

在阿里巴巴，以应用为核心的工程交付经过多年的发展，尤其是近两年云原生的推动，已经深入人心。我们以阿里巴巴某个电商中台部门的工程交付为例，介绍一下阿里应用为核心的工程交付实践。

•业务特点和组织架构

中台的特点是业务方众多，需求来源众多，部署环境也非常多。对于一个中台的应用容器，它的内部结构可能是这样的，里面包含来自多个业务方的需求代码，同时又有来自横向中间件、SRE等团队提供的各类非功能性代码，这些代码共同构建组成了中台的服务容器。

在技术架构上，业务研发并不允许直接修改中台应用代码，而是会以扩展点的方式，通过提供二方包给中台应用以集成业务能力。另一方面，中台团队是按照应用划分的，每个应用有唯一的负责团队，这个团队负责该应用的开发、测试、部署和运维。因此，在组织架构上，类似下图所示。

在部署架构上，由于海外电商业务的特点，该应用会部署到多个站点，每个站点使用相同的部署镜像，但有不同的站点配置。这些配置包括：容器配置、弹性配置、中间件配置、业务配置等。

小结一下，对于中台应用，中台研发团队是唯一的负责人，负责维护该应用的全生命周期。业务团队是中台应用的贡献方，会与中台研发团队紧密协作。中间件、安全、云原生等团队是中台应用的依赖方，他们的变更也会影响到中台应用，双方也存在协作。

•管理应用的研发资产

每个应用有唯一的负责团队，因此该团队天然有按应用聚合和管理研发资产的诉求，这里的研发资产包括：角色/权限、代码、

配置、环境、部署编排等。

我们以阿里云云效平台为例，看一下应用是如何创建和管理研发资产的（为避免赘述，以代码和环境为例）。

创建应用

管理应用代码库

管理应用环境

应用是研发团队日常工作的第一入口，也是资源的主要聚合和治理维度，还是团队工程效能度量和分析的主要视角。

• 对应于项目协作的项目，应用是研发团队的作业空间。当研发团队收到某个产品需求后，第一步就是找到需要变更的应用，建立应用变更，分配变更负责人。

• 财务或者基础资源团队进行开发测试所用物理资源盘点时，由于每个资源在CMDB中都标记了所属的应用，因此盘点和治理的时候，也会先聚合到应用，再有应用找到负责团队和更上层的组织。

• 在度量和改进工程效能时，由于应用是团队长期维护和演进的，基于应用可以得到团队研发相关的几乎所有活动事件，因此按应用进行度量可以做到全面、实时、客观。

• 定义应用的研发变更流程

在管理应用的研发资产（静态）的基础上，我们还会在应用上定义和管理应用的研发活动方式（动态），具体表现为应用的研发变更流程。

我们认为应用的研发变更流程有如下几个特点：

1.有明确的源头，常见的如某个代码库的变更分支，该中台应用要求流程从有变更开始。

2.包含多个阶段，每个阶段有不同的分支、流程，且每个阶段可以独立执行，该中台应用包含开发、测试、预发和正式四个阶段。

3.每个阶段有明确的准入和准出，该中台应用要求某个变更进入预发阶段前，必须通过测试阶段的验证且无安全问题。

4.一个应用可以定义多个研发变更流程，该中台应用定义了标准流程和hotfifix流程两个流程，分别用于一般日常需求的开发和紧急bug的修复。一般情况下，只有应用负责人能够修改研发变更流程。还是以云效为例，看下应用的研发变更流程。

在应用上创建研发变更流程

配置阶段的变更卡点

研发变更流程中所产生的各类事件和输出都可以作为变更的元数据，因此，可以基于这些元数据，进行应用的各类治理工作，如二方库的治理、合规治理等。

• 变更的开发、集成、交付

在该中台应用的研发实践中，开发任务等同于变更，对应用的任何变化，都是通过变更交付的。中台应用的每个开发者都可以创建变更，每个变更在创建的时候都需要指定源头，变更的源头可以有多个，可以是需求，也可以是缺陷，无相关工作项的变更是不允许创建的。每个应用变更都对应一个变更分支，开发者可以基于该变更在应用平台上直接拉取新的隔离项目环境。一个隔离项目环境可以理解为该变更独占的一套完整开发测试环境，通过中间件技术既与其它环境在该应用调用链路上隔离，又能在调用依赖应用时连通。

开发者在变更分支上完成代码开发，触发变更的开发阶段执行构建、测试、部署项目环境等，验证通过后，该变更就可以在下一阶段被集成和验证了。

变更的集成验证一般由应用的测试负责，有些团队也会直接由开发进行集成验证。集成验证阶段通常会包含来自多个业务方的变更（以不同的二方包的方式）和中台应用自身的变更。各个变更分支会自动合并，并进行验证。变更的验证大量使用了自动化测试的技术，会通过流量测试等自动化手段快速对应用进行集成验证，只有通过集成验证的变更才能进入交付阶段。如果有变更在集成验证阶段失败，它会从集成的变更列表中移除，通过验证的变更将会进入下一阶段。

变更的发布阶段一般由应用的发布负责人负责，符合发布标准的多个变更会被自动合入发布分支，进行构建和发布前验证，验证不通过的变更会被剔除，剩下的变更会重新执行发布阶段，直至完成所有生产环境的部署。变更部署完成后，变更分支会自动合入主干，并关闭变更，同时通知变更关联的工作项。如果该工作项相关的变更都已经完成，可以设置该工作项的状态自动往下流转。

•从业务看变更、从变更看业务

业务需求、产品需求、技术任务、发布、应用变更，以及变更相关的测试、部署操作，全都可以关联到一起并自动联动和更新。

对于业务团队，可以在业务需求上看到相关产品需求的进展，可以下钻某个产品需求，查看其相关应用变更的状态，及时发现交付的瓶颈，并及早协作，从而做到从业务看技术。

•基于业务看技术

站在业务的角度，可以从业务需求追溯与之相关的所有产品需求，以及为了实现这些产品需求，所涉及的所有应用变更及变更的发布情况。

对于研发团队，可以通过发布追溯到变更，从变更追溯相关的需求，以及为支撑该需求，所涉及的其它应用的变更。通过业务需求到发布的端到端连通，可以有效管理，保证工程技术团队总是聚焦在最重要的业务价值上，避免浪费，也可以促使业、产、技三方有效协同，共同决策和改进。这也使得对业、产、技各方的价值评价得以统一到业务价值这一最重要的目标上，一方面可以基于业务看技术，另一方面可以基于技术看业

务。

•基于技术看业务

站在技术的角度，可以从变更请求追溯其实现的产品需求，以及这些产品需求所承载的业务需求。一个变更请求可以实现多个产品需求，同样，一个产品需求也可以服务于多个业务需求，通过这张关联视图，我们可以很容易地看到他们之间的关系及进展。业、产、技的端到端连接和实时数据共享，还使得对业务的即时监控和反馈成为可能。通过为业务需求定义业务观测指标和预期目标，可以在工程发布的第一时间进行精准的业务监控和预警，并有效融合工程的灰度发布和业务的AB测试，使得技术在服务于业务价值的基础上，加速业务价值的验证，推动业务的创新。