《必致(BizDevOps)白皮书2022》——04必致(BizDevOps)实践案例——4.2 案例二:阿里巴巴,以应用为核心打造持续业务交付能力

简介: 《必致(BizDevOps)白皮书2022》——04必致(BizDevOps)实践案例——4.2 案例二:阿里巴巴,以应用为核心打造持续业务交付能力

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

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


业务特点和组织架构

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


image.png


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


image.png


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


image.png

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


管理应用的研发资产

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

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

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


创建应用

image.png


管理应用代码库

image.png


管理应用环境

image.png


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

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

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

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


定义应用的研发变更流程

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

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

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

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

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

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


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

image.png


配置阶段的变更卡点


image.png


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


变更的开发、集成、交付

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

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

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

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


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

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


image.png


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


基于业务看技术


image.png


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

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

务。


image.png


基于技术看业务

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


目录
相关文章
|
11月前
|
运维
《必致(BizDevOps)白皮书2022》——01必致(BizDevOps)的目标、 能力和实践——1.2 BizDevOps的3个能力要求
《必致(BizDevOps)白皮书2022》——01必致(BizDevOps)的目标、 能力和实践——1.2 BizDevOps的3个能力要求
161 0
|
11月前
《必致(BizDevOps)白皮书2022》——01必致(BizDevOps)的目标、 能力和实践——1.3 BizDevOps的5个关键实践
《必致(BizDevOps)白皮书2022》——01必致(BizDevOps)的目标、 能力和实践——1.3 BizDevOps的5个关键实践
139 0
|
11月前
《必致(BizDevOps)白皮书2022》——01必致(BizDevOps)的目标、 能力和实践
《必致(BizDevOps)白皮书2022》——01必致(BizDevOps)的目标、 能力和实践
97 0
|
11月前
|
运维 Devops
《必致(BizDevOps)白皮书2022》——01必致(BizDevOps)的目标、 能力和实践——1.1 BizDevOps的1个总体目标
《必致(BizDevOps)白皮书2022》——01必致(BizDevOps)的目标、 能力和实践——1.1 BizDevOps的1个总体目标
136 0
|
11月前
|
持续交付
《必致(BizDevOps)白皮书2022》——03必致(BizDevOps)实践体系——3.1 BizDevOps实践的总体介绍
《必致(BizDevOps)白皮书2022》——03必致(BizDevOps)实践体系——3.1 BizDevOps实践的总体介绍
152 0
|
11月前
|
数据可视化 持续交付
《必致(BizDevOps)白皮书2022》——03必致(BizDevOps)实践体系——3.2 协作和管理领域的实践(下)
《必致(BizDevOps)白皮书2022》——03必致(BizDevOps)实践体系——3.2 协作和管理领域的实践(下)
135 0
|
11月前
|
持续交付
《必致(BizDevOps)白皮书2022》——03必致(BizDevOps)实践体系——3.2 协作和管理领域的实践(上)
《必致(BizDevOps)白皮书2022》——03必致(BizDevOps)实践体系——3.2 协作和管理领域的实践(上)
210 0
|
11月前
|
大数据 持续交付
《必致(BizDevOps)白皮书2022》——03必致(BizDevOps)实践体系——3.3 度量和改进实践
《必致(BizDevOps)白皮书2022》——03必致(BizDevOps)实践体系——3.3 度量和改进实践
369 0
|
11月前
|
运维 Cloud Native 测试技术
《必致(BizDevOps)白皮书2022》——03必致(BizDevOps)实践体系——3.3 工程和技术领域的实践
《必致(BizDevOps)白皮书2022》——03必致(BizDevOps)实践体系——3.3 工程和技术领域的实践
236 0
|
11月前
|
敏捷开发 运维 Cloud Native
《必致(BizDevOps)白皮书2022》——04必致(BizDevOps)实践案例——4.1 案例一:迈向BizDevOps的 招商银行精益管理体系
《必致(BizDevOps)白皮书2022》——04必致(BizDevOps)实践案例——4.1 案例一:迈向BizDevOps的招商银行精益管理体系
557 0