上线规范
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扫一扫
-
- 我的头条
- 头条扫一扫
-
评论