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