一、规划对组织的变更
本模块跟随 Zephyrus Relocation Services 的 Calvin Green 与 Juan Garcia，见证他们从「在生产环境中零散开发」过渡到专业、团队化的开发生命周期。你将学习使用 Salesforce DX 项目、基于 Git 的源代码控制、VS Code 及 Salesforce 扩展、Salesforce CLI，以及一套结构化的沙箱策略（Developer → Developer Pro → Partial → Full → Production）。本单元先规划变更并准备工具。
学习目标
完成本单元后，你将能够：
- 描述如何使用 org development model（组织开发模型）配合 Salesforce DX 与源代码控制来管理变更
- 识别必备工具：Salesforce DX 项目、Salesforce CLI、VS Code 扩展与 Git
- 解释源代码控制的好处：协作、版本历史、回滚与审计追踪
Calvin 的挑战：Zephyrus 的成长烦恼
Calvin Green 是 Zephyrus Relocation Services（位于弗吉尼亚州费尔法克斯的人才流动公司）的 Salesforce 管理员。他一直在生产环境中通过 Setup 界面定制 Salesforce，为公司规模不大但持续增长的销售团队打造了大量仪表盘与报表。
随着团队壮大，现有的做法开始出问题：
- 多名管理员与开发人员同时修改，却无法跟踪每个人改了什么
- 开发与测试环境漂移、失去同步
- 因环境差异导致变更集需要反复创建和部署才能成功
新任首席开发 Juan Garcia 研究了 Salesforce DX 工具与开发模型，认为 org development model 能缓解这些痛点。该模型使用几类不同工具，带来：1) 更强的灵活性与可扩展性；2) 跟踪与管理变更的新方式；3) 不同的部署方法。
Juan 喜欢该模型用源代码仓库存储变更与项目文件——通过把每次发布的变更外置到仓库，团队知道仓库反映的是他们实际交付的内容，不受环境差异影响，从而让开发、测试、暂存环境之间的流转更顺畅。团队还使用变更跟踪机制来捕获对组件所做的变更，与直接在组织里通过 Setup UI 修改区分开来。
org development model 涉及的关键工具：
Salesforce DX 项目：包含构成你变更的源代码与文件，具有特定的项目结构与源代码格式。除源文件外，项目还包含配置文件 sfdx-project.json（含项目信息，用于驱动 Salesforce DX 工具）。项目结构包括：.sfdx 文件、.vscode 文件、config 目录、force-app 目录（以源代码格式存放变更）、manifest 目录（存放 package.xml）、.forceignore 文件，以及 sfdx-project.json 配置文件。
发布制品（清单文件）：测试完成后，Juan 创建发布制品——一个列出要部署组件的清单文件 package.xml。他先用它部署到各个沙箱，最后再部署到生产。变更只有在部署后才会生效。
源代码控制系统：所有变更都合并存储到源代码控制系统（内含 Salesforce DX 项目）。它带来几个好处：实时协作提高效率并促成共识；团队可同时编辑同一文件而无需担心覆盖他人工作或丢失成果；修订历史显示谁改了哪些内容；可以回退到任意文件的早期版本（就像一台能回到过去拯救宇宙的时光机）；保存工作时可填写提交说明，为工作提供历史上下文。
Salesforce CLI：一个强大的命令行界面，可用于 org development 生命周期的每个阶段，通过单一接口提升生产力。你可以：授权沙箱（无头或 Web 流程）、创建与管理 DX 项目、导入导出测试数据、检索与部署元数据、运行并自动化测试。
Salesforce Extensions for VS Code：构建在 Salesforce CLI 与 VS Code 之上，是专为 Lightning Platform 定制开发打造的集成开发环境（IDE）。你可以直接在命令面板或终端运行 Salesforce CLI 命令。团队安装 Salesforce Extension Pack 后可使用这些扩展：Einstein for Developers（用自然语言快速生成代码建议）、Salesforce CLI Integration（与 Salesforce CLI 交互提供核心功能）、Apex（用 Apex Language Server 提供语法高亮与代码补全）、Apex Replay Debugger（从 Apex 调试日志重放 Apex 执行）、Lightning Web Components（支持 Lightning Web 组件）。
专业提示：如果因安全限制无法安装 Salesforce CLI 或 VS Code，或你只想在云端工作，可以尝试 Salesforce Code Builder——一个基于 Web 的集成开发环境，在浏览器里提供 VS Code、Salesforce 扩展与 Salesforce CLI 的全部能力，无需担心下载、安装或机器配置。
变更管理机制：团队还可以借助正式的变更跟踪工具，包括团队变更清单（team change list）、部署运行清单（deployment run list）与项目管理系统。
安装工具：Juan 和 Ella 都使用 Salesforce Extensions for VS Code 进行开发与测试，用 GitHub 作为源代码控制系统。安装步骤：1) 安装 Salesforce CLI；2) 安装 VS Code 与 Salesforce Extensions；3) 安装 Git；4) 配置 Git；5) 创建 GitHub 账号。专业提示：安装 Salesforce CLI 的自动补全功能，可让你输入部分命令或参数后按 Tab 自动补全，在终端里操作更轻松。
沙箱策略：四个环境一条流水线
org development model 使用一套结构化的沙箱流水线，团队在应用生命周期的每个阶段使用不同类型的沙箱：
- 开发与测试（Develop and test）：每位成员拥有自己的 Developer sandbox 来创建各自的定制。Developer 沙箱不含生产数据。
- 构建发布（Build release）：每位成员把自己的定制从各自的 Developer 沙箱迁移到共享的 Developer Pro sandbox 进行集成。Developer Pro 沙箱不含生产数据，但可以用测试数据填充。
- 测试发布（Test release）：为了用户验收测试，团队使用 Partial sandbox 创建生产的完整副本（不含生产数据）。
- 发布（Release）：发布进入生产后，团队可用 Full sandbox 培训用户，无需担心改动生产数据。Full 沙箱包含生产数据的副本。
核心洞察：源代码控制是唯一的事实来源（single source of truth）。环境是一次性的，仓库才是永久的。变更的流动方向是：Developer 沙箱 → 源代码控制 → Developer Pro 沙箱 → 源代码控制 → 暂存环境 → 生产环境。
二、本地开发并测试变更
现在动手。Juan 和 Ella 建立 GitHub 仓库、创建 Salesforce DX 项目、构建自定义对象与字段、编写 Apex 触发器、把变更提交到源代码控制，并部署到 Developer 沙箱测试。这就是核心开发循环：编码 → 提交 → 部署 → 测试。
开发循环：编码、提交、部署、测试
org development model 的核心工作流如下：
- 克隆仓库（Clone the Repo）——每个开发者从 GitHub 克隆一份到本地，创建自己的分支（例如 Ella 的分支
ella-custom-object）。 - 授权沙箱（Authorize the Sandbox）——用 CLI 把本地工具连接到 Developer 沙箱：选择 SFDX: Authorize an Org → Sandbox（登录 URL 为 test.salesforce.com）→ 输入别名（如
dev_sandbox）→ 用沙箱用户名密码登录。 - 做出变更——在本地 DX 项目结构中创建自定义对象、字段、Flow、Apex 类、触发器：
force-app/main/default/objects/（自定义对象）、force-app/main/default/classes/（Apex 类）、force-app/main/default/triggers/（Apex 触发器）。 - 从沙箱检索（Retrieve）——把通过 Setup 界面做的元数据变更拉回 DX 项目：
sf project retrieve start。 - 提交到源代码控制——用说明信息保存变更：
git add .→git commit -m "Added Course Instructor object"→git push。现在仓库拥有完整的变更历史。 - 部署到沙箱——把项目变更推送到 Developer 沙箱测试：
sf project deploy start。 - 测试——在沙箱里验证变更正确工作。
这个循环对每次变更重复执行。小而频繁的提交更好——每个提交都是一个可以回退的检查点。
具体到 Zephyrus 的需求：销售团队希望在语言课程被新增或修改时收到通知，并想知道每门课由谁授课。于是 Ella 负责创建「语言课程讲师」自定义对象并关联到课程记录，Juan 创建向销售团队别名发送通知邮件的触发器。以下是完整过程：
建立代码仓库：Juan 在 GitHub 中创建名为 language-courses 的私有仓库。然后在 VS Code 中：命令面板输入 sfdx project → 选择 SFDX: Create Project with Manifest → 项目名用 language-courses → Create Project。接着把项目文件加入仓库：点 Source Control 图标 → Initialize Repository → 暂存所有变更 → 输入提交信息并提交 → Publish Branch。
创建自定义对象：Ella 在她的 Developer 沙箱中创建 Language Course 与 Language Instructor 两个自定义对象。以 Language Course Instructor 为例：Setup → Object Manager → Create | Custom Object → Label 输入 Language Course Instructor，Plural Label 输入 Language Course Instructors → 勾选 Launch New Custom Tab Wizard → Save → 选择标签样式（Presenter）。Language Course 对象同理（标签样式选 Chalkboard）。
定义自定义字段：在 Language Course 对象上定义一个引用 Language Course Instructor 的字段。Setup → Object Manager | Language Course → Fields & Relationships → New → 数据类型选 Master-Detail Relationship → Related To 选 Language Course Instructor → Field Label 为 Course Instructor，Description 为 Teacher for the language course → 保存。
在变更清单中跟踪变更：Ella 为项目创建变更清单，记录她做的变更。
从沙箱检索变更：Ella 用 VS Code 终端运行 CLI 命令检索自定义对象与字段：
sf project retrieve start --metadata CustomObject:Language_Course_Instructor__c --metadata CustomField:Language_Course__c.Course_Instructor__c
这里用 --metadata 而不是 --source-dir，因为 --source-dir 只能检索文件系统上已存在的文件。CLI 会按 DX 项目默认目录把源码放到 force-app 文件夹（注意：GitHub 无法添加空文件夹，所以要先在本地创建 force-app 文件夹）。自定义对象会出现在 force-app/main/default/objects 目录。
提交变更并审查代码：Ella 把变更提交到仓库，创建 pull request 通知 Juan 审查。Juan 审查并批准后，Ella 合并 pull request。
创建触发器：触发器（trigger）是一段 Apex 代码，在特定类型记录被插入、更新或删除之前或之后执行。Juan 克隆仓库并创建自己的分支 juan_apex_trigger，在 VS Code 中创建触发器及其测试。展开 force-app 文件夹 → 右键 default → New Folder 输入 triggers → 右键 triggers 文件夹 → SFDX: Create Apex Trigger → 输入名称 LanguageCourseTrigger，编写代码（trigger LanguageCourseTrigger on Language_Course__c (after insert, after update, after delete)）→ 保存 → 创建测试类 TestLanguageCourseTrigger 以满足代码覆盖率要求。
部署变更到 Developer 沙箱：Juan 把触发器部署到沙箱验证并编译，再测试它与新对象协同工作是否正常。右键 triggers 文件夹 → SFDX: Deploy Source to Org，或运行：
sf project deploy start --source-dir force-app/main/default/triggers
随后 Juan 提交变更、创建 pull request，由 Ella 进行代码审查。未来的定制也遵循相同流程：在 VS Code 中开发的定制（如触发器）部署到各自的 Developer 沙箱验证测试；其余用 Setup 完成，再检索回本地、提交到源代码控制、创建 pull request 并请求代码审查后再合并到主分支。
三、测试并部署变更
所有开发完成。Juan 构建发布制品（package.xml），在 Developer Pro 沙箱中集成变更，运行用户验收测试，最后执行生产部署。本单元覆盖完整的发布流程，包括用 Quick Deploy 加速验证，以及部署后任务的执行。
构建发布制品并部署到生产
发布制品（Release Artifact）是一个清单文件（package.xml），列出要部署到沙箱与生产组织的所有元数据组件。你也可以用它来检索组件。清单文件只是一份列表，并不包含实际的 Apex 代码或自定义对象的完整结构——部署命令使用的是你本地项目中当前找到的源文件。请务必留意你实际部署的源文件。
拉取仓库变更：Juan 知道本次发布的所有变更都已存放在 GitHub 仓库（唯一事实来源）。在 VS Code 中：点 Source Control 图标 → 点 More Actions 图标 → 选 Pull from → 选 origin。仓库包含新的自定义对象、自定义字段与触发器——Ella 和 Juan 的所有变更都在这里。
构建发布制品：Juan 先生成清单文件。在 Salesforce DX 项目目录下运行：
sf project generate manifest --metadata CustomObject:Language_Course_Instructor__c --metadata CustomField:Language_Course__c.Course_Instructor__c --metadata ApexTrigger:LanguageCourseTrigger --metadata ApexClass:TestLanguageCourseTrigger
该命令在当前目录生成 package.xml。然后在 Developer Pro 沙箱中测试该文件能否部署所有组件：
sf project deploy start --manifest package.xml --target-org dev-pro-sandbox
你还可以用清单文件在部署时删除组件：用 project generate manifest 的 --type 参数生成「破坏性变更」清单，再用 project deploy start|validate 的删除参数（如 --post-destructive-changes）指定该文件。
在测试（Partial）沙箱中测试发布制品：授权 Partial 沙箱后，在项目目录运行部署命令（模拟生产部署）：
sf project deploy start --manifest package.xml --target-org partial-sandbox --test-level RunSpecifiedTests --tests TestLanguageCourseTrigger
必要时运行 UI 测试（如 Selenium 测试），然后打开沙箱执行用户验收测试。此阶段 Juan 只关心与本次发布变更相关的测试。
在暂存（Full）沙箱中测试发布制品：若集成测试无需改动，下一步在 Full 沙箱中暂存变更，此阶段包含回归测试并模拟生产发布。Juan 使用同一个 package.xml，并确保从测试时相同的分支部署。他先做一次验证部署（validated deploy）来运行全部回归测试——验证部署能验证部署将执行的测试结果，但不提交任何变更，还能确保没有遗漏组件依赖或无效元数据：
sf project deploy validate --manifest package.xml --target-org full-sandbox --test-level RunLocalTests
该命令返回一个 job ID。验证成功意味着所有 Apex 测试都通过，且测试至少覆盖被部署代码的 75%。接着用上一步返回的 job ID 在 Full 沙箱上完成快速部署（quick deploy），模拟后续在生产中的操作：
sf project deploy quick --job-id <jobID> --target-org full-sandbox
在暂存环境中成功验证组件后，Juan 的维护窗口更短，部署到生产时对用户访问的阻塞也更少。
发布到生产：所有测试在 Full 沙箱通过后，即可部署到生产。Juan 检查部署运行清单，确认没有部署前任务。他先为生产组织设置验证部署，确保与暂存沙箱的差异不会引发问题：
sf project deploy validate --manifest package.xml --target-org production-org --test-level RunLocalTests
验证成功后，他最多有 10 天时间执行快速部署到生产（前提是期间没有其他部署或重大改动）。为了最小化对客户的影响，他在业务时段运行验证部署（出问题能及时排查），并在当晚用快速部署上线：
sf project deploy quick --job-id <jobID> --target-org production-org
最后打开生产组织确认变更已就位，并执行部署运行清单中列出的部署后任务。
又一次成功上线：Calvin 在生产组织里做快速抽查，给某门课程添加一名讲师，验证通知邮件确实到达收件箱。由于所有变更都记录在源代码控制系统中，团队可以为 Calvin 提供一份明确的变更清单，用于编写发布说明。至此，Zephyrus 销售团队随时掌握最新课程信息，而变更也永久保存在仓库中，为团队未来承接更多工作打下了基础。