预发环境--产品质量的最后一道防线

2022-04-26  本文已影响0人  天草二十六_简村人

目标

1、对于大多数应用,可以在白天验证并发布。

2、让预发环境更贴近生产环境,而不是测试环境的拷贝。(现在的预发环境连接的数据库数据和生产环境相差很大)

3、以低成本对新版本程序的上线验证,而不会影响真实用户对旧版本程序的请求。

4、便于在预发环境跟踪定位线上的问题。(甚至可以在预发环境断点调试线上的疑难问题,可能是数据不一致导致,也可能是因为网络不一致导致)

背景

我们现在的发布特点是:晚上11点开始执行发布,先执行数模、修改配置项,再是对应用程序的滚动发布,最后是测试人员介入--开始验证。

当遇到不明确的问题或者调整的功能点比较多,那么验证的周期就会被延长。最后测试人员根据线上运行情况,告诉运维人员是回滚还是验证通过。

有几个地方值得改进:

一、发布环境

预发 生产 是否共用
数据库等中间件(mysql/mongodb/redis/es) 生产 生产
DNS(域名解析) 预发 生产
API网关 预发 生产
注册中心 预发 生产
xxl-job 预发 生产
MQ(发布订阅模式) 预发 生产
配置中心 预发 生产
应用程序 1.1.x版本(高版本) 1.0.x版本(低版本)
预发环境与正式环境.png

二、预发环境与生产环境的区别

1、访问的域名不同

虽然它们的域名均是对外的,但是预发环境的域名不对外。

2、应用节点的个数不同

预发环境往往只需要一个,而生产环境至少两个。

三、蓝绿发布与灰度发布的区别

1、灰度发布是不同版本共存,而蓝绿发布是新旧版本替换。

(因为有了预发环境,以比较低的成本,允许不同版本的程序共存,方便上线前的最后验证)

2、灰度发布一定是需要灰度规则的,蓝绿发布则是通过不同域名将真实用户的请求和我们的测试请求隔离开来。

3、灰度发布,适用于对产品的A/B测试,对流量分发可以精准控制,给产品和运营人员进行对比分析;

四、蓝绿发布与滚动发布的区别

1、蓝绿发布是会将测试和真实流量进行隔离开来,而滚动发布是没有做流量切换,新旧版本的程序均可能同时接受请求。

2、滚动发布,相对比蓝绿发布,无法确定Ok的环境,不易回滚。

五、适用场景

1、无数模变更的发布,毫无疑问,适用于蓝绿发布。

2、使用生产数据做验收测试。减少因使用测试数据导致的漏测,加强数据兼容测试。

(比如说,支付服务中的商户ID、密钥、证书等,只有在生产环境才存在,而无法在非生产环境得到充分验证)

3、避免因为环境的差异,而影响至测试和产品等部门对迭代功能的验收。

4、贴近线上环境,且作为上线前的最后一道流程,可排除上生产环境时出现的缺少配置或缺少数据等问题。

五、注意点

1、测试

在测试环境,需要整理出完善的配置项修改清单、数模变更清单;尽量减少遗漏或错误,这一点要求更加严格。

2、DBA

执行数模前,DBA和开发负责人根据锁表等影响进行分析,选择合适的时间点进行。

比如,预计应用程序的发版时间为12月10日下午,如果考虑到执行影响用户的使用体验,可以提前在12月9日晚上11点执行数模变更。

另外,数模变更后期纳入系统审计里,让整个数模变更更加规范。

概括来说,数模又分为DML和DDL语句。

举例说明:用户表,原先有user_id, user_name, age, desc等字段,此次功能迭代,增加了gender性别属性,不需要了age年龄属性。

错误示例:``alter table student add gender varchar(``8``) not ``null` `COMMENT ``'性别'``;
``alter table student drop age;
正确示例:``alter table student add gender varchar(``8``) not ``null` `COMMENT ``'性别'``;`` ``-- 不能删除新版本不需要的字段age,因为旧版本还依赖于字段age。

3、开发人员

六、发布流程

1、在预发环境执行数模变更,修改分布式配置项。

2、重启预发环境的应用

3、配置xxl-job的分布式任务

4、预发验证,待成功后,开始发布正式环境的应用,类同预发环境的操作(数模、配置、xxl-job、api网关)

5、把预发环境下的Jar包下发到正式环境的目标机

6、在正式环境,进行滚动发布

上一篇 下一篇

猜你喜欢

热点阅读