7. 推进与发布

你已经在 dev 上拥有一个可运行的 CRM。本章使用 env-layering 把它推进到 staging 与 production,使配置可复现。

预计耗时:25 分钟。

7.1 快照 dev 配置

在项目根目录运行:

# run locally
aura plugin build crm --output dist

该命令会校验并打包 CRM 的配置产物到 dist/<namespace>-<version>.json(例如 dist/crm-1.0.0.json):model 定义、字段、binding、命令、页面、权限、角色、菜单、字典、i18n 资源。

7.2 与 staging 做 diff

对这个包和 staging 当前状态做一次 diff:

# compare local package/config with the staging platform
aura plugin diff crm --target https://staging.example.com

如果走产品内 env-layering,在环境发布的 dry-run 后打开差异页审核 source / target 变化:

发布差异审核

仔细审核 diff。重点看 model、field、page、permission、command、dict、menu 的差异;凡是会变更用户产生数据的内容一律拒绝。env-layering 只推进配置,不推进业务数据。CLI diff 用于本地包与目标环境的可复核比较;产品内 Diff Viewer 用于已经创建的 promotion dry-run,逐项看 source / target 差异和影响面。若 staging 上有人手工改了同一个配置,先回到 dev 合并并重新打包,不要在 staging 直接热修。

7.3 推进到 staging

应用这个包:

# run against staging
aura plugin import crm --env staging --yes

--env staging 会把目标平台解析到 staging 环境(经 ~/.aura/config.json 中配置的命名环境);--yes 跳过交互确认。完整生命周期见 env-promotion。变更必须来自新一轮推进周期,不要直接在 staging 上原地修改。

7.4 冒烟

在 staging 上:

  • 以 rep 身份登录,资格化一个 lead → opportunity 被创建
  • 触发一笔 > $50k 的交易 → 审批送达 manager
  • Dashboard KPI 在 seed 数据上正常渲染
  • 移动端 app 能识别这些新对象

如有任何缺失,回到 dev 修,重新 build、重新 import。不要直接热修复 staging。

7.5 推进到 production

同样的命令,改成 --env prod。如果你有 CI 流水线,应在 staging 通过绿测后调用它;否则配双人 review 手工执行(reviewer 审批记录由发布流程或工单系统留痕,不在 CLI 标志上)。

aura plugin import crm --env prod --yes

7.6 发布后

  • 在 git 中打 tag:git tag crm-v0.1.0 && git push --tags
  • Release Notes(/docs/release-notes/v0.x)中追加一条记录,描述本次交付内容
  • 设置一个 7 天后的检查节点,回顾 Dashboard 上的使用指标

你构建了什么

一个可运行的 CRM:三个 model、设计好的页面、含行级筛选的角色访问控制、lead 到 opportunity 的自动化转化、BPMN 审批、销售 Dashboard、移动端体验、以及一条可复现的发布路径。

整套都是配置。继续深入:

  • 插件开发 —— 把这个 CRM 封装为可分发的插件
  • AI Copilot —— 让用户问出"本季度有哪些有风险的交易"
  • Webhooks —— 把 opportunity 事件推送到 Slack 或 Salesforce