版本迭代要点

初衷

平时在做版本迭代时,总会遇到这样那样的问题,大部分是流程规范、分工安排、经验技巧类的问题,这里整理了自己关于迭代流程的一些思考,做一些分享,期待大家的阅读和斧正。

流程迭代必要环节

需求小范围预评审 --> 需求评审 --> 问题澄清 --> 技术评审 --> 测试用例评审 --> 开发 --> 自测 --> 联调 --> 代码review -->
产品冒烟 --> 版本提测 --> 压测(如有必要) --> 上线check --> 版本发布上线

角色

  1. 模块owner:参与每次迭代,负责本次迭代的某些模块开发;
  2. 版本master:负责本次迭代进度的各项事宜,外部协调可以向上反馈进行协调;

角色职责

模块owner

  1. 需求评审;
  2. 需求开发、联调;
  3. 测试支持;

版本master

  1. 清楚了解本次迭代的需求边界;
  2. 负责本次版本迭代进度把控;
  3. 清楚提测、上线流程细节;
  4. 本次迭代分析、反馈;

目标

模块owner

  1. 对本次迭代的需求需要理解透彻,需要理清历史版本和本次版本、当前模块和其他模块、未来扩展性 这些核心问题;
  2. 开发时,要以高的代码质量标准要求自己,追求高内聚低耦合、扩展性高、优雅的解决方案;
  3. 开发完毕后,做好充分的自测、联调工作,追求提测后 bug-free,而不是将测试工作全部移交给测试人员然后测试一堆 bug;

版本master

  1. 要以主人翁的心态来推进本次版本的迭代,要切换思维方式,不要期待别人给你分配任务;
  2. 对本次迭代的需求边界要牢记在心,需要理清本次迭代的要点以及和其他系统的交互关系,能够迅速进行定位追溯,并能够及时高效的解决;
  3. 需要按照既定的排期计划严格执行,并督促其他模块 owner 遵守排期计划,确保迭代能够按时高质量的交付;
  4. 需要严格遵守迭代流程的原则,对流程的每个步骤认真严肃的落实;
  5. 需要给出反馈,对本次迭代中出现的问题能够进行全面深入的分析,作为下次迭代的改进项进行优化;

环境区分

  1. test环境:对应工程中的qaprofile,对应工程中的master分支,用于给实施人员演示,以及线上环境的 bug 复现、修复、验证;
  2. dev环境 :对应工程中的devprofile,对应工程中的dev分支,用于版本迭代测试;
  3. prod环境:对应工程中的prodprofile,对应工程中打出的tag,用于真实用户使用;

分支命名

avatar

目前我们版本控制基本是和 gitflow 一致。

develop 对应我们的 dev 和 test 分支;
release 类似我们的 tag 分支,不过我们是先合入 master,后 release,而不是先 release 后合入 master。
feature 对应我们每次迭代从 dev 拉出来的个人开发分支。
hotfix 对应我们每次修复线上问题从 master 拉出的 bug 修复分支。

feature 分支在上线后应该删掉。

  1. 如果是迭代需求,分支名最好形式是feature-版本号-模块名,如feature-v1.0-teacherManage,注意该分支是基于开发分支,如基于dev进行checkout出来的,提测时mergedev分支,上线时mergemaster分支,最后基于master分支打tag上线;
  2. 如果是线上bug,分支名最好形式是hotfix-版本号-模块或者hotfix-版本号-bug号,如hotfix-v1.0-order或者hotfix-v1.0-925,这个是基于master分支来checkout出来的,然后通过test环境复现和验证,验证通过后合并至master分支,最后基于master分支打tag上线,上线完毕后将master分支mergedev分支;
  3. 版本上线后,需求分支需要合至master,同时删掉该分支,线上bug分支也是如此;

提测流程

  1. 配置文件是否配置过了qa
  2. 数据库更新脚本是否提至git,是否正确,是否更新至测试环境数据库;
  3. 新依赖的外部服务是否已部署至 dev 环境;
  4. 新增定时任务是否开启,需要编辑的定时任务是否编辑;

上线流程

上线check列表
  1. 配置文件是否配置过了prod
  2. 数据库更新脚本是否提至git,是否正确,是否更新至线上环境数据库;
  3. 新依赖的外部服务是否已部署上线;
  4. 新增定时任务是否开启,需要编辑的定时任务是否编辑;
  5. dev 环境已测试过的最新代码是否合并至master,并且基于master打了tag,打的tag是否基于已测试过的最新代码;
  6. api项目是否已经升级了maven-version,如果没有,使用mvn versions:set -DnewVersion=1.0.0.RELEASE来打版本,注意线上必须使用RELEASE版本号;

你可能感兴趣的:(版本迭代要点)