6 有把握地交付
区分本地预览、仓库集成、主题发布与站点部署,并用对应证据验证每一种状态。
发布是一串可以分别验证的状态。本地预览成功,只能证明内容与主题可以在当前工作区共同渲染; 它并不能证明远端模块标签已经存在,也不能证明公开站点已经部署了这一版本。
为每种交付状态命名
| 状态 | 证据 | 不能证明什么 |
|---|---|---|
| 本地预览 | 站点可以使用指定的本地主题检出完成渲染 | 公开主题版本已经发布 |
| 站点集成 | 内容、配置与依赖变更已经一起审阅 | 托管平台已经部署这些变更 |
| 主题发布 | 不使用本地替换时,公开标签与模块校验和可以解析 | 消费站点已经升级 |
| 站点部署 | 公开版本与代表性路由可以访问 | 每种语言和视口都正确 |
验证最小且有效的范围
在自己的 Starter 仓库中,先执行普通生产构建,再使用已选定的部署 workflow:
确认 hugo mod graph 解析到 go.mod 中预期的公开版本,再按Starter 部署步骤操作。
普通 Starter 站点不需要 npm 构建脚本或同级主题 checkout。如果同时修改 OINK 主题本身,
另按主题开发流程验证。
分别记录本地构建、workflow 结果与公开 URL 检查。
审阅真正渲染出的结果
自动检查可以发现坏链接、重复 ID、无效短代码与无障碍回归,却无法判断 Hero 裁切是否合适, 也无法判断密集表格在手机上是否仍然易读。请在桌面与窄屏下抽查具有代表性的中英文路由, 覆盖导航、主题控件、代码块以及整书输出。
交接事实,而不是暗示
有效的交接应列出变更文件、命令与结果、已知限制,以及尚未发生的下一种状态。引用 表 6-1,准确说明当前到达了哪一步, 不要用一个“完成”混淆验证、发布与部署。