再论环境标准化

好久没写文章了，今天简单总结一篇。前一段时间写过几篇持续交付的文章，围绕的问题还是一致性、环境配置管理、服务隔离等。最近有了一些新的体会。

第一个问题说说仿真环境，所谓仿真就是基本上接近线上环境，比如mysql和redis资源都和线上环境一致，系统部署也和线上基本一致的，只是对外隔离了，通过域名来区分。

如果QA环境和线上环境架构不太一致，那么仿真环境的存在非常有意义，对测试人员来说非常重要，这是最后一道把门锁；另外仿真环境也可用于灰度测试。

但由于仿真环境用的数据就是线上的，所以如果测试的时候产生一些脏数据，会让用户看到，这个情况我们就遇到了。

那么如何解决呢？目前想到的方法就是将仿真环境的核心数据（mysql和redis）独立出来，系统部署和线上保持一致，这样有两个好处，首先是仿真，其次数据是隔离的。

为了保障仿真环境的数据是较为真实的，可以定期将线上的数据同步到仿真数据库中，不过一些用户属性数据（比如手机号）需要清除，避免测试的时候干扰了真实用户（比如给他发短信）。

看上去很美好，但对于我们的系统来说，虽然目前有三种环境（QA、仿真、线上），但代码层面并没有很好的支持，隔离的不彻底，导致线上和仿真并没有完全区分，使用的配置也没有中心化（环境变量或集中配置文件），尤其是我们的job服务和admin服务，比如代码中有对于环境的判断，通过下面的伪代码就可以看出来了：

if (环境 == QA) {

} else {

}

相对比较好的做法是代码中不能有对于环境的判断，环境配置一体化（所有的配置可以从环境变量或集中配置文件中获取）。

从这个角度出发，支持真正的仿真环境迫在眉睫。

第二个核心问题是QA环境的使用，我们的QA环境有以下几个弊端：

首先不该测的代码被测试了，比如两个人分别开发v1，v2版本，测试团队只想测试v1，但目前的机制v1和v2都会merge到QA，导致测试的范围不一致，可能会有一些隐性问题。

其次目前的QA环境用于前后端联调，这说明QA服务于前后端和测试，没有做到隔离。

最后QA环境不是一个稳定的环境，因为有的时候为了排查问题，会直接在QA上调试（属于坏习惯），另外QA的代码一直在联调，测试在一个不稳定的环境测试。

目前想到的方法使用一个pre QA环境，主要用户前后端联调或排查问题，QA环境用于测试，merge的频率建议不要太高。

pre QA和QA除了代码部署不一致，数据和系统部署是一致的，但达到了隔离和稳定，缺点有两点：

首先就是merge复杂度变高，不仅要merge到pre QA还要merge 到QA。

其次如何保证 pre QA和QA代码是持续同步的，会不会有人忘记合并到pre QA了？

虽然看上去很美好，但改变了大家的工作方式（大家都习惯了），需要再看看合理性。

最后通过一张图说明：