---
title: 发布到生产环境
navTitle: 发布生产
---
# 发布到生产环境

项目通常先在测试环境由人和 AI 共同修改、验证，再将确认过的 Git 版本发布到生产环境。SuccApp 可以帮助用户对比和推送元数据，但生产同步必须配合 Git、评审和业务验证流程使用。

AI 可以参与整理发布说明、检查 diff 和生成回退建议，但不应在没有人工确认的情况下直接推送生产环境。

![使用 SuccApp 在 Git、测试环境和生产环境之间同步元数据的流程图](../images/test-to-prod-flow.png)

## 环境职责{#responsibility}

推荐将不同环境的职责区分清楚：

| 环境或工具 | 职责 |
| :--- | :--- |
| 测试环境 | 日常修改、调试、功能验证 |
| Git 仓库 | 保存经过验证的元数据版本 |
| 生产环境 | 客户正式使用环境，只接收已评审版本 |
| SuccApp | 在本地和服务器之间同步元数据 |

不要把生产环境当作日常调试环境。

## 推荐发布流程{#flow}

从测试环境同步到生产环境，建议按以下流程：

1. 在测试环境完成修改。
2. 使用 SuccApp 推送测试服务器并验证。
3. 提交 Git。
4. 团队评审本次变更。
5. 准备生产发布工作区。
6. 切换到已评审的 Git 版本。
7. 连接生产服务器。
8. 执行 **SuccApp: 刷新变化**（英文界面为 **SuccApp: Refresh Changes**）。
9. 对比生产差异。
10. 推送生产服务器。
11. 完成生产业务验证。
12. 记录发布结果和回退方式。

## 测试环境开发{#test-dev}

测试环境中可以使用较高频率的修改和推送流程：

1. 本地修改元数据。
2. 查看 Changes 差异。
3. 推送测试环境。
4. 在浏览器或设计器中预览。
5. 修复问题后继续小步推送。

测试通过后，再提交 Git。不要把未验证的临时修改提交到稳定分支。

## 准备生产工作区{#prod-workspace}

生产发布前建议使用干净的生产发布工作区。

生产工作区应满足：

1. Git 已切换到准备发布的版本。
2. 已配置生产服务器。
3. 未开启自动推送。
4. 已连接生产服务器，并按生产服务器刷新变化。
5. Git 工作区没有未提交本地修改。

如果是首次准备生产发布工作区，建议先从 Git 拉取已评审版本，确认本地已经存在要发布的项目目录，再连接生产服务器并执行 **SuccApp: 刷新变化**（英文界面为 **SuccApp: Refresh Changes**）。

::: warning 注意
当前版本不提供单独只刷新 mirror、但不修改工作区文件的用户命令。不要用 **从服务器重置本地项目** 代替生产发布前的差异检查，否则本地 Git 版本可能被生产服务器内容覆盖。
:::

如果同一个工作区同时配置测试和生产服务器，切换到生产服务器后应先执行 **SuccApp: 刷新变化**（英文界面为 **SuccApp: Refresh Changes**），不要用测试服务器状态判断生产差异。

## 确认生产服务器差异{#prod-baseline}

SuccApp 会通过 Changes 视图展示“待发布 Git 版本”和“生产服务器当前版本”之间的差异。生产发布前应先连接生产服务器并刷新变化。

推荐按以下方式确认差异：

1. 打开干净的生产发布工作区。
2. 从 Git 切换到本次准备发布的版本。
3. 连接生产服务器。
4. 执行 **SuccApp: 刷新变化**（英文界面为 **SuccApp: Refresh Changes**）。
5. 打开 Changes 视图，确认本地变化、远端变化和冲突符合预期。

完成后，Changes 视图中看到的本地变化，表示本次 Git 版本准备推送到生产服务器的差异；远端变化或冲突需要先确认来源，不能直接忽略。

如果本地还没有项目目录，可以先从 Git 拉取项目文件。如果确实需要通过生产服务器创建初始工作区，可以先克隆生产项目，再初始化或切换到团队 Git 仓库中的发布版本，最后刷新变化。

## 对比生产差异{#compare-prod}

推送生产前，必须查看 SuccApp Changes 视图。

重点确认：

1. 本地变化是否就是本次发布内容。
2. 是否有生产服务器上的远端变化尚未处理。
3. 是否存在冲突。
4. 是否出现无关文件或大量格式化差异。
5. 是否包含不应发布的临时测试配置。

如果生产服务器有远端变化，应先确认这些变化来源。不要直接强制覆盖。

## 推送生产环境{#push-prod}

确认差异无误后，再执行推送。

推送生产前建议由发布负责人进行最后确认：

1. Git 版本正确。
2. 评审已通过。
3. 变更范围明确。
4. 已有回退方案。
5. 当前连接的是生产服务器。

推送完成后，应立即进行业务验证。

## 生产验证{#verify-prod}

生产验证至少应包含：

1. 打开受影响页面。
2. 完成一条核心业务流程。
3. 检查脚本控制台或系统日志是否有异常。
4. 确认权限、数据范围和页面显示符合预期。
5. 通知相关人员验证结果。

## 回退方案{#rollback}

生产发布前应准备回退方案。

常见回退方式：

1. 使用 Git 切回上一个稳定版本，再通过 SuccApp 推送。
2. 使用服务器文件历史对比问题文件，确认后恢复。
3. 使用客户现场既有备份或发布包恢复。

选择哪种回退方式，应由项目负责人根据现场制度决定。

## 发布前检查清单{#checklist}

发布生产前请确认：

1. 本次修改已在测试环境验证。
2. 本次修改已提交 Git。
3. 合并请求或评审已通过。
4. 发布人员清楚本次影响范围。
5. 生产服务器无未处理远端变化。
6. Changes 视图无冲突。
7. 未开启自动推送。
8. 已准备回退方案。
9. 已安排生产验证人员。

::: danger 生产环境操作
生产环境 push 是高风险操作。任何不确定的差异、冲突或远端变化，都应先暂停并确认原因。
:::