不断进化的分支和需求管理

昨天有朋友在公众号私信问我几个关于代码分支管理的问题，这几个问题是我去年写的《在团队中使用GitLab中的Merge Request工作模式》一文结尾时抛出的几个问题：

• 如果系统上线后有紧急Bug需要处理，这个流程应该怎样去调整？
• 每个任务都在单独分支并行开发，这时如果A和B都依赖C开发的一个模块，应该怎么解决？
• 理论上Issue管理员和开发人员都可以进行创建，什么样的Issue可以有开发人员来创建？

这几个问题在《敏捷下的需求和代码分支管理》一文中其实已经给出了答案，时隔两个月，管理方式又有了些调整和改进。我觉得还是有必要单独写一写。

总体的流程没有大的变化，还是使用Tapd来管理需求和缺陷，使用Gitlab来管理代码的分支，但有几个小的调整：

• 迭代周期
• 需求文档
• 分支管理

迭代周期调整

之前是以一周做为一个迭代周期，实践中发现，以周为单位，粒度还是太大，有时候紧急上线一个功能或是修复Bug，连续几天都会有发布，甚至一天内还有多次发布。目前迭代遵循着以下几点：

• 因为功能发布时间的不确定性，需求的安排还是以周为单位来计划
• 一个完整功能提测通过后，立即发布上线
• 紧急Bug修复完成后，立即发布上线

像这样调整，产品的迭代会更加敏捷，同时也对整个团队提出了更高的要求，怎样在这样高速迭代的过程中，还保证产品的稳定性？

需求文档的调整

自从以任务为导向调整成需求为导向时，就已经意识到需求的重要性，同时也面临一个问题：需求文档谁来写？

一些大公司的研发团队，配置齐全，有专职的需求分析师，而像我们这种小的创业型产品团队，我希望每个人都能是需求分析师。

在调整为需求导向的开始阶段，是我一个人在写需求的详细描述，一旦精力分散，就会导致有疏漏，效果不是很好。现在我要求团队成员每个人都参与写需求，在接到任务时，必须先思考，把自己到理解写出来，然后才开始开发。

我会对需求做review，也会让经验丰富的程序员来做review，找出遗漏的点和错误的点进行补充和改正。

让每个人都参与需求的编写有两个好处：

• 可以改掉程序员不喜欢思考，拿到任务就直接写代码的坏习惯
• 程序员有了自己的思考，并且形成了文字的输出，对需求的理解会更加的深刻，产出的质量会有提高

另外，需求文档的工具，也从原来直接在Tapd中编写，调整到了语雀。在这里强烈推荐下语雀，理由如下：

• 编辑器，对开发人员非常友好，真正意义上的所见及所得
• 文中可以直接嵌入Office文档和视频（支持本地视频上传），在线浏览和观看
• 整个文档可以导出成PDF，不知不觉的就可以写一本电子书

分支的调整

之所以要做调整肯定是遇到了问题，所以，先说问题：

1. 需要更小迭代的发布，常常A功能已经在测试中，这时B功能并入主分支进行测试，A功能测试完，B功能还在测试中，这是如果发布，会导致没有完成测试的B也发布了，而我只想发布A
2. 客户A使用的是v6.7.5版本，而现在最新的版本已经迭代到了v6.8.0，在v6.7.5上发现的Bug应该怎么办？

引入release分支

• 创建release分支做为发布分支，该分支设置为只能管理员提交代码
• 需求开发完成后，会merge到master分支进行测试
• 测试通过的提交，并到release分支，进行再次验证，验证通过，发布上线

引入release分支可以虽然在操作步骤上带来了一些复杂度，但是可以确保能够以最小粒度发布。

引入Tag

在release分支发布上线后，以发布的版本号为名称在GitLab中打一个Tag，这样就可以解决上面的问题2，分为两种情况：

1. 以v6.7.5的Tag创建分支来修复Bug，修复后直接在该分支进行测试，验证通过后发布，最新版本如果该Bug已经修复，则直接更新Tag
2. 以v6.7.5的Tag创建分支来修复Bug，修复后直接在该分支进行测试，验证通过后发布，最新版本如果没有修复该Bug，将修复Bug的提交合并到主分支，然后更新Tag

同样，当程序发布到docker容器中后，在容器的私有仓库中也打上以版本号命名的Tag，可以便于升级后的回滚。

总结

工具和流程都只是辅助手段，目的是为了团队能够更好的沟通协助，能够持续地有高质量的产出，千万不能本末倒置。