项目版本管理的最佳实践：云效飞流Flow篇

目录

一、分支规约

二、版本号规约

2.1 主版本号 首位版本号

2.2 次版本号 迭代号

2.3 小版本号

三、云效飞流Flow的最佳实践 使用阿里云云效

3.1 总体流程图

3.2 弓行同学与阿吉同学的最佳实践

3.2.1 功能分支(feature分支)的创建

3.2.2 流水线的创建

3.2.3 日常环境发布

3.2.4 预发环境发布

3.2.5 危险分支下线

3.2.6 生产环境发布

3.2.7 生产环境发布:写基线

四、FAQ

一、分支规约

二、版本号规约

在最佳实践中 我们常用的版本号为三位数版本号 其构成如下

V主版本号.次版本号.小版本号

eg V1.0.0、V1.5.0、V1.13.1等

2.1 主版本号 首位版本号

主版本号 也叫首位版本号、顶位版本号 即V后第一个版本号。主版本号一般代表项目的期数与产品方向。除非项目合同改变、大规模api不兼容、产品方向改变、底层架构升级等情况外不轻易更新。

另外 项目未正式发布、未正式孵化、未正式上线 则首位版本号为0 一期发布 则为V1 二期发布则为V2。

2.2 次版本号 迭代号

次版本号 也叫迭代号 一般代表某个迭代发布的功能集合 一个迭代发布会包含若干个功能更新 。

如V1.1.0 第一期项目第一迭代发布版本、V1.2.0 第一期第二迭代发布版本、第一期第十八个迭代发布版本:V1.18.0。

2.3 小版本号

小版本号 是为了某些小功能的临时上线 热修复的临时上线设置的小迭代 通常不包含大的功能性更新 常常是围绕某个功能点进行升级或者某个bug的修复进行上线。

三、飞流Flow的最佳实践 使用阿里云云效

为了更好地使用飞流Flow 接下来将结合阿里云云效来讲解飞流Flow的最佳实践

3.1 总体流程图

下图为最乐观形式下的飞流Flow模型图 可以见到 release分支是多个feature的集成版本。同时 release又可以通过流水线进行组织 使用在不同的项目环境构建下。

3.2 弓行同学与阿吉同学的最佳实践

这里要邀请出两位同学进行接下来的讲解 他们是【弓行】同学与【阿吉】同学。

3.2.1 功能分支(feature分支)的创建

项目组规划了迭代V1.1.0 迭代backlogs包括

某个bug的修复【弓行同学】

function1 功能的开发【阿吉同学】

function2 功能的开发【弓行同学】

迭代开始时 弓行同学与阿吉同学将会基于master创建三条功能分支 防止三条分支的功能代码互相耦合。

完成分支创建后 版本库中的分支情况便如下图所示 各负责开发的同学可以在各分支上进行开发而不互相影响。

3.2.2 流水线的创建

在云效中 可以将流水线分为三种环境 他们是 【日常环境】、【预发环境】和【生产环境】。云效中的流水线为我们提供了各式各样灵活的构建步骤、部署步骤和人工卡点模版 我们可以基于不同的需求创建流水线的流程。

弓行同学是这样创建他的项目流水线的 请无视正式环境的构建失败

日常环境和预发环境常用于开发与测试 因此他的步骤比较简单

即 【分支集成】-【前后端构建】-【前后端制品】-【前后端部署】

注 在【部署阶段】 为当前流水线制定部署的机器便可完成流水线和部署环境的绑定。

需要注意的是 因为我们需要使用飞流Flow对项目进行版本管理 因此在第一步【源】选择时 选择的版本库需要开启分支模式 同一条流水线存在多个构建源时 如一个流水线需要同时构建前后端的情况 只支持一个源设置分支模式

3.2.3 日常环境发布

完成了流水线的设置后 可以点击【运行】对流水线进行测试。在运行时 由于开启了分支模式 此时需要将本次加入【DEV日常流水线】的分支加入到构建列表中。

运行后 分支管理器会对feature_bugfix、feature_function1、feature_function2 等三个分支进行集成 并生成一个新的【origin/release】分支 如下图 而这个release分支就是专门服务于日常环境的发布分支了。

此时 我们的版本线是这样的 红线代表由云效分支管理器的自动集成 。需要注意的是 release分支的我们不应该直接修改 除了解决冲突外

而随着日常开发的持续进行 每当分支上有同学提交了代码并触发了流水线的重新运行 分支管理器变会对分支进行集成处理 形成包含最新分支代码的commit

3.2.4 预发环境发布

经过每天辛辛苦苦的搬砖 由阿吉同学负责的function1功能和弓行同学负责的bugfix通过了自测和日常冒烟 可以上预发进行验证了。

此时则需要到预发的流水线中 对这两条分支进行集成操作。

选择完需要集成的分支之后 点击运行 便可以实现在预发环境发布这两条分支。

此时的版本线是这样的 绿线代表由预发流水线分支管理器的集成 。如此一来 预发环境便得到了只包含bugfix和function1而不含没有冒烟通过的function2的最新代码的纯净提交。

测试同学和开发同学便可以在预发环境对功能进行预发验证。

同理 当弓行同学的function2功能也开发自测完、在日常冒烟验证后 在预发流水线里添加他的分支 便可以完成对function2的集成了 至此 整个版本线如下所示

3.2.5 危险分支下线

在预发环境进行预发验证和测试时 测试同学发现由【阿吉】同学开发的function1功能虽然完成了开发 但是他的改动会影响某个功能正常运行 而发布日迫在眉睫 现在改动一定是来不及的 此时阿吉同学的feature_function1分支便是一个危险分支 不能够上线。此时 需要在预发流水线对阿吉同学的代码进行下线操作。

下线后 因为涉及到的改动会比较多 此时云效的分支管理器会自动将feature_function2和feature_bugfix两条分支重新集成到为我们创建的另一条预发环境使用的发布分支【release_pre_2】中 以减少代码冲突解决的次数。

此时 版本线如下图所示 蓝线为云效分支管理器集成 而原origin/release_pre分支已经废除 取而代之的是origin/release_pre2

3.2.6 生产环境发布

将通过测试的分支在生产流水线中添加 如3.2.4步 并实现构建便可完成生产环境的发布 生产环境运行的分支也是一条release分支。

在实践中 推荐将生产环境的发布流程增加人工卡点 审批 即流水线的设置可以如下

【构建】-【部署审批 人工卡点 】-【灰度部署(分批)】-【生产部署(分批)】-【生产验证(人工卡点)】-【写基线】

3.2.7 生产环境发布:写基线

写基线是指将发布分支的代码合并到当前master分支中 一般在完成生产验证之后执行。

完成发布后 整体个版本线流程图是

四、FAQ

Q1: 云效Flow下如何进行code review和拉取请求

A1: 基于云效Flow进行团队协作开发时 可以围绕feature分支进行code review和pr操作 即除了保护release分支外 还保护feature分支 不允许直接提交到feature分支 且另外创建origin/feature_xxx_pr分支进行拉取请求。不仅如此 在最终发布到生产之前 设置一个人工卡点来进行code review操作也是可行的 只是code review的粒度不一样 前者基于每个commit、后者基于发布的整个功能 。如果团队的发布节奏比较紧急且人力资源不太充足 可以采取发布前进行人工卡点 团队code review的形式。

Q2: 云效Flow适合什么样的开发场景或者开发团队

A2 云效Flow适合团队规模适中 一个迭代中所需要开发的backlogs涉及到不同的业务域 且存在分支发布风险或存在迭代周期交叉情况 如1.2.1与1.3.0同时开发并提测 的敏捷团队。如上述最佳实践中 【阿吉】同学开发的function1在临近上线前发现会影响其他业务功能开发 需要临时下车不发布 如果一个开发团队中只有两三个人 那么一切从简便可。

Q3: 我可以不使用云效来实现Flow吗

A3 目前来看 使用云效来实现Flow是最省时间的 若不使用云效 可以采用人工管理release分支的构建 jenkins流水线的形式也是可以实现Flow的 或者采用脚本自动合并分支

Q4?: 远程feature分支可以不删除吗

A4 远程feature可以不删除 但是由于feature在发布后已经合并到了基线 不删除留存在远程版本库意义不大。

Q5: 多个分支同时开发 遇到代码冲突怎么办

A5 云效提供了完成的冲突解决教程。最安全的做法是将集成分支拉到本地 在本地解决冲突后 构建成功后再提交到远程release分支

Q6: 下一次迭代 还需要重新创建流水线吗

A6: 不需要 只需要在原先的流水线中将原来需要集成的分支删除 实际上发布后也会自动删除 重新添加需要发布的功能分支上去便可

Q7: 预发、日常都集成了同一个feature 重新构建的话新提交会影响两个环境吗

A7: 一旦预发流水线、日常流水线都集成了同一个feature分支 那么开发者提交代码后触发重新部署 在预发环境和日常环境都会呈现最新的功能特性

Q8: 几条release分支会互相合并吗 如日常的release和预发的release

A8: 不会 release分支相互独立 完全没有一点关系 他们的相同也只是名字上的部分相同而已。

Q9: 对比了gitflow、AoneFlow感觉更加灵活和自由 对风险的控制也是比较稳妥的 那么AoneFlow是最好的版本管理模型吗

A9 没有最好的版本管理模型 适合自己生产的具体情况的才是最好的

以上便是项目版本管理的最佳实践 云效飞流Flow篇的所有内容 欢迎在评论区讨论与提出改进意见

本文转自网络，原文链接：https://developer.aliyun.com/article/783137
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！