不断进化的分支和需求管理
昨天有朋友在公众号私信问我几个关于代码分支管理的问题，这几个问题是我去年写的《在团队中使用GitLab中的Merge Request工作模式》一文结尾时抛出的几个问题：
- 如果系统上线后有紧急
Bug需要处理，这个流程应该怎样去调整？ - 每个任务都在单独分支并行开发，这时如果A和B都依赖C开发的一个模块，应该怎么解决？
- 理论上
Issue管理员和开发人员都可以进行创建，什么样的Issue可以有开发人员来创建？
这几个问题在《敏捷下的需求和代码分支管理》一文中其实已经给出了答案，时隔两个月，管理方式又有了些调整和改进。我觉得还是有必要单独写一写。
总体的流程没有大的变化，还是使用Tapd来管理需求和缺陷，使用Gitlab来管理代码的分支，但有几个小的调整：
- 迭代周期
- 需求文档
- 分支管理
迭代周期调整
之前是以一周做为一个迭代周期，实践中发现，以周为单位，粒度还是太大，有时候紧急上线一个功能或是修复Bug，连续几天都会有发布，甚至一天内还有多次发布。目前迭代遵循着以下几点：
- 因为功能发布时间的不确定性，需求的安排还是以周为单位来计划
- 一个完整功能提测通过后，立即发布上线
- 紧急
Bug修复完成后，立即发布上线
像这样调整，产品的迭代会更加敏捷，同时也对整个团队提出了更高的要求，怎样在这样高速迭代的过程中，还保证产品的稳定性？
需求文档的调整
自从以任务为导向调整成需求为导向时，就已经意识到需求的重要性，同时也面临一个问题：需求文档谁来写？
一些大公司的研发团队，配置齐全，有专职的需求分析师，而像我们这种小的创业型产品团队，我希望每个人都能是需求分析师。
在调整为需求导向的开始阶段，是我一个人在写需求的详细描述，一旦精力分散，就会导致有疏漏，效果不是很好。现在我要求团队成员每个人都参与写需求，在接到任务时，必须先思考，把自己到理解写出来，然后才开始开发。
我会对需求做review，也会让经验丰富的程序员来做review，找出遗漏的点和错误的点进行补充和改正。
让每个人都参与需求的编写有两个好处：
- 可以改掉程序员不喜欢思考，拿到任务就直接写代码的坏习惯
- 程序员有了自己的思考，并且形成了文字的输出，对需求的理解会更加的深刻，产出的质量会有提高
另外，需求文档的工具，也从原来直接在Tapd中编写，调整到了语雀。在这里强烈推荐下语雀，理由如下：
- 编辑器，对开发人员非常友好，真正意义上的所见及所得
- 文中可以直接嵌入
Office文档和视频（支持本地视频上传），在线浏览和观看 - 整个文档可以导出成
PDF，不知不觉的就可以写一本电子书
分支的调整
之所以要做调整肯定是遇到了问题，所以，先说问题：
- 需要更小迭代的发布，常常A功能已经在测试中，这时B功能并入主分支进行测试，A功能测试完，B功能还在测试中，这是如果发布，会导致没有完成测试的B也发布了，而我只想发布A
- 客户A使用的是
v6.7.5版本，而现在最新的版本已经迭代到了v6.8.0，在v6.7.5上发现的Bug应该怎么办？
引入release分支
- 创建
release分支做为发布分支，该分支设置为只能管理员提交代码 - 需求开发完成后，会
merge到master分支进行测试 - 测试通过的提交，并到
release分支，进行再次验证，验证通过，发布上线
引入release分支可以虽然在操作步骤上带来了一些复杂度，但是可以确保能够以最小粒度发布。
引入Tag
在release分支发布上线后，以发布的版本号为名称在GitLab中打一个Tag，这样就可以解决上面的问题2，分为两种情况：
- 以
v6.7.5的Tag创建分支来修复Bug，修复后直接在该分支进行测试，验证通过后发布，最新版本如果该Bug已经修复，则直接更新Tag - 以
v6.7.5的Tag创建分支来修复Bug，修复后直接在该分支进行测试，验证通过后发布，最新版本如果没有修复该Bug，将修复Bug的提交合并到主分支，然后更新Tag
同样，当程序发布到docker容器中后，在容器的私有仓库中也打上以版本号命名的Tag，可以便于升级后的回滚。
总结
工具和流程都只是辅助手段，目的是为了团队能够更好的沟通协助，能够持续地有高质量的产出，千万不能本末倒置。
最后，祝大家端午节快乐！
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
