部署环境怎样设置、谁是审批人，由管理员在 部署环境 里设定；CI 怎样接入，见 连接 CI。
上线的过程
以“供应商管理”项目为例，CI 接入后：
- 任务验收、PR 合并后，CI 把默认分支部署到预发布环境，任务上标出“预发布 ✓ b64c3bd”。
- 打一个版本标签，例如
v1.4.0，CI 构建这个版本，向生产环境部署。 - 生产环境受保护，这次部署变成一份部署申请，送到审批人的收件箱。
- 审批人批准后，部署到生产，任务上标出“生产 ✓ 1.4.0”。
项目概览的「发布」里，能看到每个环境上正在运行哪个版本、来自哪个提交、谁部署的、谁批准的，以及还在等审批的申请。
审批人做什么
部署申请出现在审批人收件箱的「待我决定」里，写明：
- 要部署的应用和环境；
- 要部署的版本，以及它来自的提交；
- CI 构建它时用的标签或分支，以及 CI 的日志；
- 谁发起的：某个人、某个 Agent，或者 CI。
打开申请，核对无误后，再输入一次应用 ID 确认，批准后立即部署。部署的就是申请里的那个版本，之后有了更新的版本，也不会顶替它。不同意时，拒绝这份申请。
谁都不能批准自己发起的申请；Agent 不能批准部署，也不能直接部署到受保护的环境。
部署前先备份
Studio 部署前不会自动备份应用的数据库。生产环境的数据库请自己定期备份，例如定时运行 pg_dump，或者使用数据库服务自带的备份。
回滚
部署后发现问题，在「发布 › 应用」里打开这个应用，在部署记录里选之前一次成功的部署，回滚到它的版本。受保护的环境上，回滚同样会变成一份部署申请，由审批人批准。
回滚后，Studio 会核对每个任务的改动是否还在线上：
- 不再包含在这个版本里的任务，部署标记会撤回，例如“已随 1.3.0 撤回”；
- 已经完成、但改动被撤回的任务，执行回滚的人会收到建议，可以把它们重新打开，也可以忽略。
任务的状态不会自动改变，要不要重新打开，由人决定。
已合并未发布
项目概览的「已合并未发布」，列出已经完成、但改动还没有部署到生产环境的任务。每完成一个这样的任务，项目负责人会收到通知。准备发布新版本时，从这里看这次会上线哪些改动。