一、构想新的真相来源
本模块介绍在 Salesforce 上构建的现代方式——从「以组织为中心」（生产环境是真相来源）转向「以包为中心」（源代码控制是真相来源）。你将学习 unlocked packages（未锁定包）如何实现模块化、独立的开发，scratch orgs（临时组织）如何取代沙箱用于开发与测试，以及如何规划组织向这种更可扩展、更利于团队协作的开发模型转型。
组织开发 vs 包开发：两种范式
传统上，这个世界的中心是你的生产组织，大部分开发都在沙箱或生产组织的范围内进行。在组织开发模型中，无论你构建什么，最终创建的都是以生产组织为范围的部署——即使有多个团队在各自独立的开发项目上工作，他们也要用同一个部署来开发和发布更新，所有东西都塞进一个 package.xml。
举例来说，假设你要为两个新项目工作：CRM 扩展/定制（添加自定义对象、字段、页面布局、工作流、Apex 类、Visualforce 页面）和 Time Off Manager 应用。在组织模型下，第一个发布里两个项目一起发布；第二个发布即使只做小改动，两个项目也仍然同时发布到生产组织。开发者与发布经理把组织视为一堆交织在一起的代码与定制，最终部署并不只针对某个应用，而是包含对组织的所有变更。
随着组织不断壮大、发布越来越复杂，Calvin 希望把项目从庞大的「发布列车」中解耦出来。包开发模型（package development model）精简了整个开发生命周期，带来这些好处：改善团队开发与协作；模块化开发流程并明确包之间的依赖；通过版本化帮助变更管理；促进自动化测试与持续集成；让发布周期更高效敏捷；通过 Setup 功能的变更跟踪改善 VCS 同步；更细粒度地洞察生产组织的变更管理。
这意味着，你不再是「为组织」构建代码与定制，而是创建一个包（package）——一个逻辑上的代码集合，一个由相关代码与定制组成的发布制品。包的组件分组可以代表很多东西：支持销售团队的定制集合、在组织中构建的应用的 Lightning 组件/对象/工作流、围绕从 AgentExchange 安装的托管包构建的扩展等。
通过把源代码与元数据组织进包，你能更好地理解组织中元数据组件之间的关系。组织越大，这个过程越重要，所以要尽早规划、始终思考如何组织你的组织。
包的关键特征：包含一个逻辑上的元数据分组（一个应用、一个功能、一个共享库）；有版本号（1.0.0 → 1.1.0 → 2.0.0）；对其他包有显式依赖；可以安装到任何组织（scratch、sandbox、production）；独立部署，无需 package.xml。
VCS 是开发者最好的朋友，在包开发生命周期中扮演着不可或缺的角色。你把所有包的源代码存储到源代码仓库（真相来源在此维护），从该源代码构建 scratch org，从而专注开发你的包。变更跟踪功能监控你在开发组织里创建、更新、删除了什么，你可以轻松把修改后的源代码拉到本地文件系统并签入 VCS。
包开发让你在管理团队与发布上更灵活：把某个包交给一个团队负责，各开发团队独立开发、朝着包的发布（而不是组织更新的发布）努力。这种敏捷模型支持更频繁、独立的发布。
对于企业客户，有一种特殊的包类型——unlocked packages（未锁定包），尤其适合内部业务应用。
用 unlocked packages 发布 CRM 定制与 Time Off Manager 应用时：第一个发布创建两个新项目，都版本化为 1.0，可以分别构建、再分别用 Metadata API 部署到生产组织。第二个发布里，你同样可以独立构建和部署每个包版本（例如 CRM 扩展 v1.1、Time Off Manager v2.0），从而为每个发布制品（包）维护不同的版本。这一流程还延伸到 CI/CD——构建包让你能为项目量身定制测试计划，并在源代码通过 VCS 修改时、跨多个环境运行测试，确保持续的质量水平。
二、工具、源驱动开发与 CI/CD
第 2–4 单元介绍让包开发模型落地的工具与工作流：Salesforce CLI 与 VS Code 集成、scratch orgs（一次性的可配置环境）、源驱动开发工作流，以及从提交到生产的 CI/CD 流水线。
临时组织、源驱动开发与 CI/CD
Salesforce Command Line Interface（CLI） 是一个灵活强大的命令行工具，可用它从命令行管理包开发流程。它整合了多个 Salesforce API 的能力（Metadata API、Tooling API、Data/SOAP API），把来自所有重要 API 的开发任务集中在一处——从创建组织到导入导出数据，管理完整开发生命周期所需的一切，都可以脚本化。
CLI 是「机会均等」的生产力增强器：开发者用它管理 DX 项目、创建 scratch org、向 scratch org 部署/检索元数据、运行单元测试；DevOps 把它用于构建自动化脚本——创建和访问环境、部署源代码、安装包、运行测试。
Agentforce Vibes 是一个专为 Salesforce 开发打造的强大集成开发环境，内置扩展提供：与 Salesforce CLI 交互、为包开发创建项目、访问 Apex Language Server（语法高亮与代码补全）、支持 Lightning 组件 bundle、支持 Apex 与重放调试器、以及生成式 AI 辅助编写/测试/调试/重构代码。它已预集成 Git，也能配合其他版本控制系统。如果你更喜欢本地开发环境（如 Visual Studio Code），Salesforce 也为 VS Code 提供了同样的扩展。
版本控制系统（VCS）是源驱动开发的核心。要从新工具与包开发中充分获益，你需要 VCS 来管理和版本化源代码。如果还没用 VCS，可以从创建一个包开始理解流程：一个 DX 项目对应一个包的开发，配一个对应的 VCS 仓库。熟悉之后，再考虑跨一个或多个 VCS 仓库设计包项目的新方式。
Scratch Orgs（临时组织）被设计为「短暂、易于重建」——它们是专用、可配置的 Salesforce 环境，可以快速创建用于各种目的。作为开发与测试流程的一部分，scratch org 可以是你个人的开发环境，也可以为自动化测试创建无头 scratch org。需要时你就可以创建一个新 scratch org：启动新项目、新功能分支、测试新功能、自动化测试、直接在组织里做开发任务、或从一个全新组织「从零开始」。你可以用不同的 Salesforce 版本、以及你想要的功能与偏好来配置 scratch org，并与团队成员共享配置文件，让大家拥有相同的基础组织。
Scratch org 与沙箱的区别：scratch org 没有能力容纳生产组织里全部交织的元数据，也并非要取代沙箱。分析要部署到 scratch org 的元数据时，要问自己：这些定制都只关联单个应用/CRM 扩展吗？还是代表了大量不同的应用或项目？如果是后者，就把它们拆分成包，为每个独立模块创建单独的 scratch org 测试，之后再把这些独立的包部署到沙箱做最终测试与暂存。
沙箱仍然重要：尽管 scratch org 能大幅提升生产力，沙箱仍是包开发生命周期的重要部分——它们作为你创建的包版本安装测试的目标/目的地。安装后，你继续用它们做用户验收测试、暂存环境与持续交付测试。把源开发用例对应到 scratch org，把发布与部署测试对应到沙箱。
源驱动开发（Source-Driven Development）：Salesforce DX 项目是元数据在源代码格式下的本地目录结构，让你能用 Salesforce DX 工具开发与测试。它包含创建 scratch org 的配置文件、可加载到组织做开发/测试的数据、以及验证包所需的测试。用 CLI 创建新项目时，会为你生成项目目录结构：基础项目配置文件、示例 scratch 定义文件、测试与示例数据集目录，以及存放包源代码的默认 package 目录。一个包是一组相关代码与定制，可独立于组织中其他组件测试、独立发布；一个元数据组件同一时间只能存在于一个包中。DX 项目格式会把大源文件拆成更易消化、更易用 VCS 管理的小文件（例如把自定义对象与翻译拆成多个文件目录），从而减少团队开发时的合并冲突。
创建 scratch org 后，把项目的所有源代码部署到 scratch org、设置权限、创建或加载包所需的测试数据。IDE/文本编辑器用于程序化（代码）开发，scratch org 用于声明式（点击式）开发——与在沙箱/生产组织中的做法类似，区别在于源驱动模型会把你在 scratch org 中做的任何开发同步回本地项目，让你能把 Setup 页面里的变更与本地 IDE 里的变更一起提交。提交到 VCS 前务必运行测试——可以用同一个 scratch org 测试，或专门再建一个用于测试。
持续集成（CI）是自动对合并到应用的每一组变更运行一致的测试，确保应用质量，防止任何损坏性变更进入源代码仓库。scratch org 很容易集成进 CI 流程——CLI 能创建 scratch org，把它脚本化进 CI 流程轻而易举；你可以用适当版本的源代码仓库填充组织，并对特定变更运行测试。与开发者沙箱每天只能刷新一次不同，scratch org 一天内可随时创建；需要时能快速删除并新建，还能为不同目的维护多个 scratch org，用极少的开销带来极大的灵活性。
做手动或探索性测试时，把元数据部署到专门用于测试的 scratch org（该组织只用于测试/验证，从不从中检索）。准备发布测试或持续交付自动化时，创建包版本——不是用变更集在环境间移动变更，而是在每个测试环境里创建并安装包版本；完成测试后，在生产组织安装包版本。
持续交付（CD）使用沙箱：用构建阶段创建的包在沙箱中安装测试（沙箱是生产组织的最佳代表），复制并测试发布到生产组织的步骤。
你仍然可以只部署一组变更：尽管包开发是管理交织元数据变更的好方法，你仍支持在包之外挑选要部署的内容，用 CLI 的 project deploy start 命令处理构建与部署用例。
三、规划你的包迁移之旅
迁移到包不是一天就能完成的「大爆炸」，而是一段旅程。本单元讲解为什么 unlocked packages 现在对所有 Salesforce 客户开放（不只是合作伙伴）、如何组建合适的团队、如何把单体组织拆解出包边界、如何处理共享元数据，以及开始包化之旅的实用第一步。
你的包开发路线图
为什么现在是采用包化的好时机：过去包是为想在 AgentExchange 上构建和分发应用的合作伙伴准备的，但现在企业客户也有了新选择——unlocked packages。无论你是 Salesforce 客户、承包商、顾问还是系统集成商，unlocked packages 都适合你。它们提供一种可重复、可脚本化、可跟踪的方式来组织工作、在开发功能时管理变更。Salesforce CLI 与 DX 项目让创建 unlocked packages 变得轻而易举，且可安装到任何 Salesforce 环境：scratch org、沙箱、试用组织与生产组织。
组建团队：「没有人是一座孤岛」，团队亦然。公司里 Salesforce 生产组织往往有众多利益相关者。在开始包开发之旅前，首要任务之一就是如何「拆解」你的组织。在开始前，把合适的人纳入团队很重要——包括：架构师（设计包边界与依赖）、开发者（构建并拥有包）、发布经理（协调包版本化与部署）、以及利益相关者（理解模块化独立发布的价值）。
寻找把组织拆解成包的方法：评估开发流程的各个方面，寻找向模块化、基于包的方法转变的可能。寻找生产组织中与其余部分独立的独特应用——如果有独立团队构建和维护这些应用，就能把它们隔离进各自的包。有时你没有可拆分成包的独立应用，但有随着时间积累的组织的独特部分，例如对核心应用所做的扩展，可以隔离到一个包中。也可以寻找那些已经或希望独立构建与交付的团队——希望更敏捷灵活、或希望把变更从生产组织更大的变更管理流程中分离出来的团队，他们可以隔离元数据、存储到自己的包中。如果你发现拆解组织中的元数据非常困难，org-dependent unlocked packages（组织依赖型未锁定包）可能适合你——它是 unlocked packages 的一种变体，允许你创建依赖于安装组织中未打包元数据的包。
警惕共享元数据：评估所有潜在包时，务必检查共享元数据组件，避免无意中把共享元数据隔离到某个特定团队或应用拥有的包里。如果元数据组件是共享的，建议把这些共享组件组织到一个基础包（base package）中，这样所有包都能引用共享基础包里的组件（记住：元数据组件同一时间只能存在于一个包中）。
启动你的包项目：识别出潜在包后，用 Metadata API 检索与包相关的源代码；检索到元数据格式的源代码后，把它转换为源代码格式。然后为每个包创建一个 VCS 仓库，继续针对这些应用构建特定包。
罗马不是一天建成的：如果组织成熟或复杂，向包的迁移需要逐步进行。生产组织是你最宝贵的财产，务必深思熟虑地规划转型。用本单元的指导识别可以迁移到包的组织部分，一次迁移一个包，持续评估并改进流程。
需要留意的、不适合放进包的内容：高度易变、每天变化的配置；本质上组织特有的元数据（公司信息、营业时间、邮件中继等）；有些东西仍然留在组织里，用传统方式部署。目标不是 100% 包化，而是在能带来价值的地方实现独立可部署。