发布于 

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

昨天有朋友在公众号私信问我几个关于代码分支管理的问题,这几个问题是我去年写的《在团队中使用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分支做为发布分支,该分支设置为只能管理员提交代码
  • 需求开发完成后,会mergemaster分支进行测试
  • 测试通过的提交,并到release分支,进行再次验证,验证通过,发布上线

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

引入Tag

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

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

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

总结

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

最后,祝大家端午节快乐!