什么是预发布环境?上线前先测试
预发布环境是应用的私有副本,尽可能与线上版本保持一致,你可以在真实用户看到改动之前在那里进行测试。它使用自己的数据库、测试数据和测试 API 密钥,因此那里出现的功能故障或错误的数据改动不会影响团队之外的任何人。当改动在预发布环境中表现正常后,你再将其发布到生产环境,也就是客户正在使用的线上应用。
用 AI 建站时,预发布环境为什么重要
用 AI 开发让改动变得很快。几分钟之内,你就可以添加一个功能、重写一个页面或修改数据结构。这种速度很好,直到某个在你看来没问题的改动悄悄破坏了结账流程,或者一次“小小的清理”删除了一列客户数据。
在改动上线之前有一个检查的地方,可以帮你:
- 在客户发现问题之前发现故障。 每次重大改动之后,都要测试注册、支付和其他关键流程。
- 使用接近真实的设置进行测试。 预发布环境应与生产环境表现一致,使用相同的技术栈和相似的配置,这样问题会在那里暴露,而不是之后。
- 保护真实数据。 数据库改动、导入和批量编辑可以先在测试数据上演练。
- 展示进行中的工作。 客户或同事可以在改动不公开的情况下审阅它。
日常类比
可以把它想象成剧院的彩排。
- 开发环境是排练室:演员试背台词、停下、重来、尝试各种可能。
- 预发布环境是彩排:穿上全套戏服,站在真正的舞台上,灯光齐备,一切都与正式演出时一样,只是没有付费观众。
- 生产环境是正式演出之夜。出错时,所有人都在场看着。
大多数你不希望在正式演出之夜出现的问题,都会在彩排时暴露出来:换装耗时太长,或者某个灯光提示有误。这正是预发布环境的职责。
三种常见环境
| 开发环境 | 预发布环境 | 生产环境 | |
|---|---|---|---|
| 用途 | 构建和尝试 | 发布前的最终检查 | 线上应用 |
| 使用者 | 你或你的开发人员 | 团队、测试人员、客户 | 真实用户 |
| 数据 | 示例数据或虚构数据 | 测试数据或经过清理的副本 | 真实客户数据 |
| API 密钥 | 测试密钥 | 测试密钥(例如支付的测试模式) | 正式密钥 |
| 稳定性 | 经常出错,这没关系 | 应当稳定 | 必须稳定 |
| 网址 | 本地或私有预览 | 私有或受密码保护的网址 | 你的公开域名 |
各个环境之间的主要差别在于它们的配置:连接哪个数据库、使用哪些密钥、运行在哪个网址。这就是为什么优秀的应用会从环境变量和密钥中读取这些设置,而不是把它们写死在代码里。同一份代码就可以在每个环境中运行,只是设置不同。
实例:修改预约应用的取消规则
你经营一个有付费客户的美发预约应用。你想把规则改为客户可以在预约前 24 小时取消,而不是 48 小时,并且退款自动完成。
1. 在开发环境中构建。 你向 AI 建站工具提出这个改动。它会更新取消逻辑,以及调用支付服务商进行退款的代码。
2. 发布到预发布环境。 预发布环境运行相同的代码,连接到预发布数据库(包含测试预约)以及支付服务商的测试模式密钥。
3. 测试真实流程。 你和一位同事:
- 预约一个明天的测试服务,并在 30 小时前取消,应当退款;
- 尝试在 10 小时前取消,应当被拒绝,并给出清晰的提示;
- 检查退款是否出现在支付服务商的测试后台中;
- 检查确认邮件中写的是 24 小时,而不是 48 小时。
4. 发现问题。 在预发布环境中你注意到,规则使用的是服务器的时区,而不是沙龙所在的时区,因此截止时间相差一小时。你修复后再次测试。
5. 发布到生产环境。 只有到这时,改动才会送达真实客户,而时区的问题已经被提前发现。
如果没有预发布环境,第 4 步就会发生在某位真实客户的退款上。
关键术语
| 术语 | 含义 |
|---|---|
| 环境(Environment) | 你的应用的一个正在运行的副本,拥有自己的设置、数据和地址。 |
| 生产环境(Production / prod) | 真实用户所依赖的线上环境。 |
| 预发布环境(Staging) | 用于最终测试的、与生产环境相似的副本。 |
| 开发环境(Development / dev) | 改动首先被构建和尝试的地方。 |
| 预览环境(Preview environment) | 为某一项改动创建的短期应用副本,通常自动生成。 |
| 部署 / 发布(Deploy / release) | 将某个版本的代码放入一个环境中。 |
| 回滚(Rollback) | 在一次有问题的发布之后,恢复到之前可以正常工作的版本。 |
| 环境一致性(Environment parity) | 预发布环境与生产环境的相似程度。越接近,就越有用。 |
| 种子数据(Seed data) | 为测试而加载到非生产数据库中的示例数据。 |
常见误解
- “预发布环境可以共用生产数据库。” 这是最危险的捷径。一个删除或编辑记录的测试会直接影响真实客户。请为预发布环境配置独立的数据库。
- “只要在预发布环境中能运行,生产环境就不会出问题。” 预发布环境能降低风险,但无法消除风险。真实流量、真实数据和外部服务仍可能带来意外。请保留回滚的方法。
- “预发布环境必须很贵。” 它可以很小,它需要的是与生产环境相同的配置,而不是相同的规模。
- “为了更真实,在预发布环境中使用正式支付密钥。” 请使用服务商的测试模式。真实并不意味着使用真钱。
- “预发布环境只适合大团队。” “先在安全的地方测试”这一理念,即使对一个人来说也很有用。仪式感的多少可以根据利害关系来调整。
- “预发布环境应当公开,方便大家试用。” 应保持私有或受保护,并阻止搜索引擎收录,以免有人把它误认为真正的应用。
向你的 AI 建站工具提出什么要求
- “让每一项与环境相关的设置(数据库、API 密钥、站点网址)都从环境变量中读取。”
- “添加一个种子脚本,为非生产数据库填充逼真的测试数据。”
- “在我决定上线之前,使用支付服务商的测试模式。”
- “在这项改动上线之前,列出我应当测试的流程,以及每个流程应有的结果。”
- “这项改动会影响现有数据吗?请先给我看迁移方案。”
- “确保非生产环境的网站副本不会被搜索引擎收录。”
如需分步设置指南,请参阅如何设置预发布环境。一旦发布变得频繁,把代码到预发布再到生产的路径自动化,就是 CI/CD 的用途。
Mythex 中的发布前测试
Mythex 没有单独的“预发布与生产”切换开关;发布会给你一个公开的线上网址,文档对此也有明确说明(参见多服务应用)。它所提供的,是构建与上线之间的清晰界限:
- 预览(Preview) 在你构建时,将应用运行在私有的云端沙盒中。改动会先出现在这里,而不是你的线上应用中。
- 分享(Share) 会创建预览链接,让客户或同事无需 Mythex 账号、也无需你发布,即可审阅进行中的工作。该链接显示沙盒当前的状态,包括构建过程中的改动,并且你随时可以删除它。
- 发布(Publish) 对项目进行快照并部署。在你再次发布之前,线上应用保持原样。
- 检查点(Checkpoints) 会在每一轮 Agent 成功执行后保存,因此如果某项改动出错,你可以还原项目文件。
请把预览当作你的彩排:在上线前让支付服务商保持测试模式,并在每次发布前走一遍关键流程。一旦涉及真实客户,在测试任何会写入或删除数据的操作之前,先问一下 Agent 你的预览使用的是哪个数据库和哪些密钥。如果你需要一个拥有独立数据库的完整预发布环境,请让 Agent 为你的项目解释可选方案;或者在 Pro 版中导出项目,或将其同步到 GitHub,并在你自己控制的基础设施上运行。
常见问题
简单来说,什么是预发布环境?
预发布环境是应用的一个私有副本,尽可能与线上版本保持一致,你可以在真实用户看到改动之前在那里测试。如果那里出了问题,团队之外的人不会受到影响。
预发布和生产环境有什么区别?
生产环境是真实用户和真实数据所依赖的线上应用。预发布环境则像彩排用的副本,它的配置与生产环境相同,但使用独立的测试数据和测试密钥,让你可以安全地尝试改动。
预发布环境会使用和生产环境相同的数据库吗?
不应该。预发布环境应当有自己的数据库,里面放测试数据,或经过清理的生产数据副本。共用数据库意味着一次测试就可能修改或删除真实客户的记录。
小型应用需要预发布环境吗?
不一定需要完整的环境。一个人的项目通常靠私有预览、检查清单和回滚能力就够用了。一旦涉及真实客户、支付或团队,一个单独的测试场所就变得非常有价值。