先判断项目形态
静态站点和常驻服务的部署路径不同。先识别 build output、runtime、端口、环境变量和状态依赖,再选择入口。
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、静态资源、错误页和回滚候选。
静态产物、服务、worker、Compose app、PR preview 或自托管控制面。
本地用 CLI,团队 CI 用 GitHub Action,AI workflow 用 Appaloft skill,静态站点可用 Cloud upload。
每次上线都要能找到 status、logs、health、rollback 和 cleanup。
适合静态站点、VPS 服务、GitHub Action、AI agent 部署和自托管控制面。
至少检查 URL、关键页面、静态资源、health、最近日志、错误处理和回滚路径。
当项目需要 API route、SSR、worker、cron 或常驻 Node/容器进程时,应走服务部署路径。
Appaloft 的 SEO 页面按真实部署任务组织。每个主题页都应该把用户带到下一步,而不是停在孤立介绍。
用检查清单和选择页把搜索用户带到正确部署入口,而不是停在抽象概念。
从 build 输出、浏览器上传、CLI 部署到一键部署按钮,覆盖静态站点的主要入口。
把控制面、CLI、服务器、回滚和 Cloud 协作边界连在同一个自部署主题里。
用 GitHub Actions 把仓库事件接到 Appaloft 部署路径,并保留显式 workflow。
让 agent 先识别项目形态,再选择 skill、CLI、静态发布或 Cloud 控制台路径。