Apex 部署与托管包
Apex 不能在生产组织中直接开发——所有开发工作在 Sandbox、Scratch Org 或 Developer Edition 组织中进行。部署通过 Change Set、VS Code/CLI、Metadata API、Tooling API 或 DevOps Center 将代码从开发环境迁移到生产环境。
Compile On Deploy
组织中的 Apex 代码在元数据部署、包安装或包升级完成前自动重新编译。生产组织和 Full Sandbox 默认启用——确保部署后用户不会立即遇到性能下降（不可禁用）。Developer/Developer Pro/Partial Copy Sandbox 和 Developer/Trial/Scratch Org 默认禁用——可在 Setup → Apex Settings → Perform Synchronous Compile on Deploy 启用。部署时调用 Apex 编译器并将字节码保存为部署的一部分——例如部署自定义字段时所有使用该字段的类被重新编译。部署时间可能略微增加——但后续请求不需要重新编译。对多用户共享的功能测试 Sandbox 或 CI 流程尤其推荐启用。
部署方法：Change Sets 与 VS Code
Change Sets（变更集）：在连接的 Salesforce 组织之间部署——从 Sandbox → Production。使用 Outbound Change Set（源组织选择组件——Apex 类/触发器/自定义对象/字段等）→ Upload → 目标组织 Inbound Change Set → Deploy。仅适用于 Performance/Unlimited/Enterprise Edition。Developer Edition 不支持——使用其他部署方法。部署连接需预配置。
VS Code & Code Builder：使用 Salesforce CLI 和 Salesforce API——sf project deploy start 命令。支持源格式（source format）和元数据格式（metadata format）。直接从本地项目部署到任意 Salesforce 组织——支持 Scratch Org、Sandbox 和 Production。集成源代码控制（Git）——实现 CI/CD 流水线。
部署方法：Metadata API、Tooling API 与 DevOps Center
Metadata API：部署自定义信息——自定义对象定义、Apex 类/触发器、页面布局、工作流规则等。deploy() 调用异步部署元数据组件——配合 package.xml 清单文件指定部署内容。支持多组件部署和回滚。
Tooling API：部署 Apex 类或触发器——可在复杂类型中更改单个元素（如只修改类的单个方法签名）。比 Metadata API 更轻量——仅部署特定组件而非整个元数据包。适合 CI/CD 中的增量部署。
DevOps Center：改进的变更和发布管理体验——构建流水线（Pipeline）推广工作项从开发→测试→生产。配置 DevOps Center 后通过流水线自动化推进发布生命周期。集成源代码控制和自动化部署检查。
托管包类型与 Apex 版本化
托管包类型：First-Generation Managed Package (1GP)——传统托管包模型；Second-Generation Managed Package (2GP)——新一代，支持命名空间组织分离、更灵活的版本管理、源驱动开发。Apex 版本设置：每个类和触发器关联特定 Salesforce API 版本——控制编译行为和可用 API 功能。托管包订阅者可为每个引用托管包的类/触发器指定包版本——确保行为稳定。
Apex 项：已版本化、未版本化与变更规则
已版本化：global 类/方法/变量/接口——在托管包中发布后签名不可更改（只能添加新方法或弃用）。webservice 方法不可弃用。@Deprecated 注解标记弃用项——新订阅者不可见但现有订阅者继续工作。
未版本化（可更改）：public/protected/private 成员——包内修改不影响外部订阅者。内部实现细节——订阅者不应依赖未版本化 API。
托管包安全审查：AppExchange 安全审查确保代码质量和安全合规。认证托管包有独立 Governor Limit 集——与订阅者组织代码的 Limit 分离。
测试与托管 Apex 最佳实践
- 部署前运行所有测试——至少 75% 代码覆盖率。每个触发器必须有测试
- 使用
@isTest(OnInstall=true)标记包安装时运行的测试 - 认证托管包的测试在安装时运行——确保安装后功能正常
- 使用命名空间前缀保护代码——避免与订阅者组织代码冲突
- 暴露为 global 的 API 必须在后续版本中保持向后兼容
- 使用 @Deprecated 标记弃用项而非直接删除——给予订阅者迁移时间
- 使用 @TestVisible 暴露测试所需的 private 成员
- 使用 Stub API 创建 Mock 对象——不需要将测试代码打包部署
安全包升级流程
托管包升级流程：(1) 在开发 org 中开发新版本——保持所有 global API 向后兼容；(2) 使用新的包版本号创建 Beta 包——在测试 org 中完整测试；(3) 发布版本前确保所有 @isTest(OnInstall=true) 测试通过；(4) 上传包到 AppExchange——安全审查通过后发布；(5) 订阅者通过 Package Upgrade 安装新版本——自动保留现有数据和配置。版本号格式：major.minor.patch——Major 升级需特殊授权。发布后不可回滚版本——只能发布新版本修复问题。
理解部署方式和托管包版本化规则是构建可分发的企业级 Salesforce 应用的基础——从 Change Set 到 Metadata API 再到 AppExchange 包发布。