关键词：
简介：
飞流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篇的所有内容，欢迎在评论区讨论与提出改进意见！
原文链接
本文为阿里云原创内容，未经允许不得转载。
在具有大量依赖项的项目中进行依赖项管理的最佳实践
】在具有大量依赖项的项目中进行依赖项管理的最佳实践【英文标题】：Bestpracticefordependencymanagementinaprojectwithahugenumberofdependencies【发布时间】：2014-07-1804:00:05【问题描述】：我们的项目就像一个适配器/外观接口，用于大量不同... 查看详情
云效flow——java构建并通过云效上传二方库到maven私有仓库(代码片段)
...云效会为用户生成两个私有仓库，一个用于存放release版本的二方库，一个用于存储SNAPSHOT版本的二方库。Release仓库地址示例:https://packages.aliyun.com/maven/repository/24409-release-87w1FL/SnapShot仓库地址示例 查看详情
svn协同开发下的dll版本管理最佳实践
...误，忘记提交本地更改的文件或少提交，特别是croj或sln项目和新添加的文件，因为新添加的文件在svn下默认是？状态的，这一点的话，只能靠开发人员自己细心解决；2.由 查看详情
最佳管理实践msp
MSP是最佳实践系列刊物中项目组合的一部分（统称为最佳管理实践或BMP）旨在帮助组织或个人管理项目、项目群和服务的一致性及有效性（图1.5）。MSP可以在很好的融入其他BMP产品，不论是国际标准还是组织内部标准。在适当情... 查看详情
建立和管理开源项目的最佳实践
】建立和管理开源项目的最佳实践【英文标题】：BestPracticesforSetupandManagementofanOpenSourceProject【发布时间】：2010-04-0216:23:03【问题描述】：今年晚些时候，我想发布一个我一直致力于开源的PHP框架。我确实使用源代码控制(SVN)，但... 查看详情
版本管理之gitlab实践教程基础篇3
...nt是版本管理中非常重要的内容,尤其是在经年累月的大型项目中,铁打的项目,流水的SE,哪怕只言片语的留下,对后来者问题的对应很多时候都能起到重要作用,这篇文章用来讲解git中如何进行comment的管理.为什么需要comment为什么需... 查看详情
处理一个项目的多个版本的 Flash Builder 最佳实践
】处理一个项目的多个版本的FlashBuilder最佳实践【英文标题】：FlashBuilderbestpracticeforworkingonmultipleversionsofaproject【发布时间】：2011-04-1310:51:21【问题描述】：我有一个大型FlashBuilder项目，它是更大(.net)解决方案的一部分。对于整... 查看详情
svn版本管理系统最佳应用实践
摘要SVN是近年来崛起的非常优秀的版本管理工具，与CVS管理工具一样，SVN是一个固态的跨平台的开源的版本控制系统。SVN版本管理工具管理者随时间改变的各种数据。这些数据放置在一个中央资料档案库（repository）中，这个档... 查看详情
ci/cd系列之阿里云云效2020应用篇(代码片段)
目录前言实战制品仓库maven配置项目pom配置代码管理流水线参考资料前言前不久登录阿里云后台，看到云效的介绍，出于好奇便点进去看了看，刚开始以为云效是类似Jenkins的一套自动化部署方案，了解之后发现云效的野心很大哦... 查看详情
在 Web 应用程序中使用 Drools Expert/Flow 的最佳实践
】在Web应用程序中使用DroolsExpert/Flow的最佳实践【英文标题】：BestpracticesforusingDroolsExpert/FlowinaWebApplication【发布时间】：2011-04-1813:46:07【问题描述】：我目前正在自学DroolsExpert/Flow以及GWT。我想使用DroolsFlow作为事件/命令总线和... 查看详情
zabbix最佳实践——安装篇
...服务器系统的安全运行；并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。 zabbix由2部分构成，zabbixserver与 查看详情
在实际生产项目中部署（管理依赖）django 可重用应用程序的最佳实践是啥？
】在实际生产项目中部署（管理依赖）django可重用应用程序的最佳实践是啥？【英文标题】：What\'sthebestpracticetodeploy(managedependency)thedjangoreusableappsinarealproductionproject?在实际生产项目中部署（管理依赖）django可重用应用程序的最... 查看详情
版本管理之gitlab实践教程基础篇5
...下如何使用mergerequest.pullrequestVSmergerequestpullrequest在开源项目中极其常见，被简称为PR。素未谋面的一群人在一起一起开发一个项目，你看到某个项目很好Fork下来，添加了一个功能发了个PR给Owner，Owner评审完之后觉得很OK，就Merge... 查看详情
译livedata-flow在mvvm中的最佳实践
...rt-i-a98fe06077a0最近，我一直在寻找MVVM架构中KotlinFlow的最佳实 查看详情
IntelliJ IDEA 9 + Maven + 版本控制的最佳实践
...rsioncontrol【发布时间】：2010-12-1122:26:42【问题描述】：该项目使用Maven，因此POM文件是项目信息的主要来源。项目文件中有一些有用的设置可以很好地保留。OTOHIDEA似乎在项目文件结构中创建了太多冗余更改，从而污染了SVN历史... 查看详情
实战flyway迁移指南最佳实践(代码片段)
项目在多环境迭代开发过程中，数据库的表结构不断变更，在部署时，往往会出现数据库表结构未及时变更导致出现问题，耗费在表结构上的时间相当多，上线过程持续痛苦，代码有GIT/SVN来控制，数据库中的表版本也可以做到... 查看详情
软件项目量化管理（cmmi高成熟度）实践经验谈——之项目管理过程监督与控制篇
续：软件项目量化管理（CMMI高成熟度）实践经验谈——之概述篇续：软件项目量化管理（CMMI高成熟度）实践经验谈——之项目管理过程策划篇2、项目监督与控制 项目监控是环绕项目实施计划，跟踪进度、成本... 查看详情
在版本控制系统之间移动的最佳实践是啥？
...布时间】：2010-09-0921:20:21【问题描述】：cvs中大约有200个项目，vss中至少有100个项目。有些是维护模式下的非活动代码。有些是旧版应用程序。有些是不再使用的旧应用程序。大约10%正在积极开发中。 查看详情