跳到正文
Decision guide

上线前先确认这条部署路径是可恢复的。

Deployment checklist 覆盖从本地构建到线上验证的关键检查点。它不是泛泛的 DevOps 清单,而是帮助你判断该用静态发布、VPS/CLI、GitHub Action、AI agent 还是自托管控制面。

检查项

Build output

确认构建命令、产物目录和入口文件,不要把本地 dev server 当成生产产物。

Runtime config

列清环境变量、secret、端口、启动命令和运行时依赖。

Domain and TLS

确认临时 URL、自定义域名、TLS 归属和 DNS 变更窗口。

Health and logs

准备 health endpoint、最近日志、失败诊断和状态查看入口。

Rollback

确认能重新部署上一版,或至少有明确的恢复命令和人工缺口。

Cleanup

预览环境、临时资源和失败部署必须有清理路径。

先判断项目形态

静态站点和常驻服务的部署路径不同。先识别 build output、runtime、端口、环境变量和状态依赖,再选择入口。

凭据不能混进代码

SSH key、provider token、数据库 URL 和 API key 应放在本地 profile、Appaloft secret 或 GitHub Secrets,而不是写进仓库。

上线完成不等于验证完成

返回 live URL 只是第一步。还要检查日志、health、deep link、静态资源、错误页和回滚候选。

落地步骤

1

识别部署类型

静态产物、服务、worker、Compose app、PR preview 或自托管控制面。

2

选择入口

本地用 CLI,团队 CI 用 GitHub Action,AI workflow 用 Appaloft skill,静态站点可用 Cloud upload。

3

验证恢复

每次上线都要能找到 status、logs、health、rollback 和 cleanup。

常见问题

这个清单适合哪些项目?

适合静态站点、VPS 服务、GitHub Action、AI agent 部署和自托管控制面。

部署成功后还要检查什么?

至少检查 URL、关键页面、静态资源、health、最近日志、错误处理和回滚路径。

什么时候不该用静态发布?

当项目需要 API route、SSR、worker、cron 或常驻 Node/容器进程时,应走服务部署路径。

相关主题

继续沿着同一条部署路径看。

Appaloft 的 SEO 页面按真实部署任务组织。每个主题页都应该把用户带到下一步,而不是停在孤立介绍。