济南网站建设公司,工作态度,视觉中国设计网站,菏泽市建设局网站简介#xff1a; 飞流Flow的最佳实践#xff08;使用阿里云云效#xff09;为了更好地使用飞流Flow#xff0c;接下来将结合阿里云云效来讲解飞流Flow的最佳实践
目录 一、分支规约 二、版本号规约 2.1 主版本号#xff08;首位版本号#xff09; 2.2 次版本号#xff…简介 飞流Flow的最佳实践使用阿里云云效为了更好地使用飞流Flow接下来将结合阿里云云效来讲解飞流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主版本号.次版本号.小版本号
egV1.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篇的所有内容欢迎在评论区讨论与提出改进意见
原文链接
本文为阿里云原创内容未经允许不得转载。
