这是一个创建于 240 天前的主题，其中的信息可能已经有所发展或是发生改变。
想了解大家发布生产前会不会有这样一个环境？我这目前没有，每次发布的服务一多就手忙脚乱，神经紧绷，一点都不丝滑。现在我这的做法是：
以上流程，是直接更生产，回归期间有问题直接修复，如果到了业务敏感时间段还得申请才能走 hotfix ，很多时候都会消耗一天的时间才能完成一次迭代。不是说发布前测试完就能在生产上避免问题，来自工程管理上的细节太多了，问题会像噪声一样溢出到生产。所以才想着一般是不是做一个这样的环境去做回归，然后才上生产，然后二次回归。
这样的环境叫什么？预发布环境？蓝绿部署？关键是，大家会不会这么做？
 |
1 leehaoze98 2025 年 10 月 16 日预发布环境/沙盒环境，会和线上连同一个数据库之类的，在请求里携带特殊 Cookie 之类的，线上域名的流量会转发到这个环境，然后 PM 和 QA 走查 |
 |
2 shakaraka 2025 年 10 月 16 日 1
sit -> uat -> prod |
 |
4 yolee599 2025 年 10 月 16 日 via Android预发布环境 |
 |
7 itechify 2025 年 10 月 16 日 2
不通场景不同叫法，挺多的，团队内达成共识吧 |
 |
10 chaoyebugao 2025 年 10 月 16 日这种环境弄起来对我们来说可能太复杂了，因为我们有很多数据流，还有第三方服务。这个环境按我理解知识要发版前才会有，发版过后就销毁了，但要维护一整套环境成本也是个问题，从前端 Web 、K8s 、持久化存储都要多一套环境。也就是说，这种环境，从 env 子域名、Web 发布静态文件、K8s 集群、Redis 、数据库等都要有一套独立的？当要迭代时从生产 Copy 过来，然后发布到此环境，发布生产后销毁此环境 |
 |
11 ZARRO 2025 年 10 月 16 日 via Android共用数据库其实也有很大隐患，前司几次生产事故就是由预发布环境引起的，后来就下线了这个环境(下线的过程中也出现了几次生产事故)。通过引入预发布环境来解决工程管理问题，但却又因此引入了一个新的工程管理问题…… |
 |
14 ccpp132 2025 年 10 月 16 日你想稳就先测试环境 QA ，没问题再预发布环境给内部用户用一阵子，再灰度升级线上机器 |
 |
17 layxy 2025 年 10 月 16 日预发环境或者灰度环境 |
 |
18 KagurazakaNyaa 2025 年 10 月 16 日我们一般把这个叫 stag 环境，dev->stag->prod |
 |
19 cloudzhou 2025 年 10 月 16 日@ZARRO 预发布环境就是要接近线上到这一步，和发布就一步之差了，甚至我们之前预发布，其实也是线上的一部分 反而这折射出你们预发布滥用了 我以前设计过一套方案，在线上环境下，慢慢灰度指定的服务，可以控制到百分比，甚至可以慢慢灰度一天 |
 |
20 cctv6 2025 年 10 月 16 日我们以前是叫预发布环境。这个环境数据库用的也是生产的数据库，但是正式的请求不会被访问到这些实例上。有时候会通过手动控制上层的网关，把一部分请求转发到这个环境上，在紧急的时候会直接把客户端的请求转发到这个环境中。等运行一段时间后，确定没有内存泄漏、程序异常后，再把预发布的镜像全量更新到生产环境上。这么做的目的其实就是验证上生产的镜像是不是正常的，以及新更新的接口有没有问题。 |
|
21 ZARRO 2025 年 10 月 16 日 via Android@cloudzhou 是的，这说明你们工程管理很优秀。但楼主的问题就是工程管理问题，所以我认为预发布环境不是解决楼主问题的关键。 |
|
23 ZARRO 2025 年 10 月 16 日 via Android@cloudzhou (不小心点了回复) 但是缺点是由于共享 db 导致无论如何都无法保证不影响线上数据。由于公司各个服务调用链路比较复杂，一时无法解决，而影响线上数据又是无法忍受的，所以就下线了预发布环境。取而代之的是加强对测试环境的管理。不受未发布的功能影响→任何需求都通过泳道发布互不影响(也就是一个需求一个环境，但共享测试环境数据库)，只有当天要上线的需求由 qa 合到测试环境进行回归(在此之前先在泳道验收)，然后每天自动将 master 分支发到测试环境。数据真实→qa 自动化测试用例。 |
|
24 ZARRO 2025 年 10 月 16 日 via Android@chaoyebugao 是的，最终决定把数据库也隔离了，也就是变成了测试环境。 |
 |
26 levelworm 2025 年 10 月 16 日 via iPhonepreprd? 反正别和 pre 混在一块就行了。 |
|
28 chaoyebugao 2025 年 10 月 16 日@ZARRO 但测试环境是长期存在的，对应 develop 分支，长期隔离的话和生产环境并不完全一致，数据量和代码上都不同，因为 Git Flow 的话生产对应的 master 或 release 分支 |
 |
29 kaneg 2025 年 10 月 16 日 via iPhone我们叫预览环境，数据库每次升级代码前从生产环境克隆。 |
 |
30 flmn 2025 年 10 月 16 日stg |
 |
31 meiyiliya 2025 年 10 月 16 日我们是 dev -> beta -> preview -> online |
 |
32 gefranks 2025 年 10 月 16 日尽可能模仿生产环境的叫 stage(staging)环境.验证产线包的基本功能和配置,归类于生产环境的一部分, 只是基本上不会把外部用户放到这个环境上, 走上生产环境的流程.有问题的话就是 hotfix+批斗会伺候. |
 |
33 eudore 2025 年 10 月 17 日预发 dev->test->pre->prod |
 |
34 pobo 2025 年 10 月 17 日这个叫预发环境或准生产环境，稍微大点的公司一般都有 |
 |
35 kenshin912 2025 年 10 月 17 日Pre-Production 吧 |
 |
36 jimrok 2025 年 10 月 17 日应该有专门的运维管这个 staging 环境，会从生产拿备份恢复这个 staging ，然后验证升级后的功能，通过后代码打标签，确认发布。然后发布到生产。验证工作一般有写好的自动化测试代码验证核心功能。 |
 |
37 sharpy 2025 年 10 月 17 日moni beta prod |
 |
38 skymei 2025 年 10 月 17 日我们就有这个环境，叫 canary 灰度，和 prod 公用数据，但是仅内部访问，发布验证所用。 |
 |
39 ZzzWatch 2025 年 10 月 17 日sit-> uat -> pp -> prod ,pp 准生产，与生产环境数据一致 |
 |
40 BestPix 2025 年 10 月 17 日dev-release-prod |
|
41 leehaoze98 2025 年 10 月 17 日@chaoyebugao 从线上剥离一台机器或者一个小集群，域名、各类中间件都是相同的，一个不对外提供服务的线上环境，一直在线上活着，只是没有流量而已。如果是微服务的形态，会通过流量染色把回归人员的流量转发到本次上线服务的预发布版本，量很大的服务还会有金丝雀发布，流量是一点点分配到新版本上的 走到这一步已经是在上线流程中了，再点下一步就是单台单边单集群推全量正式上线了，预发布是最后一道防线，在预发布回滚是很严重的事故。 |
 |
43 COW 2025 年 10 月 17 日我们是逻辑上分离内部用户出来，都是一个生产环境，前面有一个集成测试环境。 |
 |
44 i0error 2025 年 10 月 17 日仿真。 |
 |
45 vaynecv 2025 年 10 月 17 日预发环境/Pre |
 |
47 sslyxhz 2025 年 10 月 17 日dev->test->staging->prod 不过都逐步去掉 staging 了 |
 |
48 whoosy 2025 年 10 月 17 日预发布 |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
