2 篇博文 含有标签「staging」

你可以搭建一个预发布数据库。你可以搭建预发布队列、预发布支付沙箱，以及你所依赖的每一个第三方 API 的预发布副本。三十年来，整个预发布（pre-production）学科都建立在一个假设之上：你可以创建一个足够忠实于生产环境的副本，对其进行测试，并从中了解到发布后会发生什么的真实情况。

然后，你将托管模型添加到了关键路径中，这个假设便悄然瓦解了。那个现在主导你产品行为的组件——决定你的应用实际上在说什么、做什么的那个东西——正是你无法搭建预发布副本的唯一组件。它由别人进行版本管理，由别人进行速率限制，并由别人按照你无法察觉的时间表悄悄更新。你的预发布环境拥有一切的预发布副本，唯独没有预发布模型。

我认识的一个团队有一套教科书级别的 staging 设置。生产数据库的只读副本。一个假装会扣款的 Stripe 模拟账户。带着没人拥有的域名邮箱的合成用户。这个 agent 被要求在 staging 里端到端走一遍"账户欠费"的升级流程,作为发版演练的一部分。trace 看起来很干净,agent 做了它该做的事。

三分钟后,一个真实客户——一个付费客户,六个月前流失的,但仍然留在一个开发者用来播种测试数据的休眠导出里——回复了一封措辞礼貌的逾期付款邮件。那个"send_email"工具,与十几个其他全部以 mock 收尾的工具注册在一起,却接在了生产环境的 Mailgun key 上。两个 sprint 前配置它的开发者当时在快速迭代邮件模板,沙箱层级把发送量限制在每小时五封,把内部反馈循环搞坏了,于是他们换上了真 key"就用一下午",然后忘了换回去。没人复查过。agent 没有任何办法知道这件事。