Skip to content

发布到生产环境

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

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

使用 SuccApp 在 Git、测试环境和生产环境之间同步元数据的流程图

环境职责

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

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

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

推荐发布流程

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

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

测试环境开发

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

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

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

准备生产工作区

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

生产工作区应满足:

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

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

注意

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

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

确认生产服务器差异

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

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

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

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

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

对比生产差异

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

重点确认:

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

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

推送生产环境

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

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

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

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

生产验证

生产验证至少应包含:

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

回退方案

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

常见回退方式:

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

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

发布前检查清单

发布生产前请确认:

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

生产环境操作

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

微信公众号微信公众号:山川软件