关于阿里云:阿里巴巴基于应用和变更的交付模式｜阿里巴巴DevOps实践指南

编者按：本文源自阿里云云效团队出品的《阿里巴巴 DevOps 实际指南》，扫描上方二维码或返回：https://developer.aliyun.com/…，下载完整版电子书，理解阿里十年 DevOps 实践经验。

让咱们进入到阿里巴巴在交付阶段的一些实际，包含：

• 以利用和变更为外围的交付流程
• 基于变更的查看项和卡点
• 针对利用特征选择研发模式

利用与变更

进入到具体的实际之前，咱们先介绍下阿里巴巴的利用和变更模型。

利用，是研发流动的载体，包含了代码库、部署环境、配置项、变更治理、公布流水线、运维等一系列因素。整个需要的开发交付过程都能够在利用中实现。利用上能够设置不同的角色，这些角色信息在研发的各个环节中会起到作用。比方谁能公布线上环境，谁有权限批改测试配置等。

变更 ，作为利用的重要组成部分，是一个形象的概念。所有对线上的行为的批改都能够称之为变更，变更属于某一个利用。变更中能够蕴含一个或者多个不同类型的变更内容，最常见的变更内容类型就是代码变更。

变更有相应的生命周期，一个典型的变更生命周期为：开发中 -> 公布中 -> 实现。当一个利用有多个变更同时在开发和公布时，须要有肯定的协调机制，比方是在一个长期的集成分支上进行集成，还是在一个常驻的 develop 分支上进行集成。咱们称这种分支合作模式为“研发模式”。

创立变更通常是为了实现需求和修复缺点。一个需要可能须要批改多个利用，也就是须要在多个利用上创立变更，而简略的缺点修复可能批改一个利用就能够解决问题，也就是一个变更。所以工作项（需要和 bug）和变更是一对多的关系。

咱们从两个视角来看一下：

• 利用部署视角：每次利用部署上线会蕴含一个或者多个该利用的变更，可能波及多个工作项。
• 工作项公布视角：一个工作项的公布可能须要多个利用的先后部署。
• 这两个视角是有穿插的。作为平台和工具，应该更关注哪个视角呢？
• 如果偏利用，则要实现一个工作项的公布，开发团队须要自行协调多个利用的部署程序，会产生肯定的沟通老本。
• 如果偏工作项，则会呈现一个工作项的一组变更在部署某个验收环境，其余的工作项的变更须要期待，影响了整体交付吞吐率。
• 如果想要兼顾这两个视角，则不可避免的须要应用大版本制，或者叫火车制，拉长了单工作项的交付周期。

阿里巴巴的 DevOps 工具抉择偏利用的视角，次要保障单个利用的部署上线流程和品质，将部署的节奏交给开发团队灵便安顿。

比方一个工作项的公布波及三个利用的三个变更，这个工作项的开发能够抉择在周一部署第一个变更，周二部署第二个变更，而这两个变更不会造成任何线上可见的批改；到了周四，产品心愿该性能上线时，再部署第三个变更，需要正式公布。这种将部署利用行为与公布性能行为拆散的模式，能够升高集中部署带来的危险。当然可能这样做的前提是须要有比较完善的自动化品质保障及卡点机制。

基于变更的查看项和卡点

变更是交付的载体，因而能够通过在变更上承载查看项来保障交付品质。最常见的查看项包含：

• 是否通过代码评审
• 是否通过平安扫描
• 是否通过单元测试 /UI 测试

基于这些查看项会进行品质卡点，个别在如下的生命周期节点上：

• 从开发中进入公布中：须要满足肯定的质量标准（比方单元测试通过率，覆盖率等）之后，才容许进入到公布中的状态，能进入测试环境进行验证。
• 公布到某个环境上：这时变更曾经进入了集成流水线，实现了构建等，但如果要持续部署到某个环境，须要满足更多的验证条件。比方平安审核须要通过，能力公布正式等。

至于在哪些节点设置哪些卡点，利用负责人能够自行决定。多个查看项倡议尽早同时开始，以提高效率。

从另一个角度来看，公布平台也能够对所有利用进行全局的卡点设置，针对某些卡点主动开启，且不容许勾销。比方扫描到你的代码中依赖了有平安问题的 JAR 包，则要求必须进行修复，否则无奈部署上线。这样就能够管制一些全局性的危险。

变更和利用中的公布流水线，提供了一个进行检查和卡点的框架。具体的查看工作由其它的专门的平台提供，比方测试平台、平安扫描平台、与特定业务相干的合规扫描等。

研发模式

如前文提到，为了可能让一个利用的多个变更协同开发和公布，咱们须要采纳不同的研发模式。研发模式的次要差异在分支合并策略，目前阿里巴巴次要采纳上面三种研发模式：

• 骨干模式
• Aone-Flow 分支模式
• Git Flow 模式

利用有大有小，在其上进行需要开发的并行度也不雷同。

阿里巴巴有大量的的利用没有并行进行的变更公布。这类利用适宜应用骨干模式或者 Git Flow 模式。也有一些利用变更的并发度比拟高，会呈现一些公布节奏不同的问题。业界个别应用性能开关的形式解决这个问题。阿里外部采纳名为 Aone-Flow 的分支模式来解决。

在 Aone-Flow 的分支模式下，开发人员的典型工作流程为：

1. 提交变更，Aone-Flow 会创立一个集成分支，或者复用已有分支，主动将你的变更合并到这个集成分支。
2. 当你发现你的变更有问题不能公布，能够“退出公布”，Aone-Flow 会主动创立一个新的集成分支，把残余的须要持续公布的变更再合并进去。
3. 当集成分支实现正式部署之后，会合并到 master 骨干上。这个集成分支上的变更都会被标记“已实现”，并打上 Git Tag。
4. 当须要回滚时，能够依据零碎的记录同时将线上的版本和代码一起回滚掉（git revert）。避免出现无心把有问题的 master 代码公布上线的状况。

对于 Aone-Flow 的详细描述能够参看：https://www.infoq.cn/article/EaC4c6yiJrzZ_Gtaf9Ne

这里仅就骨干模式和 Aone-Flow 进行一个简略的比照。

能够看到骨干模式和 Aone-Flow 各有利弊。在阿里巴巴，为了可能更加疾速独立的交付个性，有一多半的团队采纳了 Aone-Flow。

总结

理解了上述的过程，以 Aone-Flow 为例，咱们对一个需要的上线过程要通过的阶段进行一个图解：

这里只画了日常、预发和正式三个环境，在理论的流程中，还会有灰度，平安生产环境等，来尽量避免呈现线上问题和故障。

另外在变更的开发阶段，阿里外部还采纳了一些隔离测试环境的技术来帮忙开发者进行个性级别的隔离测试联调，详见前序的隔离测试环境章节。通过上述的管控和流程，咱们就失去一个比拟平安的需要交付流程。

【对于云效】

云效，云原生时代一站式 BizDevOps 平台，反对公共云、专有云和混合云多种部署状态，通过云原生新技术和研发新模式，助力翻新守业和数字化转型企业疾速实现研发麻利和组织麻利，打造“双敏”组织，实现 10 倍效力晋升。

立刻体验