第二十四篇：稳定性之多环境建设

前言

在很多互联网公司依然凌晨才能够上线，上线那天面临各种突发情况，导致通宵上线，这些问题都很常见，经常因测试不周且频繁版本变更，及未经充分验证的代码，在线上直接运行出现故障屡见不鲜，适当的变更有助于减少故障的发生，但是无法杜绝后患，在这种情况，如何降低或减少未经验证的代码出现在线上环境，如何在上线日释放人力并有效改善现状。

多环境建设

为了提升产研的迭代效率，通常情况下都会存在多个环境，分别是开发环境、测试环境、预发环境、线上环境，不同环境的职责也不同，对于业务立项、研发、最终上线都会先后经过上述环境，一方面是为了提升产研的效率，另外一方面是验证新业务功能的完善性、正确性及对当前系统的影响以及可靠性和兼容性。

多环境同时也对应Git仓库的多分支，分支用途也不同，分支名称和环境是一一对应的，例如：

●Dev分支：开发分支，对应开发环境，用户内部集成联调、自测

●Test分支：测试分支，对应测试环境，分支代码合并，部署等等，用户功能测试

●Release分支：预发布分支，对应预发环境，用于最后一轮的测试和验证

●Master分支：主分支，对应线上环境，提供线上服务，上线完成后，继续新开发功能再从 Master 分支上拉代码进行新的开发

开发环境

开发环境是供研发工程师使用和维护，是代码最超前版本的一个环境，通常情况下开发环境是被研发工程师用来内部联调测试或者内部集成测试，在新业务的迭代中，任务最终可能拆分到不同研发工程师中，各自都是独立研发完成，最终可能在开发环境上做内部集成测试，只有经过研发工程师内部测试通过的才可提交到测试环境供测试人员进行测试。需要注意的是，在提测时尽可能由owner进行发送提测邮件，邮件内容一般包括：业务功能描述、此次所有的git仓库地址、分支名字、是否配置变更、是否有数据库表结构变更、是否涉及其他依赖、影响范围、功能负责人等等。

测试环境

测试环境是供测试人员使用，一般情况下研发人员是没有权限动测试环境，将研发和测试隔离开，为了使测试结果更加真实有效。在以往的经验中，遇到很多次测试人员在测试环境进行业务测试，研发工程师动了测试环境，导致整个测试阻塞，测试人员在该环境按照测试用例进行测试，经过多轮的测试，直到所有的Bug都被解决掉，最后经项目责任人或产品经理验收测试，一旦完成，等待上线时间进行上线。

预发环境

经过测试验证过且到达上线时间点，在这个过程中，提前预留部分时间，将其发布到预发环境，预发环境最后经过一轮验证，预发环境不论是环境真实性还是数据库更接近线上环境高度仿真，在这个过程中测试人员会再次回归测试一轮，验证是否可达上线状态。

预发环境和测试环境区别

预发和测试环境的区别是预发环境更接近线上环境高度仿真，无论是环境配置还是数据库、配置等都和线上一样，另外还会有线上真实的数据可进行验证，比测试环境更准确，更提升可靠性；面向的用户群体也不同，预发环境可使用更贴近真实用户的数据进行测试验证。

预发环境高度仿真

引入预发环境可以帮助我们解决很多在测试环境发现不了的问题，为了保证预发环境的高度仿真，因此基础环境、配置方面和线上环境保持一致，差别主要是在容量和数据存储上，说到这里可能能够想到面对数据库结构修改，如何保持高度仿真呢。

●容量：预发环境一般是最小单元，不会和线上部署服务器数量一样，通常保持2台，保持基础可用即可，节约成本，缩小规模。

●数据存储：可参考定期备份同步策略，定期和线上的数据保持一致，这样就可解决数据库表结构修改的问题，数据存储一般中等配置即可，更多占用的磁盘存储空间。

线上环境

多环境维护

小结