精通 Salesforce DX：现代应用生命周期管理的开发者指南

九月 08, 2025

背景与应用场景

作为一名 Salesforce 开发人员，我见证了平台开发模式的演进。在过去，我们的开发流程严重依赖于变更集（Change Sets）和基于 Eclipse 的 Force.com IDE。这种模式存在诸多痛点：难以进行版本控制、团队成员之间容易产生元数据覆盖、部署过程手动且易错、缺乏自动化测试的集成。这使得大型项目或敏捷团队的协作变得异常困难，开发效率也大打折扣。

为了解决这些问题，Salesforce 推出了 Salesforce DX (SFDX)。它不仅仅是一个工具，更是一套全新的开发方法论和工具集，旨在将 Salesforce 平台的应用开发带入现代化、标准化的轨道。SFDX 的核心理念是源码驱动开发（Source-Driven Development），即将版本控制系统（Version Control System, VCS），如 Git，作为项目元数据的唯一真实来源（Single Source of Truth），而不是某个特定的 Salesforce 组织（Org）。

SFDX 的应用场景极其广泛，尤其适用于以下情况：

团队协作开发： 多个开发者可以并行工作在各自的功能分支上，通过 Git 进行代码合并与冲突解决，极大地提高了协作效率。
自动化构建与部署 (CI/CD)： SFDX 的命令行工具 Salesforce CLI 可以轻松集成到 Jenkins、GitHub Actions、GitLab CI 等自动化流程中，实现代码提交后自动运行测试、验证和部署。

模块化应用开发：

可预测的环境管理：

暂存组织（Scratch Orgs）

原理说明

要理解 Salesforce DX 的工作方式，我们需要掌握几个核心概念：

1. Salesforce CLI (命令行界面)
这是与 Salesforce DX 生态系统交互的主要工具。它提供了一系列强大的命令（以 `sf` 或旧版的 `sfdx` 开头），用于创建和管理项目、授权组织、创建和管理 Scratch Orgs、推送和拉取元数据、运行测试、打包和部署应用等。由于其脚本化的特性，CLI 是实现 DevOps 自动化的基石。

2. Dev Hub (开发中心)
Dev Hub 是一个特殊的 Salesforce 组织（通常是你的生产组织或专用的开发者版组织），它扮演着“指挥中心”的角色。你需要在一个组织中启用 Dev Hub 功能，才能创建和管理你的所有 Scratch Orgs。Dev Hub 会跟踪所有关联的 Scratch Orgs 的状态、默认设置和生命周期。

3. Scratch Orgs (暂存组织)
Scratch Orgs 是 Salesforce DX 的革命性特性。它们是临时的、一次性的、完全可通过源码驱动的 Salesforce 环境。开发者可以通过一个 JSON 配置文件（`project-scratch-def.json`）来定义 Scratch Org 的功能、设置和许可证。你可以随时创建一个全新的、干净的 Scratch Org，在完成功能开发或测试后将其销毁。这确保了每个开发任务都在一个独立且可预测的环境中进行，避免了传统沙盒（Sandbox）中因长期使用而产生的元数据“漂移”和配置混乱问题。

4. DX 项目结构与源码格式
Salesforce DX 项目有一个标准化的目录结构。最重要的文件是 `sfdx-project.json`，它定义了项目的基本信息，如包目录、命名空间、API 版本以及对其他包的依赖。项目源码存储在 `force-app`（或其他自定义）目录下，并采用源码格式（Source Format）。与传统的元数据格式（Metadata Format）将整个对象的所有信息（字段、验证规则、布局等）放在一个巨大的 XML 文件中不同，源码格式将这些元数据分解为多个更小的、独立的文件。例如，一个自定义对象会被拆分成对象自身的 XML 文件、每个字段一个 XML 文件、每个列表视图一个 XML 文件等。这种精细化的结构使得在版本控制系统中跟踪变更、进行代码审查和合并冲突变得极其简单。

5. 源码跟踪 (Source Tracking)
在 Scratch Orgs 中，Salesforce DX 会自动跟踪你的本地文件与云端组织之间的元数据差异。这意味着你可以使用简单的 `sf project deploy start`（推送）和 `sf project retrieve start`（拉取）命令来同步变更，而无需手动指定要操作的组件。对于沙盒或生产等非 Scratch Org 环境，源码跟踪不可用，你需要依赖 `package.xml` 清单文件来明确指定要部署或拉取的元数据。

示例代码

以下是一些在日常开发中常用的 Salesforce CLI 命令。这些示例均基于 Salesforce 官方文档，并使用最新的 `sf` 命令语法。

1. 创建一个 DX 项目

这个命令会在本地创建一个标准的 Salesforce DX 项目结构，包括 `sfdx-project.json` 配置文件和 `force-app` 源码目录。

sf project generate --name MyDXProject

详细注释：

`sf project generate`: 这是用于创建新项目的核心命令。
`--name MyDXProject`: 指定新项目的名称。执行后，会在当前目录下创建一个名为 `MyDXProject` 的文件夹。

2. 授权 Dev Hub 并创建 Scratch Org

在创建 Scratch Org 之前，你必须先登录并授权你的 Dev Hub 组织。然后，使用一个定义文件来创建 Scratch Org。

首先，通过 Web 浏览器登录到你的 Dev Hub 组织：

sf org login web --set-default-dev-hub --alias MyDevHub

详细注释：

`sf org login web`: 启动一个基于 Web 的登录流程。
`--set-default-dev-hub`: 将这个授权的组织设置为此项目的默认 Dev Hub。
`--alias MyDevHub`: 为这个组织设置一个易于记忆的别名 `MyDevHub`，方便后续命令引用。

接下来，创建一个 Scratch Org 定义文件 `config/project-scratch-def.json`：

{
  "orgName": "My Company",
  "edition": "Developer",
  "features": ["EnableSetPasswordInApi"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    },
    "mobileSettings": {
      "enableS1EncryptedStoragePref2": false
    }
  }
}

详细注释：

`orgName`: Scratch Org 的名称。
`edition`: 指定 Org 的版本，如 `Developer`, `Enterprise`, `Professional`。
`features`: 一个数组，用于启用组织中的特定功能。
`settings`: 一个对象，用于配置组织的各种设置，如启用 Lightning Experience。

最后，使用定义文件创建 Scratch Org：

sf org create scratch --definition-file config/project-scratch-def.json --set-default --alias MyScratchOrg

详细注释：

`sf org create scratch`: 创建 Scratch Org 的命令。
`--definition-file config/project-scratch-def.json`: 指定用于创建 Org 的配置文件路径。
`--set-default`: 将新创建的 Scratch Org 设置为该项目的默认组织。
`--alias MyScratchOrg`: 为这个 Scratch Org 设置别名 `MyScratchOrg`。

3. 推送和拉取源码

将本地项目的元数据推送到默认的 Scratch Org 中。

sf project deploy start

如果想从 Scratch Org 中拉取在 UI 上做的修改到本地项目中：

sf project retrieve start

详细注释：

这两个命令非常简洁，因为它们依赖于 Scratch Org 的源码跟踪功能来自动检测变更。无需指定具体文件，SFDX 会自动同步差异。

4. 运行 Apex 测试

在目标组织中运行所有的 Apex 测试。

sf apex test run --result-format human --test-level RunLocalTests

详细注释：

`sf apex test run`: 运行 Apex 测试的命令。
`--result-format human`: 以人类可读的格式显示测试结果。
`--test-level RunLocalTests`: 指定测试级别。`RunLocalTests` 会运行所有本地测试（排除托管包中的测试）。

5. 从非 Scratch Org 中拉取元数据

当需要从一个已有的沙盒或生产组织中拉取元数据以启动一个 DX 项目时，由于没有源码跟踪，我们需要使用 `package.xml` 清单文件。

首先，确保你已经授权了目标沙盒：

sf org login web --alias MySandbox --instance-url https://test.salesforce.com

然后，使用清单文件来拉取元数据：

sf project retrieve start --manifest path/to/package.xml --target-org MySandbox

详细注释：

`--manifest path/to/package.xml`: 指定一个 `package.xml` 文件，该文件定义了需要拉取的元数据组件列表。
`--target-org MySandbox`: 指定要从哪个组织拉取元数据，这里使用的是我们之前设置的别名 `MySandbox`。

注意事项

权限与许可证： 要使用 Dev Hub 和 Scratch Orgs，相关用户需要被分配 "Salesforce DX" 权限集许可证，并加入 "Salesforce DX" 权限集。
Dev Hub 启用： Dev Hub 功能必须在你的生产组织或专用的开发者版组织中手动启用。此操作不可逆。
Scratch Org 限制： 不同版本的 Salesforce 组织对活动 Scratch Org 的数量和每日创建数量有不同的限制。请根据你的版本查阅官方文档，合理规划资源。
API 限制： Salesforce CLI 的所有操作最终都会转化为对 Salesforce API 的调用，因此会消耗组织的 API 调用限额。在设计大规模自动化流程时，需要考虑这一点。
环境策略： Scratch Orgs 最适合用于功能开发和自动化测试。对于用户验收测试（UAT）、集成测试和性能测试，仍然推荐使用功能完整的沙盒（Sandboxes）。Salesforce DX 可以同时管理这两种环境，但工作流有所不同（push/pull vs deploy/retrieve）。
源码跟踪的局限性： 源码跟踪是 Scratch Org 的专属功能。在与沙盒或生产组织交互时，必须明确指定要操作的元数据，通常是通过 `package.xml` 或指定源文件目录的方式。

总结与最佳实践

Salesforce DX 无疑是 Salesforce 平台开发的一场革命。它通过引入源码驱动开发、CLI、Scratch Orgs 等现代化工具和理念，彻底改变了我们构建、测试和交付应用的方式。作为一名开发人员，拥抱 SFDX 不仅能显著提升个人生产力，更能促进团队协作，实现稳健、高效的 DevOps 流程。

以下是一些在实践中总结的最佳实践：

将 Git 作为唯一真实来源： 任何对元数据的修改都应始于本地代码，并提交到版本控制系统。避免直接在组织中（尤其是共享沙盒）进行修改，然后尝试同步回本地。
为每个功能创建 Scratch Org： 遵循“一个功能（或一个 Bug 修复），一个 Scratch Org”的原则。这能确保开发环境的绝对纯净，避免不同功能间的相互干扰。
自动化所有重复性工作： 利用 Salesforce CLI 的脚本能力，将代码检查、测试运行、打包、部署等步骤集成到 CI/CD 流水线中。这能减少人为错误，确保交付质量。
采用清晰的 Git 分支策略： 结合如 GitFlow 这样的分支模型来管理功能开发、发布和热修复，使团队协作井然有序。
模块化应用设计： 对于复杂的应用，应尽早考虑使用第二代打包（Unlocked Packages）进行拆分。这不仅能简化依赖管理，还能加快部署速度，降低风险。
定期更新 Salesforce CLI： Salesforce 团队在持续迭代 CLI，带来新功能和性能优化。通过运行 `sf update` 命令保持你的工具是最新版本。

总之，掌握 Salesforce DX 是每一位现代 Salesforce 开发人员的必备技能。它不仅能帮助我们写出更高质量的代码，更能让我们以一种更专业、更工程化的方式参与到整个应用生命周期管理中。

Salesforce中文网