版本、上线与回滚
查看状态与历史
xdbapp status
xdbapp deployments
xdbapp inspect <deployment-id>
三个命令分别回答不同问题：
| 命令 | 回答的问题 |
|---|---|
status | 当前项目关联了哪个 App，Production 是否健康 |
deployments | 这个 App 发布过哪些版本，各自处于什么状态 |
inspect | 某一个版本的详细信息、失败原因和地址是什么 |
打开应用
xdbapp open
xdbapp open --preview <deployment-id>
open 只是在浏览器打开地址：默认打开当前 Production；带 --preview 时打开指定且仍可用的 Preview。它不会修改本地代码、重新启动历史版本或切换线上版本。
重新试用历史版本
历史 Preview 已停止时，可先把仍在保留期内的版本重新挂到测试环境：
xdbapp preview <deployment-id> --yes
xdbapp open --preview <deployment-id>
preview 会替换当前 Preview 的指针和运行实例，因此需要 --yes 确认；不会改变 Production，也不会重新上传本地项目。超出保留期或制品已经清理的版本无法恢复。商家后台的“版本管理”也提供相同的预览恢复操作。
Promote 与 Rollback
xdbapp promote <deployment-id> --yes
xdbapp rollback <deployment-id> --yes
promote：正常发布流程。把刚刚在 Preview 验收过的新版本设为 Production；rollback：故障恢复流程。把仍在保留期内、过去运行过的历史版本重新设为 Production。
两者底层都在改变 Production 指向，但操作意图、允许的版本状态和审计记录不同，因此使用不同命令。
如果项目配置了 database.migrate_command，Promote 会先对 Production 数据库运行当前版本的 migration，成功后才启动并切换新 Production；Rollback 不重放历史 migration。
回滚时容器如何处理
平台会从历史制品重新启动一个 Production 实例，完成健康检查后再替换当前实例。历史版本不需要一直占用一个运行中的容器。
数据库不会随代码回滚
回滚只恢复应用代码和对应运行配置，不会自动撤销数据库结构或业务数据变更。数据库迁移需要保持向前兼容；需要修复数据库时创建新的、向前执行的 migration，不要改写已经发布过的 migration。
在商家后台管理版本
管理员和开发者可从“云应用 → 对应应用 → 版本管理”查看发布记录、恢复历史预览、正式上线或回滚。这里显示的是已经上传到平台的版本；本地尚未上传的修改不会出现。
出现版本已变化的提示时，刷新记录再选择目标，避免把旧页面中的版本覆盖到新正式版。发布与后台菜单如何配合，见后台管理与使用。