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

简介: 飞流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



一、分支规约


image.png


二、版本号规约


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


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又可以通过流水线进行组织,使用在不同的项目环境构建下。


1.png


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


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


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


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


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

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

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

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

image.png

2.jpg


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


3.png


3.2.2 流水线的创建


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


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


4.jpg


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


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


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


4.jpg


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


6.png


3.2.3 日常环境发布


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


7.png


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


8.png


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


10.png


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


11.png


3.2.4 预发环境发布


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


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


12.png


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


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


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


13.png


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


14.png


3.2.5 危险分支下线


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


15.png


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


16.png


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


17.png


3.2.6 生产环境发布


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


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


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


3.2.7 生产环境发布:写基线


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


18.png


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


19.png


四、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分支


20.png

21.png


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


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


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


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


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


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


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


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



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

相关实践学习
2分钟自动化部署人生模拟器
本场景将带你借助云效流水线Flow实现人生模拟器小游戏的自动化部署
SVN版本控制系统
SVN是现在软件开发之中的主流软件版本控制工具,在工作之中利用SVN可以有效的解决多人开发的代码管理问题,本课程将为读者讲解SVN服务器的配置以及基于MyEclipse的SVN客户端插件的配置与使用,并且在讲解之中着重讲解了冲突的产生于解决。
目录
相关文章
|
4月前
|
Java Linux Docker
阿里云云效流水线自动化构建Java项目并发布到docker环境
阿里云云效流水线自动化构建Java项目并发布到docker环境
203 0
|
26天前
|
Shell Linux Go
云效问题之 Flow 使用自定义镜像构建步骤失败如何解决
云效镜像是指存储在阿里云效服务中的容器镜像,它们可以用于持续集成和持续部署(CI/CD)流程中;本合集将介绍如何在云效平台上管理和使用镜像资源,以及常见的镜像问题和解决办法。
45 0
|
2月前
|
缓存 BI
咨询下,阿里云云效ram账号绑定钉钉账号后,手机端看项目,是空的,怎么解决?
咨询下,阿里云云效ram账号绑定钉钉账号后,手机端看项目,是空的,怎么解决?
25 2
|
2月前
|
网络协议 Docker 容器
云效中flow构建出现这样的问题,这个应该怎么办?
云效中flow构建出现这样的问题,这个应该怎么办?
27 2
|
4月前
|
API
在云效中获取项目详情接口返回值为null
在云效中获取项目详情接口返回值为null
39 1
|
4月前
|
API
如果在云效中获取项目详情接口返回值为null
如果在云效中获取项目详情接口返回值为null
31 2
|
6月前
云效中我们的项目组成员无法看到工时这个功能模块
云效中我们的项目组成员无法看到工时这个功能模块,请问是什么原因,在哪里配置呀?
61 1
|
8月前
|
弹性计算 jenkins 持续交付
在云效Flow中所提供的各种操作模版是非常适应于我们国内用户的
在云效Flow中所提供的各种操作模版是非常适应于我们国内用户的
|
Java 测试技术
阿里云云效-项目的部署与发布
本文针对于阿里云云效代码的管理以及部署上线的一些教程,另外关于云效其他的一些功能暂不做概述,关于代码的部署请看作者的上一篇文章
840 0
阿里云云效-项目的部署与发布
|
Kubernetes 安全 搜索推荐
Istio生态系统ON ASM(4):在阿里云服务网格ASM中集成阿里云云效Flow实现DevOps
在阿里云服务网格(简称 ASM)企业版实例中,兼容 Istio,支持多个 Kubernetes 集群统一流量管理,为容器和虚拟机应用服务提供一致性的通信控制。基于服务网格最新的“数据面KubeAPI访问"能力,能够通过数据面集群的kubeconfig来管理Istio资源。和阿里云Flow等云效工具集成后,可以享受DevOps、GitOps带来的应用发布的便利性,还能够利用Istio细粒度
216 0
Istio生态系统ON ASM(4):在阿里云服务网格ASM中集成阿里云云效Flow实现DevOps