AuraBoot
免费开始
English简体中文

环境推送

AuraBoot 把 DSL（models、pages、commands、permissions）当作带版本的工件，在各环境之间流转。推送意味着把一份已验证过的配置从某个环境抬升到下一个环境（按资源版本逐项写入），而不是去手工改目标环境。

三环境模型

环境用途写策略
dev插件作者、设计者、自由实验开放：任何人都可以改
staging验收、UAT、生产行为的演练锁定：变更只能通过推送进来
prod最终用户锁定：变更只能通过推送进来，且需要审批

租户数据不参与推送。只有 DSL 与配置参与推送。生产数据留在生产。

何时使用

  • 设计者在 dev 上线了新页面或新命令，干系人需要在 staging 复核。
  • 发布之前：把 staging 的配置推送到 prod。
  • 事故响应：在不恢复数据库的前提下，把先前已知正确的配置重新推送回目标环境（见下文「回退」）。

工作原理

一次推送是四步工作流：

  1. 导出配置：从源环境导出一份配置快照（EnvironmentExportData，可读、可校验）。
  2. Diff：把源环境与目标环境对比，列出新增 / 更新 / 删除（GET /api/admin/environments/diff）。
  3. 加锁：锁定目标环境，避免并发编辑与推送竞态（POST /api/admin/environments/{pid}/lock）。
  4. 应用：先创建并 validate（dry-run）一个 promotion，再 apply，platform 事务化写入 DSL。

锁定目标环境后，目标环境在解锁之前会拒绝设计器写入。这能防止那个经典的脑裂 bug：prod 上的紧急修复被下一次推送悄悄覆盖。加锁与解锁都要求填写 reason，并会进入审计轨迹。

API 与命令

环境推送通过 platform 的管理 REST API 完成（挂在 /api/admin/environments 与 /api/admin/promotions 下，需管理员 token）。

# 0. 列出环境，拿到 source/target 的 env id 与 code
curl -sS http://localhost:6443/api/admin/environments \
  -H "Authorization: Bearer $ADMIN_TOKEN"

# 1. 导出 dev 的配置快照（只读，可用于审阅）
curl -sS -X POST http://localhost:6443/api/admin/environments/dev/export \
  -H "Authorization: Bearer $ADMIN_TOKEN"

# 2. 对比 dev 与 staging（只读）
curl -sS "http://localhost:6443/api/admin/environments/diff?source=dev&target=staging" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

# 3. 加锁目标环境（reason 必填，进入审计）
curl -sS -X POST http://localhost:6443/api/admin/environments/<staging-pid>/lock \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"reason": "Promote crm_lead.qualify command"}'

# 4. 创建一个 promotion（指定 source/target env id 与要推送的资源单元）
curl -sS -X POST http://localhost:6443/api/admin/promotions \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "sourceEnvId": 1,
    "targetEnvId": 2,
    "units": [
      { "resourceType": "PAGE_SCHEMA", "resourcePid": "<page-pid>" }
    ]
  }'

# 5. validate（dry-run）：检测冲突，无错时 DRAFT → VALIDATED
curl -sS -X POST http://localhost:6443/api/admin/promotions/<promotion-pid>/validate \
  -H "Authorization: Bearer $ADMIN_TOKEN"

# 6. apply：事务化写入目标环境（目标锁定时需四眼校验，reason 必填）
curl -sS -X POST http://localhost:6443/api/admin/promotions/<promotion-pid>/apply \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"reason": "Add crm_lead.qualify command"}'

diff 概念上会列出源、目标之间新增 / 更新 / 删除的资源（如页面 schema 的版本差异）。

推送在审计日志中是 append-only 的（AdminEventLogService）；每一次 apply 都会记录操作人（appliedBy）、原因（appliedReason）与时间（appliedAt），失败时记录 failureReason。

回退

平台目前没有「一键 rollback」端点。要回退，请把先前已知正确的配置版本重新推送回目标环境：在源环境（或一份已保存的导出快照）上保留好上一版资源，按上文同样的流程重新创建 → validate → apply 一个 promotion，目标环境的对应资源会 bump 到该版本。如需以导出的快照覆盖目标环境，可用 POST /api/admin/environments/{code}/import（请求体为之前 export 得到的 EnvironmentExportData）。

验证

  • 推送之后 GET /api/admin/environments/diff?source=...&target=... 不再有变更。
  • 应用之后目标环境 /actuator/health 为 UP。
  • 在目标环境上能端到端跑通推送过的页面（侧边栏 → 列表 → 创建 → 保存）。
  • promotion 状态为 APPLIED，且记录了 appliedBy / appliedReason / appliedAt；审计日志中有对应事件。
  • 回退后，相对于一份已保存的 baseline，diff 重新归零。

相关