版本开发基本流程——TBD Workflow（四）

前言

由于我们使用Gitlab代码托管平台，以feature branch的形式进行提交，所以准确的说我们用的是Scaled Trunk Based Development。

TBD准确的说不是一种"分支策略模型"，它更像是一种"分支策略模型"的规范。因此对它的使用不像是Gitflow那样有一套标准的workflow进行参考。我们在执行TBD到我们的项目中的时候，应该结合规范，参考其它TBD的应用结合我们自己的使用场景来执行。

一般而言我们只有一个分支----trunk分支（master分支），所有的开发和release工作都是在这个分支上进行。我们可以在trunk分支上以tag的形式进行release版本。如果有需要的话我们可以从相应的tag处检出release分支。通过从trunk分支上cherry-pick bug fix patch的形式，对release分支的维护。release分支和master分支之间不存在merge操作。

版本开发基本流程

遵循TBD进行项目版本开发过程中最关键的几部分就是：

• 代码提交
• 代码评审
• 待发布版本测试
• 版本发布
• 发布版本热修复

代码提交

为了Gitlab代码评审的需要，我们使用Feature Branch进行提交：

• Developer本地同步master分支
• Developer本地从master分支上检出feature branch
• Developer完成开发提交到feature branch
• Developer检查本地master是否最新，如果不是的话同步master分支，然后快进feature branch
• Developer push feature branch到Gitlab仓库

代码评审

我们使用Gitlab进行代码评审：

• Developer在Gitlab上发起merge request，请求将feature branch合并入master分支
• Reviewer收到请求后，进行代码评审，fetch feature branch到本地进行测试
• 测试通过后通知Maintainer合并请求，删除掉feature branch
• 测试不通过，close掉merge request，删除feature branch后通知Developer进行修改并重新提交

待发布版本测试（rc测试）

当前版本规划的feature全都开发完后，进入到“待发布版本测试”阶段。此阶段不再允许合入新的特性。测试人员对项目进行测试（功能测试，压力测试），反馈Bug给开发人员进行Bug修复。

• Maintainer从dev分支上检出release，更新版本信息（记录当前版本引入了哪些feature），打tag：sdk_vx.y
• Tester对项目进行测试，反馈Bug给Developer
• Developer在master上复现问题
• Developer在master上解决问题，并提交到master上（如果master上不存在这个问题，直接往release上提交）
• Developer在本地cherry-pick bugfix到release分支（我们的gitlab目前还不支持cherry-pick，所以只能在本地操作）
• 在release分支上进行“代码提交”“代码评审”
• Maintainer合并时根据需要打tag：sdk_vx.y-rcx

版本发布

版本测试通过后进入到“版本发布”阶段

• 采用release分支制作tar包
• 对tar包进行测试
• 测试通过后上传NAS，供FAE使用

发布版本热修复

发布出去的版本发现了严重Bug需要立即修复后进行发布，此时需要用到“发布后热修复”：

• Developer在release分支上复现问题
• Developer在master分支在上面复现问题
• Developer在master上解决问题，并提交到master上（如果master上不存在这个问题，直接往release上提交）
• 在master分支上进行“代码评审”“合并”
• Developer在本地cherry-pick bugfix到release分支（我们的gitlab目前还不支持cherry-pick）
• 在release分支上进行“代码提交”“代码评审”“合并”
• Maintainer合并时根据需要打tag：sdk_vx.y.z

此阶段也需要在合适的时候进行rc测试

补充

在使用TBD进行团队协作时，存在以下几种提交行为：

• 往master分支上提交feature
• 往master分支提交某一release分支的bugfix，然后cherry-pick到release分支
• 往master分支上提交feature，然后cherry-pick到release分支

为了减小维护已经发布版本的压力，发布出去的版本尽量集中（最好是一个分支），这样可以减小我们维护的工作量这样可以减少我们在不同release分支和master分支之间的bugfix的cherry-pick，feature的cherry-pick。