初衷
平时在做版本迭代时，总会遇到这样那样的问题，大部分是流程规范、分工安排、经验技巧类的问题，这里整理了自己关于迭代流程的一些思考，做一些分享，期待大家的阅读和斧正。
流程迭代必要环节
需求小范围预评审 --> 需求评审 --> 问题澄清 --> 技术评审 --> 测试用例评审 --> 开发 --> 自测 --> 联调 --> 代码review -->
产品冒烟 --> 版本提测 --> 压测(如有必要) --> 上线check --> 版本发布上线
角色
-
模块owner：参与每次迭代，负责本次迭代的某些模块开发； -
版本master：负责本次迭代进度的各项事宜，外部协调可以向上反馈进行协调；
角色职责
模块owner
- 需求评审；
- 需求开发、联调；
- 测试支持；
版本master
- 清楚了解本次迭代的需求边界；
- 负责本次版本迭代进度把控；
- 清楚提测、上线流程细节；
- 本次迭代分析、反馈；
目标
模块owner
- 对本次迭代的需求需要理解透彻，需要理清历史版本和本次版本、当前模块和其他模块、未来扩展性 这些核心问题；
- 开发时，要以高的代码质量标准要求自己，追求高内聚低耦合、扩展性高、优雅的解决方案；
- 开发完毕后，做好充分的自测、联调工作，追求提测后 bug-free，而不是将测试工作全部移交给测试人员然后测试一堆 bug；
版本master
- 要以主人翁的心态来推进本次版本的迭代，要切换思维方式，不要期待别人给你分配任务；
- 对本次迭代的需求边界要牢记在心，需要理清本次迭代的要点以及和其他系统的交互关系，能够迅速进行定位追溯，并能够及时高效的解决；
- 需要按照既定的排期计划严格执行，并督促其他模块 owner 遵守排期计划，确保迭代能够按时高质量的交付；
- 需要严格遵守迭代流程的原则，对流程的每个步骤认真严肃的落实；
- 需要给出反馈，对本次迭代中出现的问题能够进行全面深入的分析，作为下次迭代的改进项进行优化；
环境区分
-
test环境：对应工程中的qa的profile，对应工程中的master分支，用于给实施人员演示，以及线上环境的 bug 复现、修复、验证； -
dev环境 ：对应工程中的dev的profile，对应工程中的dev分支，用于版本迭代测试； -
prod环境：对应工程中的prod的profile，对应工程中打出的tag，用于真实用户使用；
分支命名
avatar
目前我们版本控制基本是和 gitflow 一致。
develop 对应我们的 dev 和 test 分支；
release 类似我们的 tag 分支，不过我们是先合入 master，后 release，而不是先 release 后合入 master。
feature 对应我们每次迭代从 dev 拉出来的个人开发分支。
hotfix 对应我们每次修复线上问题从 master 拉出的 bug 修复分支。feature 分支在上线后应该删掉。
- 如果是迭代需求，分支名最好形式是
feature-版本号-模块名，如feature-v1.0-teacherManage，注意该分支是基于开发分支，如基于dev进行checkout出来的，提测时merge到dev分支，上线时merge至master分支，最后基于master分支打tag上线; - 如果是线上
bug，分支名最好形式是hotfix-版本号-模块或者hotfix-版本号-bug号，如hotfix-v1.0-order或者hotfix-v1.0-925，这个是基于master分支来checkout出来的，然后通过test环境复现和验证，验证通过后合并至master分支，最后基于master分支打tag上线，上线完毕后将master分支merge到dev分支; - 版本上线后，需求分支需要合至
master，同时删掉该分支，线上bug分支也是如此；
提测流程
- 配置文件是否配置过了
qa； - 数据库更新脚本是否提至
git，是否正确，是否更新至测试环境数据库； - 新依赖的外部服务是否已部署至 dev 环境；
- 新增定时任务是否开启，需要编辑的定时任务是否编辑；
上线流程
上线check列表
- 配置文件是否配置过了
prod； - 数据库更新脚本是否提至
git，是否正确，是否更新至线上环境数据库； - 新依赖的外部服务是否已部署上线；
- 新增定时任务是否开启，需要编辑的定时任务是否编辑；
- dev 环境已测试过的最新代码是否合并至
master，并且基于master打了tag，打的tag是否基于已测试过的最新代码; -
api项目是否已经升级了maven-version，如果没有，使用mvn versions:set -DnewVersion=1.0.0.RELEASE来打版本，注意线上必须使用RELEASE版本号；
网友评论