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 --yes7.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