我们以前是叫预发布环境。这个环境数据库用的也是生产的数据库，但是正式的请求不会被访问到这些实例上。有时候会通过手动控制上层的网关，把一部分请求转发到这个环境上，在紧急的时候会直接把客户端的请求转发到这个环境中。等运行一段时间后，确定没有内存泄漏、程序异常后，再把预发布的镜像全量更新到生产环境上。这么做的目的其实就是验证上生产的镜像是不是正常的，以及新更新的接口有没有问题。

@cloudzhou 是的，这说明你们工程管理很优秀。但楼主的问题就是工程管理问题，所以我认为预发布环境不是解决楼主问题的关键。 如果功能可以在预发布环境回归验证，那么就可以在线上环境回归验证。如果不好验证，或者影响面很大、需要灰度，那开发的时候做灰度逻辑，而不是依赖环境。预发布环境优点是数据真实，且不受未发布的功能影响。

gray

@cloudzhou (不小心点了回复) 但是缺点是由于共享 db 导致无论如何都无法保证不影响线上数据。由于公司各个服务调用链路比较复杂，一时无法解决，而影响线上数据又是无法忍受的，所以就下线了预发布环境。取而代之的是加强对测试环境的管理。不受未发布的功能影响→任何需求都通过泳道发布互不影响(也就是一个需求一个环境，但共享测试环境数据库)，只有当天要上线的需求由 qa 合到测试环境进行回归(在此之前先在泳道验收)，然后每天自动将 master 分支发到测试环境。数据真实→qa 自动化测试用例。 至于配置相关的内容则是通过发布计划、金丝雀发布去解决的

@chaoyebugao 是的，最终决定把数据库也隔离了，也就是变成了测试环境。

staging

preprd? 反正别和 pre 混在一块就行了。

@KagurazakaNyaa 那 staging 就是一直存在的开发测试环境吧？

@ZARRO 但测试环境是长期存在的，对应 develop 分支，长期隔离的话和生产环境并不完全一致，数据量和代码上都不同，因为 Git Flow 的话生产对应的 master 或 release 分支

我们叫预览环境，数据库每次升级代码前从生产环境克隆。