火车发版试行方案

名词解释

• 确定车次 ：分支管理人员从 master 分支按版本命名规范切出 Release 分支：release-v[版本号] 分支
• 装车：在 test 环境通过了测试、设计、产品质量校验的 Feature 或 Polish 合并至对应版本的 Release 分支中去
• 关车门：对应版本的 Release 分支不再接受任何代码合入
• 装车成功：关车门后将 Release 分支代码发布至灰度环境
• 验货：质量保障部门在灰度环境上对该版本 Release 分支中的需求进行回归测试
• 重(chong)装确认：确认该版本中的需求质量是否都基本符合要求，没有出现大的或难处理的问题
• 重装：若重装确认环节中发现某需求有大的或难处理的问题，且发车时间前无法修复好，则重新切新 Release 分支，将没有问题的需求重新合入到 Release 分支
• 发车：对应版本 Release 分支需求在灰度环境通过质量保障部门测试后，将 Release 分支合并至 master 分支，根据版本号打上 tag：[版本号]，发布上线（上线）

版本发布频率

1. 每周二、四发布版本上线

关键时间节点

1. 周一、周三 9:30 确定车次
2. 周一、周三 16:00 前完成装车，16:00 关车门，将相关需求发布至灰度环境
3. 周一 16:00～周二19:00、周三 18:00~周四 19:00，验货
4. 周二 、周四 13:00 重装确认
5. 周二、周四 16:00 发车

   
   
   

   版本命名规范

   21.45.1.[n]
   说明：

• 21: 年份缩写，2021 为 21
• 45: 当前是本年的第多少周
• 1：本周 Feature&Polish 的发版次数
• [n]：在 21.45.1 的基础上，部署 Bugfix/紧急优化 的次数。只有部署 Bugfix/紧急优化时才会使用

分支管理

• 线上环境分支：master（分支名不变，版本通过 tag 发布）
• 灰度环境分支：
  • 当前部署版本：pre-v[版本号]： pre-v21.45.1（分支从 master 分支切出，版本号根据版本命名规范生成，通过 tag 发布）
  • 下一版本：release-v[版本号]：release-v21.45.1（分支从 master 分支切出，版本号根据版本命名规范生成，合并到 pre 分支上灰度环境，合并到 master 上线上环境）
• Feature/Polish 分支: {developerName}/feature-{JIRA-ID}-{featureName}：cheng/feature-WB-99-channel-qr

Tag 管理

• 线上环境 Tag：prod-[版本名]
• 灰度环境 Tag：pre-[版本名]

例外处理

1. 发车动作从当天 16:00 开始后，可以一直持续到次日 12:00 前。期间可视情况发起多次重装确认和重装动作
2. 若发车动作截止至次日 12:00 前还未完成，则认为本次版本发车失败。根据版本中需求的回归情况，已回归确认没有问题的需求统一装车到下一车次中
3. 除 Feature&Polish 外，其余类型的任务，例如 Bugfix、紧急优化等，暂不受火车发版影响，保持和之前流程不变（分支需要改为从 master 切。部署到灰度环境时，向灰度环境当前分支发合并请求，测试没有问题后单独向 master 分支发合并请求，进行部署）

4. 装车当日16:00以后未确认装车的需求一律视为装车失败，其他需求正常进行装车，助理需要收集该需求装车失败的原因并在表格中做好记录

   FAQ

5. 验货的时间只有一天左右，可能不够

   1. 一周发布两次版本是目前试行阶段的节奏，如果在试行过程中发现确实时间不够，后期可以再做调整