简介：飞流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主版本号.次版本号.小版本号
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篇的所有内容，欢送在评论区探讨与提出改良意见！
版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。