系统提测及上线规范（系统上线必读！）

Posted 2021-03-24 aspirant

 

 

所有系统提测和上线流程均需按以下流程严格执行

1 需求上线（指产品推动，基于 PRD 的需求上线）

1.1 提测

• 提测使用的分支必须为 test 分支

• 测试非必要的情况下必须使用泳道，以后的测试骨干链路会禁止 RD 手工发布

• 提测前一天必须提 PR，至少包含系统负责人和 TL，2 个 approve之后合并到 test 分支后提测 各系统主 R

• 所有的提测项目必须提供提测文档，提测文档模板见 需求上线计划模板

• 客户端快照版本管理需要登记到文档中各客户端包版本登记

1.2 上线前准备

• 提前一天merge 代码，RD 提 PR 将开发分支（不能用 test 分支）的代码合并到 release 分支，至少包含系统负责人和 TL，2 个 approve之后合并

• 所有的需求上线前必须提交系统上线计划文档 ，模板见 TODO

1.3 预上线阶段

• 修改数据库、es 、redis 等基础组件的配置

• 编译 release 分支上线 st 环境

• 打正式的客户端 release 包 各客户端包版本登记

• 修改 MCC 配置

• 让 QA 进行 ST 环境的验证

1. 4 正式上线

• QA 打 tag 合并到 master 分支,如新服务没有 ci，手工提 PR 合并到 master 分支

• RD检查 master 分支的代码，整体 check 一下修改点，防止有遗漏的合并的代码或者冲突被覆盖的代码

• 编译 tag 的代码为上线版本

• 提前准备回滚版本（ plus 会自动有线上包，如果不能用，使用上一次上线的包，或者重新使用上一次上线的 tag 重新打包）

• 在 打车系统值班 群中发布上线周知

• 先灰度一台机器，进入观察阶段（见下一步 上线后观察），观察无误后，发剩余的机器

1.5 观察阶段

• 上线后必须观察，超过5分钟的日志，观察每一个异常，观察本次修改的新日志是否按正常逻辑进行

• 观察数据库，ES，redis中的数据是否按设计的内容生成

• 全量上线完毕之后找 QA 验证。

• 验证后在 打车系统值班 群中发布上线完毕周知

 

 

2 技术优化上线（一般指性能优化，一般无 QA 测试）

2.1 上线前准备

• 提前一天merge 代码，RD 提 PR 将开发分支的代码合并到 release 分支，至少包含系统负责人和 TL，2 个 approve之后合并

• 上线前必须提交系统上线计划文档 ，模板见 技术优化上线计划模板

2.2 预上线阶段

• 修改数据库、es 、redis 等基础组件的配置

• 编译 release 分支上线 st 环境

• 修改 MCC 配置

2.3 正式上线

• QA 打 tag 合并到 master 分支,如新服务没有 ci，手工提 PR 合并到 master 分支

• RD检查 master 分支的代码，整体 check 一下修改点，防止有遗漏的合并的代码或者冲突被覆盖的代码

• 编译 tag 的代码为上线版本

• 提前准备回滚版本（ plus 会自动有线上包，如果不能用，使用上一次上线的包，或者重新使用上一次上线的 tag 重新打包）

• 在 打车系统值班 群中发布上线周知

• 先灰度一台机器，进入观察阶段（见下一步 上线后观察），观察无误后，发剩余的机器

2.4 观察阶段

• 上线后必须观察，超过5分钟的日志，观察每一个异常并定位，观察本次修改的新日志是否按正常逻辑进行

• 观察数据库，ES，redis中的数据是否按设计的内容生成

• 验证后在 打车系统值班 群中发布上线完毕周知

 

 

3 Bug上线（一般 改 bug，一般无 QA 测试，无数据库等中间件改动）

3.1 上线前准备

• RD 提 PR 将开发分支的代码合并到 release 分支，至少包含系统负责人和 TL，2 个 approve之后合并

• 上线前必须提交系统上线计划文档 ，模板见 bug修复上线计划模板

3.2 预上线阶段

• 编译 release 分支上线 st 环境

3.3 正式上线

• 手工提 PR 合并到 master 分支

• RD检查 master 分支的代码，整体 check 一下修改点，防止有遗漏的合并的代码或者冲突被覆盖的代码

• 提前准备回滚版本（ plus 会自动有线上包，如果不能用，使用上一次上线的包，或者重新使用上一次上线的 tag 重新打包）

• 在 打车系统值班 群中发布上线周知

• 先灰度一台机器，进入观察阶段（见下一步 上线后观察），观察无误后，发剩余的机器

3.4 观察阶段

• 上线后必须观察，超过5分钟的日志，观察每一个异常并定位，观察本次修改的新日志是否按正常逻辑进行

• 验证后在 打车系统值班 群中发布上线完毕周知

 

4 紧急上线（已经影响了线上，必须立刻修复的问题）

4.1 上线前准备

• RD 直接合并代码到 release 分支

4.2 预上线阶段

• 跳过预发布环节

4.3 正式上线

• 提前准备回滚版本（ plus 会自动有线上包，如果不能用，使用上一次上线的包，或者重新使用上一次上线的 tag 重新打包）

• 紧急上线使用 release 分支来上线

• 在 打车系统值班 群中发布上线周知

• 先灰度一台机器，进入观察阶段（见下一步 上线后观察），观察无误后，发剩余的机器

4.4 观察阶段

• 上线后必须观察，超过5分钟的日志，观察每一个异常并定位，观察本次修改的新日志是否按正常逻辑进行

• 验证后在 打车系统值班 群中发布上线完毕周知

• 验证无误之后，合并代码到 master

• 补充上线文档 模板紧急上线计划模板

 

5 异常回滚

• 触发大量告警必须第一时刻立刻回滚

• 在 打车系统值班 群中发布回滚周知

• 定位问题，并在上线计划文档中填写问题分析，未填写问题分析不允许再次上线

• 填写完问题分析后，与系统负责人或 TL 共同确认问题定位是否正确及修正思路

• 确认完毕后修改代码及上线计划文档后，重新进入上线流程