什么建站程序好收录,如何将自己做的网站导入淘宝,设计师国外网站,wordpress 无所不能阿里妹导读#xff1a;代码分支模式的选择并没有绝对的正确和错误之分#xff0c;关键是与项目的规模和发布节奏相匹配。阿里协同研发平台在经过众多实践历练后#xff0c;总结出了一套独创的分支管理方法#xff1a;AoneFlow#xff0c;通过兼备灵活高效与简单实用的流程… 阿里妹导读代码分支模式的选择并没有绝对的正确和错误之分关键是与项目的规模和发布节奏相匹配。阿里协同研发平台在经过众多实践历练后总结出了一套独创的分支管理方法AoneFlow通过兼备灵活高效与简单实用的流程保障阿里旗下众多产品的交付。下面让我们一起来深入了解。 引言 在阿里内部流行着许多有意思的工程实践。有些实践通过工具和流程嵌在集团的大环境里外界不容易复制有些实践则是流露在大家的日常习惯里被默默的遵守。比如分支管理这件事其实属于工具和习惯各占一半并且颇有阿里特色的成分适合作为一个例子。阿里有很多的研发团队不同事业部使用的发布流程、分支策略并非整齐划一但总体上看是比较规整的。其中有一种主流的发布模式以及对应的分支使用方式称为“AoneFlow”。这套工作模式思路独特在阿里以外的地方并不多见。本文围绕这些实践聊一聊分支管理的话题。 细数分支模式 说到分支管理模式我们最耳熟能详的莫过于 TrunkBased 和 GitFlow。 TrunkBased 模式是持续集成思想所崇尚的工作方式它由单个主干分支和许多发布分支组成每个发布分支在特定版本的提交点上从主干创建出来用来进行上线部署和 Hotfix。在 TrunkBased 模式中没有显性的特性分支。当然实际上 Git 的分布式特征天生允许每个人有本地分支TrunkBased 也并非排斥短期的特性分支存在只不过在说这种模式的时候大家通常都不会明确强调它罢了。 虽然近年来有许多不错的案例但 TrunkBased 模式并没有一统天下。太多的团队同时工作在主干上到发布的时候就可能出现灾难尤其是多版本并行开发的情况。弥补的措施是 FeatureToggle 以及频繁的集成和足够的测试覆盖这对开发团队的能力提出了比较高的要求。目前 TrunkBased 模式主要用在不需要同时维护多个历史版本的 SaaS 型项目特别是经过微服务改造的各种小型服务上。 TrunkBased 模式有两种常见演进版本。OneFlow 模式参考了 TrunkBased 的许多思想对操作流程做了更严格的定义增加了 Hotfix 分支等内容。多主干模式通常是双主干固定的开发分支和固定的发布分支算是 TrunkBased 采用固定发布分支的特例。 GitFlow 模式是若干模式的集大成者包含一个主干分支、一个开发分支、许多的特性分支、许多的发布分支和 Hotfix 分支以及许多繁琐的合并规则。它有一个 Git 插件不过早就没人维护了。由于对每个阶段的每项操作定义十分明确它曾经是很多重视流程的企业眼里的香馍馍。但它使用起来并不是很容易大量的合并冲突和对集成测试不友好也是它被诟病最多的地方。 对还有 GithubFlow 模式不过这种策略无非是在 TrunkBased 的基础上增加了个人仓库和 Pull Request 合并代码的操作与在同一个仓库里增加个人分支的做法类似从实用的意义来说它更合适分布式团队。GithubFlow 也有演进版本例如强调了多环境部署和将仓库或分支与环境关联的 GitlabFlow 模式。 当然代码分支模式的选择并没有绝对的正确和错误之分关键是与项目的规模和发布节奏相匹配。 另辟蹊径的 AoneFlow 在 AoneFlow 上你能看到许多其他分支模式的影子。它基本上兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点同时规避掉 GitFlow 的那些繁文缛节。 看一下具体套路。AoneFlow 只使用三种分支类型主干分支、特性分支、发布分支以及三条基本规则。 规则一开始工作前从主干创建特性分支。 AoneFlow 的特性分支基本借鉴 GitFlow没有什么特别之处。每当开始一件新的工作项比如新的功能或是待解决的问题的时候从代表最新已发布版本的主干上创建一个通常以feature/前缀命名的特性分支然后在这个分支上提交代码修改。也就是说每个工作项可以是一个人完成或是多个人协作完成对应一个特性分支所有的修改都不允许直接提交到主干。 image 规则二通过合并特性分支形成发布分支。 AoneFlow 的发布分支设计十分巧妙可谓整个体系的精髓。GitFlow 先将已经完成的特性分支合并回公共主线即开发分支然后从公共主线拉出发布分支。TrunkBased 同样是等所有需要的特性都在主干分支上开发完成然后从主干分支的特定位置拉出发布分支。而 AoneFlow 的思路是从主干上拉出一条新分支将所有本次要集成或发布的特性分支依次合并过去从而得到发布分支。发布分支通常以release/前缀命名。 image 这条规则很简单不过实际的玩法就相当丰富了。 首先发布分支的用途可以很灵活。基础玩法是将每条发布分支与具体的环境相对应比如release/test分支对应部署测试环境release/prod分支对应线上正式环境等等并与流水线工具相结合串联各个环境上的代码质量扫描和自动化测试关卡将产出的部署包直接发布到相应环境上。进阶点的玩法是将一个发布分支对应多个环境比如把灰度发布和正式发布串在一起中间加上人工验收的步骤。高级的玩法呢要是按迭代计划来关联特性分支创建出以迭代演进的固定发布分支再把一系列环境都串在这个发布分支的流水线上就有点经典持续集成流水线的味道了。再或者做一个将所有特性分支都关联在一起的发布分支专门用于对所有提交做集成测试就玩出了 TrunkBased 的效果。当然这些花哨的高级玩法是我臆想的阿里的发布分支一般都还是比较中规中矩。 其次发布分支的特性组成是动态的调整起来特别容易。在一些市场瞬息万变的互联网企业以及采用“敏捷运作”的乙方企业经常会遇到这种情况已经完成就等待上线的需求随时可能由于市场策略调整或者甲方的一个临时决定其中某个功能忽然要求延迟发布或者干脆不要了。再或者是某个特性在上线前发现存在严重的开发问题需要排除。按往常的做法这时候就要来手工“剔代码”了将已经合并到开发分支或者主干分支的相关提交一个个剔除出去做过的同学都知道很麻烦。在 AoneFlow 的模式下重建发布分支只是分分钟的事将原本的发布分支删掉从主干拉出新的同名发布分支再把需要保留的各特性分支合并过来就搞定。这一系列动作能够在很大程度上实现自动化而且不会在仓库留下一堆剔除代码的记录干净无污染。 此外发布分支之间是松耦合的这样就可以有多个集成环境分别进行不同的特性组合的集成测试也能方便地管理各个特性进入到不同环境上部署的时机。松耦合并不代表没有相关性由于测试环境、集成环境、预发布环境、灰度环境和线上正式环境等发布流程通常是顺序进行的在流程上可以要求只有通过前一环境验证的特性才能传递到下一个环境做部署形成漏斗形的特性发布流。阿里有统一平台来自动化完成特性组合在发布分支间的迁移在下面讲工具的部分里会再介绍。 规则三发布到线上正式环境后合并相应的发布分支到主干在主干添加标签同时删除该发布分支关联的特性分支。 当一条发布分支上的流水线完成了一次线上正式环境的部署就意味着相应的功能真正地发布了此时应该将这条发布分支合并到主干。为了避免在代码仓库里堆积大量历史上的特性分支还应该清理掉已经上线部分特性分支。与 GitFlow 相似主干分支上的最新版本始终与线上版本一致如果要回溯历史版本只需在主干分支上找到相应的版本标签即可。 image 除了基本规则还有一些实际操作中不成文的技巧。比如上线后的 Hotfix正常的处理方法应该是创建一条新的发布分支对应线上环境相当于 Hotfix 分支同时为这个分支创建临时流水线以保障必要的发布前检查和冒烟测试能够自动执行。但其实还有一种简便方法是将线上正式环境对应的发布分支上关联的特性分支全部清退掉在这个发布分支上直接进行修改改完利用现成的流水线自动发布。如果非得修一个历史版本的 Bug 怎么办呢那就老老实实地在主干分支找到版本标签位置然后从那个位置创建 Hotfix 分支吧不过由于阿里的产品大多是线上 SaaS 业务这样的场景并不多见。 正是这些简单的规则组成了 AoneFlow 独树一帜的核心套路。 AoneFlow 中每一个看似简单的步骤都并非凭空臆造而是经历大量产品团队反复磨砺后积累下来的经验。接下来我会说说 AoneFlow 的技术门槛以及阿里内部的应对之道。 AoneFlow 的体验优化 谙熟武侠之道的人都懂得掌握一个门派的看家武艺除了要会招式还得有深厚的内功和趁手的兵器。否则拿了辟邪剑谱也只能望谱兴叹。 阿里团队的内功和兵器实际上是良好的代码习惯和齐全的配套工具。 这里说的习惯除了开发流程和代码分支的管理方式以外还包括日常开发中的一些约定俗成的规约。阿里的许多开发规约是有“文献”记载的主要收录在 《阿里巴巴 Java 开发手册》 里面。它的内容现在已经公开了所以早就不算是秘密。 注在阿里技术公众号回复“手册”即可免费下载《阿里巴巴 Java 开发手册》 举一个具体的例子。在 AoneFlow 的流程中每次重建发布分支的时候都会重新合并然后编译代码产生新的部署包。然而即使代码的内容是一样的如果工程中依赖了一些会改变的第三方软件包依然可能导致打包出的产品行为不完全一致。因此在阿里的代码规约中就明确地指出了用于线上发布的代码不可以使用包含“SNAPSHOT 版本”即未正式发布版本的依赖包从而确保每次构建出的产物都是一致的。类似这样的细节还有很多好的开发习惯是确保软件质量的必要前提。 工具可以使得团队协作更加平滑。虽然只要弄懂原理AoneFlow 中每个分支创建、合并、更改步骤使用单纯的 Git 命令就能玩转。但其中的一些操作比如为每个发布分支选出恰当的特性分支组合进行合并手工执行极易出错而且让团队的个人重复这些日常琐事的命令操作并不是令人愉悦的事情。 在阿里内部使用 AoneFlow 流程的团队基本上不用自己运行 Git 来处理分支的事情而是由阿里巴巴集团内部名叫 Aone 的协同研发平台以下简称平台接管。这个承担集团 80% 产品从需求和用户故事提出到部署上线完整研发流程的平台内置了许多以服务组件的形式嵌入的研发提效工具其中的发布组件为 AoneFlow 的用户体验添色不少。比较显著的辅助“功效”包括以下几个方面。 首先是整体流程的自动化。 由于是内部工具平台的功能高度内聚。对于项目而言从提出原始需求将需求拆分为任务然后根据任务在线创建特性分支再聚合生成发布分支同时根据模板自动创建测试环境直到后期的运维保障都可以一站式地搞定。 这个流程已经远远超出了代码分支管理的范畴。但正是因为如此平台对于 AoneFlow向前做到了将特性分支和需求项关联起来确保了特性分支的命名规范性向后做到了将发布分支与部署行为关联起来确保了各环境版本来源的可靠性。打通了端到端交付的任督二脉。 其次是发布分支的流水线。 作为一种流程自动化的手段CI/CD 流水线是许多现代交付团队中常见的标配实践。在 AoneFlow 的代码生命周期里涉及许多分支当这些分支被创建或更新时往往需要伴随其他的一系列行为。流水线能够将这些日常开发过程中的代码分支与其所表达的深层意图比如提交代码即进行集成测试联系起来。特别是发布分支AoneFlow 的每个发布分支通常关联具体的部署环境当有新代码合并进分支时就应该及时对代码进行检查和部署。 理想情况下每条不同的分支都应该有与其作用相匹配的一条流水线来为它服务。AoneFlow 的发布分支是相对固定的因此相比 GitFlow 更易于进行持续集成。理论上任何流水线工具都能够配合 AoneFlow 使用不过阿里的统一平台提供流水线对代码评审、安全检查、在线部署等功能的整合还是为 AoneFlow 在内部团队的使用优化增色不少。 还有一项很有用的辅助是分支关联的管理。 特性分支与发布分支的关联关系维护是一个 AoneFlow 特有的问题。记住每个发布分支分别来自哪些特性分支对于需要基于现有特性组合进行改变的时候十分有意义。比如当需要将某个特性从特定发布分支退出时通常会将除了该特性以外的其他特性所在分支进行一次合并以替换原有的发布分支。人为地记录这些信息并不轻松要是通过平台进行展示和辅助就会方便许多。 当某些功能组合在一个低级别的发布环境如集成测试环境验证完成后我们希望将它的内容直接迁移到高级别的环境如预发布环境对应的发布分支上。这样可以确保线上的版本一定是经过预发验证的预发的版本一定是经过集成验证的以此类推使得各个发布分支形成串联。同样的使用普通的 Git 命令就能实现这个操作只不过用可视化工具会让流程更加直观。 除此以外平台提供代码仓库各个分支状况的统一展示包括分支所对应部署环境的机器信息、操作记录等全都一览无余。正是这些“高附加值”的辅助使得 AoneFlow 得以扬长避短成为阿里团队支撑复杂项目首选的利器。 写在最后 代码分支模式的选择并没有绝对的正确和错误之分关键是与项目的规模和发布节奏相匹配。阿里协同研发平台在经过众多实践历练后总结出了一套独创的分支管理方法通过兼备灵活高效与简单实用的流程保障阿里旗下众多产品的交付。当你还在犹豫于琳琅满目的分支模式既舍不得 GitFlow 的并行特性开发又放不下 TrunkBased 的持续集成友好时AoneFlow 也许是一个值得考虑的选择。
