内部做一个新的环境，在更新生产环境前先把生产服务等先在这个服务上过一遍，确认没问题后再上生产，这个环境叫什么环境？这种流程叫什么流程？
chaoyebugao 2 小时 28 分钟前 585 次点击想了解大家发布生产前会不会有这样一个环境？我这目前没有，每次发布的服务一多就手忙脚乱，神经紧绷，一点都不丝滑。现在我这的做法是：
- 一两天前确定 [发布计划]
- 所有人准备 [发布说明] + 合并分支
- 然后由我打镜像，准备发布事项
- 更新生产镜像、SQL 、TerraForm 等事项
- 宣布更新完成，测试员回归
以上流程，是直接更生产，回归期间有问题直接修复，如果到了业务敏感时间段还得申请才能走 hotfix ，很多时候都会消耗一天的时间才能完成一次迭代。不是说发布前测试完就能在生产上避免问题，来自工程管理上的细节太多了，问题会像噪声一样溢出到生产。所以才想着一般是不是做一个这样的环境去做回归，然后才上生产，然后二次回归。
这样的环境叫什么？预发布环境？蓝绿部署？关键是，大家会不会这么做？
 | 1 leehaoze98 2 小时 22 分钟前 预发布环境/沙盒环境，会和线上连同一个数据库之类的，在请求里携带特殊 Cookie 之类的，线上域名的流量会转发到这个环境，然后 PM 和 QA 走查 |
 | 2 shakaraka PRO  1 sit -> uat -> prod |
 | 3 chaoyebugao OP @leehaoze98 听起来像是 UAT ，又像 A/B 测试 |
 | 4 yolee599 2 小时 19 分钟前 via Android 预发布环境 |
| 5 chaoyebugao OP @shakaraka 你们 UAT 和生产共用数据库吗？ |
 | 6 wuxilaoshiren 2 小时 19 分钟前 预发 |
 | 7 itechify PRO 1 不通场景不同叫法，挺多的，团队内达成共识吧 Staging 预发布环境 Canary 灰度 Pre-production 准生产 UAT 验收测试 |
| 8 leehaoze98 1 小时 57 分钟前 @chaoyebugao 此环境不面向用户，给内部使用的，部署可能就一台机器，用来回归 |
 | 9 Rickkkkkkk 1 小时 55 分钟前 一般叫预发。 |
| 10 chaoyebugao OP 这种环境弄起来对我们来说可能太复杂了，因为我们有很多数据流，还有第三方服务。这个环境按我理解知识要发版前才会有，发版过后就销毁了，但要维护一整套环境成本也是个问题，从前端 Web 、K8s 、持久化存储都要多一套环境。也就是说，这种环境，从 env 子域名、Web 发布静态文件、K8s 集群、Redis 、数据库等都要有一套独立的？当要迭代时从生产 Copy 过来，然后发布到此环境，发布生产后销毁此环境 |
 | 11 ZARRO 1 小时 39 分钟前 via Android 共用数据库其实也有很大隐患，前司几次生产事故就是由预发布环境引起的，后来就下线了这个环境(下线的过程中也出现了几次生产事故)。通过引入预发布环境来解决工程管理问题，但却又因此引入了一个新的工程管理问题…… |
 | 12 hikarumx 1 小时 30 分钟前 预发环境 |
| 13 shakaraka PRO @chaoyebugao #5 不共享。每个环境单独一套 |
 | 14 ccpp132 1 小时 22 分钟前 你想稳就先测试环境 QA ，没问题再预发布环境给内部用户用一阵子，再灰度升级线上机器 |
| 15 chaoyebugao OP @ccpp132 老板：互联网就是要快 |
| 16 chaoyebugao OP @ZARRO 那就资源尽量隔离掉不就行了，对开发和测试都很友好的环境下线了可惜... |
 | 17 layxy 1 小时 8 分钟前 预发环境或者灰度环境 |
 | 18 KagurazakaNyaa 1 小时 2 分钟前 我们一般把这个叫 stag 环境，dev->stag->prod development 是内网的多套环境，用来即时测试，非 stable 标签的镜像不会进入 stag staging 是一套用于测试的环境，和 prod 完全同构，stable 镜像必须先发布到 stag 才能发布到 prod production 就是生产环境了，镜像来自 stag 环境 |
 | 19 cloudzhou 1 小时 2 分钟前 @ZARRO 预发布环境就是要接近线上到这一步，和发布就一步之差了，甚至我们之前预发布，其实也是线上的一部分 所以，预发布反而就是需要完全的线上环境，否则就失去意义了 反而这折射出你们预发布滥用了 好的预发布，就是线上环境，通过路由等手段进行发布前真实流量校验，才达到降低风险的目的 我以前设计过一套方案，在线上环境下，慢慢灰度指定的服务，可以控制到百分比，甚至可以慢慢灰度一天 |
 | 20 cctv6 1 小时 2 分钟前 我们以前是叫预发布环境。这个环境数据库用的也是生产的数据库，但是正式的请求不会被访问到这些实例上。有时候会通过手动控制上层的网关，把一部分请求转发到这个环境上，在紧急的时候会直接把客户端的请求转发到这个环境中。等运行一段时间后，确定没有内存泄漏、程序异常后，再把预发布的镜像全量更新到生产环境上。这么做的目的其实就是验证上生产的镜像是不是正常的，以及新更新的接口有没有问题。 |
| 21 ZARRO 45 分钟前 via Android @cloudzhou 是的，这说明你们工程管理很优秀。但楼主的问题就是工程管理问题，所以我认为预发布环境不是解决楼主问题的关键。 如果功能可以在预发布环境回归验证，那么就可以在线上环境回归验证。如果不好验证，或者影响面很大、需要灰度，那开发的时候做灰度逻辑，而不是依赖环境。预发布环境优点是数据真实，且不受未发布的功能影响。 |
 | 22 misaka19000 40 分钟前 gray |
| 23 ZARRO 35 分钟前 via Android @cloudzhou (不小心点了回复) 但是缺点是由于共享 db 导致无论如何都无法保证不影响线上数据。由于公司各个服务调用链路比较复杂，一时无法解决，而影响线上数据又是无法忍受的，所以就下线了预发布环境。取而代之的是加强对测试环境的管理。不受未发布的功能影响→任何需求都通过泳道发布互不影响(也就是一个需求一个环境，但共享测试环境数据库)，只有当天要上线的需求由 qa 合到测试环境进行回归(在此之前先在泳道验收)，然后每天自动将 master 分支发到测试环境。数据真实→qa 自动化测试用例。 至于配置相关的内容则是通过发布计划、金丝雀发布去解决的 |
| 24 ZARRO 33 分钟前 via Android @chaoyebugao 是的，最终决定把数据库也隔离了，也就是变成了测试环境。 |
 | 25 superhack 6 分钟前 staging |
 | 26 levelworm 3 分钟前 via iPhone preprd? 反正别和 pre 混在一块就行了。 |
Select Language