内部做一个新的环境，在更新生产环境前先把生产服务等先在这个服务上过一遍，确认没问题后再上生产，这个环境叫什么环境？这种流程叫什么流程？

[chaoyebugao]

想了解大家发布生产前会不会有这样一个环境？我这目前没有，每次发布的服务一多就手忙脚乱，神经紧绷，一点都不丝滑。现在我这的做法是：

1. 一两天前确定 [发布计划]
2. 所有人准备 [发布说明] + 合并分支
3. 然后由我打镜像，准备发布事项
4. 更新生产镜像、SQL 、TerraForm 等事项
5. 宣布更新完成，测试员回归

以上流程，是直接更生产，回归期间有问题直接修复，如果到了业务敏感时间段还得申请才能走 hotfix ，很多时候都会消耗一天的时间才能完成一次迭代。不是说发布前测试完就能在生产上避免问题，来自工程管理上的细节太多了，问题会像噪声一样溢出到生产。所以才想着一般是不是做一个这样的环境去做回归，然后才上生产，然后二次回归。

这样的环境叫什么？预发布环境？蓝绿部署？关键是，大家会不会这么做？

[leehaoze98]

预发布环境/沙盒环境，会和线上连同一个数据库之类的，在请求里携带特殊 Cookie 之类的，线上域名的流量会转发到这个环境，然后 PM 和 QA 走查

[shakaraka]

sit -> uat -> prod

[chaoyebugao]

@leehaoze98 听起来像是 UAT ，又像 A/B 测试

[yolee599]

预发布环境

[chaoyebugao]

@shakaraka 你们 UAT 和生产共用数据库吗？

[wuxilaoshiren]

预发

[itechify]

不通场景不同叫法，挺多的，团队内达成共识吧
Staging 预发布环境
Canary 灰度
Pre-production 准生产
UAT 验收测试

[leehaoze98]

@chaoyebugao 此环境不面向用户，给内部使用的，部署可能就一台机器，用来回归

[Rickkkkkkk]

一般叫预发。

[chaoyebugao]

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

[ZARRO]

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

[hikarumx]

预发环境

[shakaraka]

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

[ccpp132]

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

[chaoyebugao]

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

[chaoyebugao]

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

[layxy]

预发环境或者灰度环境

[KagurazakaNyaa]

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

[cloudzhou]

@ZARRO 预发布环境就是要接近线上到这一步，和发布就一步之差了，甚至我们之前预发布，其实也是线上的一部分
所以，预发布反而就是需要完全的线上环境，否则就失去意义了

反而这折射出你们预发布滥用了
好的预发布，就是线上环境，通过路由等手段进行发布前真实流量校验，才达到降低风险的目的

我以前设计过一套方案，在线上环境下，慢慢灰度指定的服务，可以控制到百分比，甚至可以慢慢灰度一天

[cctv6]

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

[ZARRO]

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

[misaka19000]

gray

[ZARRO]

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

[ZARRO]

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

[superhack]

staging

[levelworm]

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

[chaoyebugao]

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

[chaoyebugao]

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

[kaneg]

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

[flmn]

stg

[meiyiliya]

我们是 dev -> beta -> preview -> online
开发只能操作 dev ，提测后由测试同学自动化打包到 beta ，上线当天再由测试自动化打包到 preview ，不过 preview 和 online 用的同数据库，所以这天大部分情况下测试都只会在该环境验证数据的查询操作，基本上只要不涉及到生产环境数据的增删改外都可以验证，没问题后再由运维发到 online 。

[gefranks]

尽可能模仿生产环境的叫 stage(staging)环境.验证产线包的基本功能和配置,归类于生产环境的一部分, 只是基本上不会把外部用户放到这个环境上, 走上生产环境的流程.有问题的话就是 hotfix+批斗会伺候.

[eudore]

预发 dev->test->pre->prod

[pobo]

这个叫预发环境或准生产环境，稍微大点的公司一般都有

[kenshin912]

Pre-Production 吧
我们是 Develop -> Test -> Pre-Production -> UAT -> Production

[jimrok]

应该有专门的运维管这个 staging 环境，会从生产拿备份恢复这个 staging ，然后验证升级后的功能，通过后代码打标签，确认发布。然后发布到生产。验证工作一般有写好的自动化测试代码验证核心功能。

[sharpy]

moni beta prod

[skymei]

我们就有这个环境，叫 canary 灰度，和 prod 公用数据，但是仅内部访问，发布验证所用。

[ZzzWatch]

sit-> uat -> pp -> prod ,pp 准生产，与生产环境数据一致

[BestPix]

dev-release-prod

[leehaoze98]

@chaoyebugao 从线上剥离一台机器或者一个小集群，域名、各类中间件都是相同的，一个不对外提供服务的线上环境，一直在线上活着，只是没有流量而已。如果是微服务的形态，会通过流量染色把回归人员的流量转发到本次上线服务的预发布版本，量很大的服务还会有金丝雀发布，流量是一点点分配到新版本上的

走到这一步已经是在上线流程中了，再点下一步就是单台单边单集群推全量正式上线了，预发布是最后一道防线，在预发布回滚是很严重的事故。

[willamtang]

dev-cons-prod

[COW]

我们是逻辑上分离内部用户出来，都是一个生产环境，前面有一个集成测试环境。

[i0error]

仿真。
dev test pre sim gray prod stable 我司😅

[vaynecv]

预发环境/Pre

[Inn0Vat10n]

阿里系, 这个环境叫预发

[sslyxhz]

dev->test->staging->prod

不过都逐步去掉 staging 了

[whoosy]

预发布

[realpg]

@ZARRO #11
共用数据库不代表使用的账户是公共真实客户的账户
我们搞这个, 都是公司内部员工账户使用

预发布一定是跟线上一模一样的环境 用来发现只有发布到线上环境才可能出现的问题
显然你们这是把一个不应该预发布的版本弄到了预发布的版本上

去掉了预发布这一步, 你们这种用法直接会导致生产环境重大事故