#发布管理

#介绍

发布管理用于规范应用从开发到生产的交付过程。它关注的不是单次操作，而是一套可重复、可验证、可回退的发布机制。

生产环境应保持稳定。配置变更先在开发环境完成，再进入预发布环境验证。验证通过后，再发布到生产环境。发布过程中产生的迁移文件、备份、执行日志和验证结果，都应妥善保存，作为后续排查和回滚的依据。

推荐环境如下：

开发环境 -> 预发布环境 -> 生产环境

开发环境用于配置和调整。预发布环境用于还原生产约束并验证发布结果。生产环境用于承载真实业务。三类环境职责清晰后，发布过程才容易管理。

#发布模型

NocoBase 的发布管理通常由五类能力配合完成。

#环境配置：使用变量与密钥

变量与密钥用于隔离不同环境的配置和敏感信息。开发、预发布和生产环境应使用各自的变量和密钥。

开发阶段就应提前识别环境相关配置。数据库连接、第三方服务地址、测试账号、访问令牌、API Key、Webhook 地址等，不应直接写死在页面、工作流或插件配置中，应尽量通过变量与密钥引用。这样迁移到预发布或生产环境时，只需要根据提示补充目标环境缺失的配置，避免把生产密钥写入迁移内容。

相关文档：变量与密钥。

#开发阶段：记录可恢复节点

开发阶段变化频繁，适合使用版本控制保存关键节点。一次较大的配置调整开始前，可以先创建版本。数据模型、页面、权限、工作流或插件配置调整完成后，再创建一个新的版本。

版本描述应写清楚本次变更的业务含义。例如“调整客户跟进页面和字段权限”“新增工单升级工作流”“优化资产领用审批流程”。描述越明确，后续验证、对比和恢复越容易。

版本控制主要服务于开发过程。它适合撤销一次配置调整，也适合保留阶段性成果。进入发布阶段后，配置变更应通过迁移管理同步到目标环境；生产环境需要恢复时，应使用备份管理。

相关文档：版本控制。

#模块拆分：控制发布边界

系统规模较小时，可以从单应用开始。单应用部署简单，适合原型验证、小型内部系统和早期项目。

当业务复杂度上升后，单个应用会承载越来越多页面、数据表、权限和工作流。一次配置变更可能影响多个团队。一次发布也可能牵动多个模块。此时应考虑使用多应用拆分业务边界。

多应用适合按业务职责拆分。例如 CRM、工单、资产、HR、报表、运营后台。每个应用可以独立开发、测试、发布和回滚。高频变更模块、高风险模块、面向不同用户群体的模块，通常更适合独立出来。

拆分前需要先规划公共能力。用户、组织、认证、权限和跨应用共享数据，都会影响后续发布方式。边界越清晰，发布影响范围越容易控制。

拆分后的发布链路通常如下：

CRM 应用：开发环境 -> 预发布环境 -> 生产环境
工单应用：开发环境 -> 预发布环境 -> 生产环境
资产应用：开发环境 -> 预发布环境 -> 生产环境

相关文档：多应用管理。

#发布前准备：确认恢复能力

备份是生产发布的安全底线。生产环境发布前，应创建发布前备份。重要发布还应先在独立环境验证备份可还原。

发布前备份和日常定时备份用途不同。日常定时备份用于应对误操作、数据损坏和基础设施故障。发布前备份用于发布失败后的快速恢复。两类备份都应纳入生产运维策略。

发布前需要确认备份任务已完成，备份文件可下载或可访问。重要发布还应在独立环境中做一次恢复验证，确认备份可以正常还原。

备份应覆盖数据库、用户上传文件，以及应用运行所需的存储内容。只记录数据库，不足以覆盖完整恢复场景。

相关文档：备份管理。

#发布执行：迁移到目标环境

迁移管理用于将应用配置从一个环境发布到另一个环境。常见迁移内容包括应用配置、数据表结构、插件配置，以及部分需要迁移的数据。

推荐先发布到预发布环境。迁移文件在预发布环境验证通过后，再用于生产发布。

#发布到预发布环境

从开发环境生成迁移文件后，先在预发布环境执行。预发布环境应尽量接近生产环境，包括内核版本、插件版本、变量、密钥、权限配置和外部系统连接方式。执行后验证核心页面、权限规则、工作流和外部系统集成。

预发布验证通过后，应保留同一份迁移文件用于生产发布。不要在发布到生产前临时修改迁移文件。需要调整时，回到开发环境重新生成，并重新经过预发布验证。

#发布到生产环境

生产发布应安排维护窗口。开始前通知用户维护时间，并停止用户访问或切换维护页，避免迁移期间产生新的业务数据。集群或多节点部署场景下，迁移前应先将应用缩容为一个节点。

确认发布前备份完成后，再执行已在预发布环境验证过的迁移文件。迁移完成后，先验证核心业务流程，再恢复用户访问。多节点部署场景下，验证通过后再恢复节点数量。

迁移文件、备份和执行日志会分别保存在对应功能中。团队内部的发布记录可补充发布时间、执行人、验证结果和备份信息，方便后续排查和回滚。

#迁移规则

迁移规则决定目标环境中数据表和记录如何处理。目前常用策略包括覆盖、仅结构和跳过。配置规则时，应先区分应用和插件内置表、用户自定义表，再选择处理方式。

应用和插件内置表通常按默认策略处理，选择覆盖优先。例如页面、菜单、区块、权限、工作流等应用配置。发布时通常以开发环境中的配置为准，同步到预发布和生产环境。

用户自定义表需要按业务用途判断。承载真实业务数据的表，通常只迁移表结构，选择仅结构，避免覆盖生产环境中持续产生的数据。部分用户自定义表如果用于承载配置、分类、模板、规则等元数据，可以根据实际业务场景选择覆盖。

如需了解默认策略对应的数据表，参考：应用和主要插件内置表。

迁移管理主要处理主数据库中的应用配置和数据。外部数据源、子应用数据和部分存储目录内容，应根据实际情况单独处理。

相关文档：迁移管理。

#回滚与恢复

发布失败时，优先通过备份管理插件使用发布前备份恢复。执行还原前，先确认备份文件可用，并根据界面提示完成还原操作。

如果当前生产环境仍可正常进入备份管理，且只是迁移执行失败，可以直接在当前环境中还原发布前备份。恢复完成后，应记录失败原因和处理结果，避免后续发布重复触发同类问题。

如果当前环境状态不稳定，或希望降低在故障环境中反复修复的风险，可以准备独立环境并还原发布前备份。还原后先验证核心业务流程，再将流量切换到恢复后的环境。

#相关文档

• 变量与密钥
• 版本控制
• 多应用管理
• 备份管理
• 迁移管理