杭州有哪些做网站的公司,教育网站前置审批,电商平台谈双11变冷,班级优化大师头像昨天有朋友在公众号私信问我几个关于代码分支管理的问题#xff0c;这几个问题是我去年写的《在团队中使用GitLab中的Merge Request工作模式》一文结尾时抛出的几个问题#xff1a;如果系统上线后有紧急Bug需要处理#xff0c;这个流程应该怎样去调整#xff1f;每个任务都… 昨天有朋友在公众号私信问我几个关于代码分支管理的问题这几个问题是我去年写的《在团队中使用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可以便于升级后的回滚。总结工具和流程都只是辅助手段目的是为了团队能够更好的沟通协助能够持续地有高质量的产出千万不能本末倒置。最后祝大家端午节快乐.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
