准备好走快速上线流程

草稿准备好了，快速发布才有意义。先用编辑器自动算出来的清单，把可以预料的上线失误清掉。

1. 打开上线指南，把它针对这个项目列出的商家信息、营业时间、真实照片、内容、SEO、按钮去处和手机预览逐项完成。
2. 打开预览，在 Desktop 和 Mobile 测店面。草稿里有经营模块时，后台也要测——完整交付会把后台一起发布出去，你在这里验过的，就是店里的人之后每天在用的。
3. 需要别人批准草稿或反馈意见时，就用审查。
4. 等状态显示已保存，再打开上线。

在浏览器版里，发布是由服务器管控的工作空间能力。服务商的密钥只该放在服务器上，绝对别粘到页面内容或浏览器存储里。

1. 在编辑器顶栏点「上线」。
2. 界面显示无法发布、没有权限或尚未配置时，就停下来，请工作空间所有者去开通。
3. 别拿导出当部署。导出是可移植的文件，不是服务器确认过的线上网站。
4. 确认选中的项目。要等不可变更的发布版本通过上架检查，Naratake 才会给出正式的系统网址；浏览器不会自己编一个服务商子域名出来。

Naratake 生成的是一套完整的 Next.js 应用，背后有数据库；订单、订座、预约、客户这些主要经营模块，都要靠那个数据库跑起来。云端发布对这套应用有两种交付。完整交付会给网站开一套自己的 Postgres 数据库和后台，那些模块会真的上线，客户留下的记录也存得下来。纯店面交付是同一个网站拿掉写入面，拿掉了哪些会逐条列在发布报告里。一个工作空间能请求哪一种，是提交请求时由服务器决定的，不是浏览器说了算：完整交付需要套餐同时包含商务和预约模块，目前就是 Storefront Pro。至于网站本身会有哪些东西，一样是按保存后那一版实际会交付的组件和模块算出来的，不是看模板名称。

1. 看清楚上线界面说这次要交付什么：是带自己的数据库和后台的网站，还是同一个网站的纯店面版本。
2. 生意需要实时订单、预约、客户记录或需登录的后台时，就请求完整交付。套餐里没有商务和预约模块的工作空间，会在动到任何服务商之前先被拦下来，而且被拦的提示会讲明哪个套餐有这一项。
3. 不要为了早一点发布，就把生意需要的模块去掉。要么把工作空间换到包含完整交付的套餐，要么就明明白白地决定先上纯店面交付，在那之前把完整的经营流程留在预览里测。
4. 套餐没有包含的交付方式，别改用桌面版导出、自己的服务商密钥，或手动从浏览器上传来顶替。

警告不一定会挡住部署，但它们讲的是客户看得到的问题。把它们当成一份需要签字放行的清单。

1. 逐条打开警告，弄清楚受影响的是哪一页、哪段内容、哪个模块或哪个环境配置。
2. 客户看得到的问题先修：少了法律条款、还留着示例数据、按钮点了没反应、支付配置没填完。
3. 如果某条警告是刻意接受的，提交上线前把是谁接受的、为什么接受记下来。

部署要花时间，也可能做到一半才失败。真正算数的是云端服务返回的状态，不是你点下去那一刻，也不是浏览器乐观显示的提示。

1. 「上线」只点一次，进度返回期间让项目一直开着。
2. 觉得构建很慢也别一直重提交。重试之前先刷新部署状态或发布记录。
3. 服务器返回错误时，把请求或部署编号和完整信息留下来，按它说的原因修好，再重试一次。
4. 模拟、演练、预览或还在进行中的状态，一律当成还没上线。

最后这关要离开编辑器，直接对着返回的公开网站和它真实的服务器行为来检查。

1. 用无痕窗口打开返回的网址，检查首页、导航栏、法律链接，以及这一版真的带上的每一个行动按钮。
2. 确认公开内容就是审过的那一版，而不是旧的预览。
3. 只有这一版真的带了订单、订座、预约或需登录的后台，才对外这么说。完整交付有带——到返回的网站登录后台，确认测试记录真的进得来；纯店面交付没有，发布报告里会列出它拿掉了哪些。
4. 分享出去之前，用手机打开线上网址看一遍，并确认是 HTTPS。

保存只是更新草稿，不会偷偷改到线上的网站。下一版审好了，再点一次上线。

1. 改完之后等显示已保存，再重跑一遍预览，以及各模块专属的测试。
2. 动到线上模块的改动，部署前要当成会影响数据的决策来审。
3. 再点一次上线，并且像第一次发布那样，把返回的状态和网址验证一遍。
4. 新版还在验证期间，让上一个可用的发布版本保持可用。