如何开始使用Salesforce DX进行内部Org自定义开发配置

是否需要先全量整理现有自定义配置归入DX项目？ #

不需要一次性迁移所有存量配置，你可以从当前正在推进的新需求/小规模变更开始试点DX，存量配置按需分批迁入即可，避免前期迁移工作量过大影响日常交付节奏。

如果是首次使用DX，建议先选复杂度低的小型需求跑通完整流程，熟练后再逐步推广到所有客户项目。

配置迁入、开发、测试、部署全流程操作 #

1. 前置准备 #

• 本地安装Salesforce CLI，安装完成后运行 sf version 确认安装成功
• 在你常用的生产/沙箱实例中启用Dev Hub功能，Dev Hub仅用于生成scratch org，不会影响现有业务
• 本地创建空文件夹作为项目根目录，运行 sf project generate --name 你的项目名称 初始化标准DX项目结构

2. 存量自定义配置迁入（按需执行） #

• 运行 sf org login web --instance-url 存量配置所在实例URL --alias 实例别名 登录目标实例
• 编写package.xml清单，仅列明你需要迁入的配置项，比如自定义对象、Apex触发器、验证规则、页面布局等你日常用到的元数据类型
• 运行 sf project retrieve start --manifest package.xml --target-org 实例别名 把指定配置拉取到本地DX项目
• 拉取完成后可将本地文件纳入Git等版本控制工具，方便后续追踪变更历史

3. 新变更开发流程 #

• 每次启动新需求开发时，运行 sf org create scratch --definition-file config/project-scratch-def.json --alias 开发环境别名 --duration-days 7 创建独立的scratch org作为开发环境
• 把项目当前的基准配置推送到scratch org：sf project deploy start --target-org 开发环境别名
• 在scratch org内完成所有自定义配置操作，比如新建自定义对象、编写Apex触发器、配置流程规则等
• 开发完成后运行 sf project retrieve start --target-org 开发环境别名 把变更拉取到本地，核对变更内容无误后提交到版本控制

4. 测试环节 #

• 测试阶段可新建独立的scratch org，推送最新的项目配置，和开发环境完全隔离避免干扰
• 自动化Apex测试直接运行 sf apex run test --target-org 测试环境别名 --code-coverage 即可获取测试结果和代码覆盖率
• 手动测试直接在测试用scratch org内操作即可，所有配置和最终要部署到生产的内容完全一致，不会出现环境差异导致的问题

5. 部署到客户实例 #

• 部署前先登录目标沙箱/生产实例：sf org login web --instance-url 目标实例URL --alias 部署目标别名
• 运行 sf project deploy start --target-org 部署目标别名 --dry-run 先做预校验，确认没有部署报错
• 预校验通过后去掉--dry-run参数执行正式部署
• 部署完成后直接在目标实例验证配置生效情况即可

提示：如果客户实例中有未纳入DX项目的存量配置，部署时不会覆盖这部分内容，仅会更新DX项目中包含的元数据，无需担心影响实例内未迁移的其他配置。

内容的提问来源于stack exchange，提问作者the-a-train