系统提测及上线规范(系统上线必读!)

 

 

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

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 共同确认问题定位是否正确及修正思路

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

原文地址:https://www.cnblogs.com/aspirant/p/11944198.html