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