这种环境弄起来对我们来说可能太复杂了，因为我们有很多数据流，还有第三方服务。这个环境按我理解知识要发版前才会有，发版过后就销毁了，但要维护一整套环境成本也是个问题，从前端 Web 、K8s 、持久化存储都要多一套环境。也就是说，这种环境，从 env 子域名、Web 发布静态文件、K8s 集群、Redis 、数据库等都要有一套独立的？当要迭代时从生产 Copy 过来，然后发布到此环境，发布生产后销毁此环境

共用数据库其实也有很大隐患，前司几次生产事故就是由预发布环境引起的，后来就下线了这个环境(下线的过程中也出现了几次生产事故)。通过引入预发布环境来解决工程管理问题，但却又因此引入了一个新的工程管理问题……

预发环境

@chaoyebugao #5 不共享。每个环境单独一套

你想稳就先测试环境 QA ，没问题再预发布环境给内部用户用一阵子，再灰度升级线上机器

@ccpp132 老板：互联网就是要快 😭

@ZARRO 那就资源尽量隔离掉不就行了，对开发和测试都很友好的环境下线了可惜...

预发环境或者灰度环境

我们一般把这个叫 stag 环境，dev->stag->prod development 是内网的多套环境，用来即时测试，非 stable 标签的镜像不会进入 stag staging 是一套用于测试的环境，和 prod 完全同构，stable 镜像必须先发布到 stag 才能发布到 prod production 就是生产环境了，镜像来自 stag 环境

@ZARRO 预发布环境就是要接近线上到这一步，和发布就一步之差了，甚至我们之前预发布，其实也是线上的一部分 所以，预发布反而就是需要完全的线上环境，否则就失去意义了 反而这折射出你们预发布滥用了 好的预发布，就是线上环境，通过路由等手段进行发布前真实流量校验，才达到降低风险的目的 我以前设计过一套方案，在线上环境下，慢慢灰度指定的服务，可以控制到百分比，甚至可以慢慢灰度一天