加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 移动互联 > 正文

阿里巴巴如何管理代码分支?

发布时间:2019-08-17 20:22:12 所属栏目:移动互联 来源:林帆
导读:在阿里内部,流行着许多有意思的工程实践。有些实践通过工具和流程嵌在集团的大环境里,外界不容易复制,有些实践则是流露在大家的日常习惯里,被默默的遵守。比如分支管理这件事,其实属于工具和习惯各占一半,并且颇有阿里特色的成分,适合作为一个例子

此外,发布分支之间是松耦合的,这样就可以有多个集成环境分别进行不同的特性组合的集成测试,也能方便的管理各个特性进入到不同环境上部署的时机。松耦合并不代表没有相关性,由于测试环境、集成环境、预发布环境、灰度环境和线上正式环境等发布流程通常是顺序进行的,在流程上可以要求只有通过前一环境验证的特性,才能传递到下一个环境做部署,形成漏斗形的特性发布流。阿里有统一平台来自动化完成特性组合在发布分支间的迁移,在下面讲工具的部分里会再介绍。

规则三,发布到线上正式环境后,合并相应的发布分支到主干,在主干添加标签,同时删除该发布分支关联的特性分支。

当一条发布分支上的流水线完成了一次线上正式环境的部署,就意味着相应的功能真正的发布了,此时应该将这条发布分支合并到主干。为了避免在代码仓库里堆积大量历史上的特性分支,还应该清理掉已经上线部分特性分支。与 GitFlow 相似,主干分支上的最新版本始终与线上版本一致,如果要回溯历史版本,只需在主干分支上找到相应的版本标签即可。

阿里巴巴如何管理代码分支?

除了基本规则,还有一些实际操作中不成文的技巧。比如上线后的 Hotfix,正常的处理方法应该是,创建一条新的发布分支,对应线上环境(相当于 Hotfix 分支),同时为这个分支创建临时流水线,以保障必要的发布前检查和冒烟测试能够自动执行。但其实还有一种简便方法是,将线上正式环境对应的发布分支上关联的特性分支全部清退掉,在这个发布分支上直接进行修改,改完利用现成的流水线自动发布。如果非得修一个历史版本的 Bug 怎么办呢?那就老老实实的在主干分支找到版本标签位置,然后从那个位置创建 Hotfix 分支吧,不过由于阿里的产品大多是线上 SaaS 业务,这样的场景并不多见。

正是这些简单的规则,组成了 AoneFlow 独树一帜的核心套路。

AoneFlow 中每一个看似简单的步骤都并非凭空臆造,而是经历大量产品团队反复磨砺后积累下来的经验。接下来,我会说说 AoneFlow 的技术门槛以及阿里内部的应对之道。

AoneFlow 的体验优化

谙熟武侠之道的人都懂得,掌握一个门派的看家武艺,除了要会招式,还得有深厚的内功和趁手的兵器。否则拿了辟邪剑谱,也只能望谱兴叹。

阿里团队的内功和兵器,实际上是良好的代码习惯和齐全的配套工具。

这里说的习惯,除了开发流程和代码分支的管理方式以外,还包括日常开发中的一些约定俗成的规约。阿里的许多开发规约是有“文献”记载的,主要收录在《阿里巴巴 Java 开发手册》里面。它的内容现在已经公开了,所以早就不算是秘密。

举一个具体的例子。在 AoneFlow 的流程中,每次重建发布分支的时候都会重新合并然后编译代码,产生新的部署包。然而,即使代码的内容是一样的,如果工程中依赖了一些会改变的第三方软件包,依然可能导致打包出的产品行为不完全一致。因此,在阿里的代码规约中就明确地指出了,用于线上发布的代码,不可以使用包含“SNAPSHOT 版本”(即未正式发布版本)的依赖包,从而确保每次构建出的产物都是一致的。类似这样的细节还有很多,好的开发习惯是确保软件质量的必要前提。

工具可以使得团队协作更加平滑。虽然只要弄懂原理,AoneFlow 中每个分支创建、合并、更改步骤使用单纯的 Git 命令就能玩转。但其中的一些操作(比如为每个发布分支选出恰当的特性分支组合进行合并)手工执行极易出错,而且让团队的个人重复这些日常琐事的命令操作,并不是令人愉悦的事情。

在阿里内部,使用 AoneFlow 流程的团队基本上不用自己运行 Git 来处理分支的事情,而是由阿里巴巴集团内部名叫 Aone 的协同研发平台(以下简称平台)接管。这个承担集团 80% 产品从需求和用户故事提出到部署上线完整研发流程的平台,内置了许多以服务组件的形式嵌入的研发提效工具,其中的发布组件为 AoneFlow 的用户体验添色不少。比较显著的辅助“功效”包括以下几个方面。

首先是整体流程的自动化。

由于是内部工具,平台的功能高度内聚。对于项目而言,从提出原始需求,将需求拆分为任务,然后根据任务在线创建特性分支,再聚合生成发布分支,同时根据模板自动创建测试环境,直到后期的运维保障都可以一站式的搞定。

这个流程已经远远超出了代码分支管理的范畴。但正是因为如此,平台对于 AoneFlow,向前做到了将特性分支和需求项关联起来,确保了特性分支的命名规范性;向后做到了将发布分支与部署行为关联起来,确保了各环境版本来源的可靠性。打通了端到端交付的任督二脉。

其次是发布分支的流水线。

作为一种流程自动化的手段,CI/CD 流水线是许多现代交付团队中常见的标配实践。在 AoneFlow 的代码生命周期里涉及许多分支,当这些分支被创建或更新时,往往需要伴随其他的一系列行为。流水线能够将这些日常开发过程中的代码分支与其所表达的深层意图(比如提交代码即进行集成测试)联系起来。特别是发布分支,AoneFlow 的每个发布分支通常关联具体的部署环境,当有新代码合并进分支时,就应该及时对代码进行检查和部署。

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读