上线规范
1)限制线上jenkins发布权限,运维操作
2)系统上线要经过多方确认,需要确认的人包括:
必须确认人:技术负责人、集成测试负责人、uat测试负责人;(由于暂时还没有专职的测试人员,不一定每个项目都经过有严格的集成测试,测试人员预计一个月后到位)
可选确认人:公司领导、产品负责人、数据负责人。
3)模块负责人决定是否需要公司领导、产品负责人、数据负责人确认,技术负责人把关;上线邮件抄送公司领导及各负责人。
4)鉴于现在人比较少且素质也都比较高,为了不降低效率,流程使用口头沟通确认,表单备份,事后追溯的方法执行。
5)严格执行 集成测试->uat测试->上线 步骤。
6)jenkins不再从master分支直接拉代码,gitlab上先打tag,从tag上拉代码,这样如果发布失败,可以回滚。接下来技术上马上做如下事:
6.1)保证全员都知道在gitlab上打tag的方法
6.2)修改jenkins配置,从git tag上拉代码,原来是从branch上拉代码
6.3)把现有的可执行代码打一个版本,作为基准版本号,统一为1.0
6.4)后续版本号如果产品规定了,使用产品规定的版本号,如果产品没有规定,模块负责人指定版本号
7)写一个技术发布流程规范文档,内容包括:
7.1)灰度发布:切流量 -> 确认节点没有事务在处理 -> 升级节点 -> 流量切回 -> 同样方式升级其他节点
7.2)停服务发布:确认客户都已被通知到 -> 流量切到维护接口 -> 全部发布服务 -> 业务确认 -> 切回流量
目标是在一段时间内所有发布都可做到灰度发布。
8)如果能做到灰度发布,在系统负载不高时操作即可,可由运维人员自行决定发布时间;
如果不能做到灰度发布,需晚上10点之后执行。
9)发布前做好回滚执行方法。(回滚版本,如有数据库变更,需编写回滚脚本)
10)此流程管理范围为在线系统,不包括离线系统。
在线系统包括:SAAS、信审系统、反欺诈系统、数据产品(包括爬虫、外部数据源、数据组装、其他基础服务等…)、日志数据采集、计费
离线系统包括:监控&预警、数据仓库
11)uat环境仍然由模块负责人自行发布。
12)以上过程使用一个表单记录,并在svn中备份。
表单由模块负责人填写,研发负责人最后确认,并抄送给公司领导和各负责人
需要填写的表单项:
(1) 发布编号:${systemId}-${date}-${number}
(2) 更新内容:对实现需求的描述
(3)集成测试确认人:姓名
(4)集成测试确认结果:通过
(5)uat测试确认人:测试人姓名,每个业务模块都需要
(6)uat测试确认结果:通过
(7)是否需要产品负责人确认:是 | 否
(8)产品负责人:姓名 | 无
(9)是否需要数据负责人确认:是 | 否
(10)数据负责人:姓名 | 无
(11)是否需要公司领导确认:是 | 否
(12)公司领导:姓名 | 无
(13)是否灰度发布:是 | 否
(14)是否需要通知客户:是 | 否
(15)需要更新的系统&gitlab tag version,数据库脚本名称
(16)上线过程:系统上线的先后顺序
(17)回滚方法:系统回滚的版本号、数据库回滚脚本名称
(18)需要留守的人:姓名,一般包括技术和uat负责人
(19)开始时间:
(20)结束时间:
(21)上线结果:
(22)失败原因:
13)1-18由模块负责人填写;19-22由运维人员填写。上线后发送给相关人员
流程:
1)模块负责人填写上线文档,并做相应的git tag、sql脚本、回滚sql脚本,sql脚本上传到svn,将文档发送给运维,抄送文档中需要确认的各负责人。
2)如果需要,运维通知需要留守的人,何时留守
3)运维操作上线,上线后完成上线文档
4)把文档上传到上线审计系统
**
如何判断是否可以灰度发布?
数据库脚本尽量不删字段,保证与之前版本的兼容性。
接口设计保持与之前版本的兼容性,如不能保证,则在升级接口版本的同时,保留原接口,待没人使用后再删。
继续阅读
- 我的QQ
- QQ扫一扫
-
- 我的头条
- 头条扫一扫
-
评论