构建和发布应用

编写完代码后，下一步是部署它。我们提供不同的 基于您作为客户、系统集成商或独立机构的角色和需求的部署选项 软件供应商 （ISV） 合作伙伴。

要了解不同开发模型的优势，请查看这些 Trailhead 模块：

  • 确定应用程序生命周期管理模型 适合您
  • 应用程序生命周期和开发模型
  • 软件包开发模型
  • 快速入门： 解锁套餐
  • 解 锁 客户套餐

根据你的采用准备情况，请查看下表，了解建议的选项：

交付应用程序的发布选项

客户和非 ISV 合作伙伴

  • 解锁包解锁的包适用于想要组织元数据的客户 到包中，并将元数据（通过包）部署到不同的组织。注意一 Unlocked Package 提供非托管包的超功能集。 因此，此列表中不包含非托管包。查看更多 信息，请参阅已解锁 包。
  • 通过 Salesforce CLI 更改集或组织开发

ISV 合作伙伴

  • 第二代托管软件包如果你是开发应用并列出应用的 ISV 在 AppExchange 上，Salesforce 建议使用托管软件包。第二代托管 打包（托管 2GP）为 AppExchange 合作伙伴开创了一种新的开发方式， 分发和管理他们的应用和元数据。您可以使用托管的 2GP 来组织 源代码，构建小型模块化软件包，与您的版本控制系统集成，以及 更好地利用您的自定义 Apex 代码。您可以通过以下方式执行所有打包操作 Salesforce CLI，或使用脚本自动执行它们。有关托管的更多信息 2GP 封装，参见第二代 托管打包开发人员指南。
  • 第一代托管软件包与托管 2GP 类似，使用托管 1GP 包 由 ISV 通过 AppExchange 将其业务应用程序分发给客户。如果你是 熟悉第一代托管软件包，并希望详细了解 1GP 如何 与 2GP 不同，请参阅 First- 和 第二代托管包。有关托管 1GP 的更多信息 软件包，请参阅创建第一代托管 使用 Salesforce DX 打包。

还没准备好进行软件包开发？

如果你或你的团队尚未准备好进行包开发，则可以继续使用更改 设置，或尝试使用组织开发模型，在该模型中，您可以使用 Salesforce CLI 部署更改。 有关更多信息，请参阅使用元数据 API 构建和发布您的应用程序。

  • 使用元数据 API
    构建和发布应用 在沙盒中开发和测试应用。使用 Salesforce CLI 或 Salesforce Extensions for VS Code 检索和部署源。此开发工作流称为组织开发模型。

使用元数据 API 构建和发布应用

在沙盒中开发和测试应用。使用 Salesforce CLI 或 Salesforce 扩展 让 VS Code 检索和部署源。此开发工作流称为组织 发展模式。

使用组织开发模型在沙盒中进行开发和测试

与更改集类似，发布工件是一组要在 生产组织。您可以使用这些命令开发、测试和部署更改。如果您想了解更多相关信息 开发模型，请参阅 Trailhead 中的组织开发模型模块。project deploy

开发和发布环境

  1. 开发和测试：每个团队成员都有自己的开发人员沙盒 创建他们分配的自定义项。开发人员沙盒不包含生产数据。
  2. 内部版本：每个团队成员都从他们的 将相应的 Developer 沙箱连接到共享的 Developer Pro 沙箱以进行集成。开发人员专业版 沙盒不包含生产数据，但您可以使用测试数据为沙盒设定种子。
  3. 测试版本：对于用户验收测试，团队使用部分沙盒 以创建生产的完整副本。
  4. 释放：在发布投入生产后，团队可以使用完整沙盒来执行以下操作 培训用户，避免更改生产数据的风险。完整沙盒包括 生产数据。

我需要什么工具？

工具描述
Salesforce DX 项目Salesforce DX 项目包含元数据和源文件，这些文件组成 变化。DX 项目具有特定的项目结构和源格式。在 除了源文件之外，该项目还包含一个配置文件 sfdx-project.json。此文件包含项目信息，并启用 您可以利用 Salesforce DX 工具完成许多开发任务。
部署项目测试更改后，创建部署项目，即包含要部署的已更改文件的 .zip 文件。部署发布 首先将工件添加到完整（暂存）沙盒，然后最后添加到生产环境。你可以想 作为入站更改集的部署项目。更改在以下时间之前不会生效 它们已部署。
源代码管理系统所有更改都将合并并存储在源代码管理系统中，该系统包含 Salesforce DX 项目。
Salesforce 命令行界面您可以将 Salesforce CLI 用于组织开发生命周期的每个阶段。它 通过为您的所有开发、测试和 自动化用例。
适用于 VS Code 的 Salesforce 扩展适用于 VS Code 的 Salesforce 扩展基于 Salesforce CLI 和 Visual Studio 构建 法典。它们共同构成了一个集成开发环境，用于在 闪电平台。您可以直接从命令面板运行 Salesforce CLI 命令，或者 终端。
变更管理机制使用正式的更改跟踪在外部捕获更改仍然很重要 工具，例如更改列表、部署运行列表和其他项目管理 工具。

部署 Apex Code 的注意事项

要将 Apex 部署到生产环境，Apex 代码的单元测试必须满足覆盖率要求。 代码覆盖率指示类和触发器中有多少行可执行代码 由您的测试方法涵盖。编写测试方法来测试触发器和类，然后运行 这些测试来生成代码覆盖率信息。如果在启动部署时未指定测试级别，则默认测试执行 行为取决于部署包的内容。

  • 如果您的部署包包含 Apex 类或触发器，则当您部署到 生产中，将执行所有测试，但源自托管包的测试除外。
  • 如果您的包不包含 Apex 代码，则默认情况下不会运行任何测试。

您可以为非 Apex 组件的部署运行测试。您可以覆盖默认测试 通过在部署选项中设置测试级别来执行行为。测试级别为 无论部署包中存在的组件类型如何，都会强制执行。我们建议 在开发环境（如沙盒）中运行所有本地测试之前 部署到生产环境。在开发环境中运行测试可减少 生产部署中所需的测试。

  • 在本地
    开发和测试更改 以源格式开发更改，部署到开发人员沙盒并从中检索。
  • 构建和测试发布项目 在您的团队完成其开发任务
    后，过渡到构建发布阶段，以将您的更改集成到 Developer Pro 沙盒中。然后生成发布项目。
  • 在暂存环境中
    测试发布项目 暂存更改并在完整沙盒中运行回归测试。
  • 将应用发布到生产环境 现在，所有测试都已在完整沙盒中通过，可以部署到生产环境
    了。
  • 取消元数据部署
    您可以从 Salesforce CLI 取消元数据部署，并指定命令完成的等待时间。

在本地开发和测试更改

对源代码格式进行更改，部署到开发人员并从开发人员处检索 沙盒。

这些步骤提供了高级工作流。

  1. 创建源代码管理存储库。
  2. 创建DX项目。
  3. 将 DX 项目文件添加到源代码管理存储库。
  4. 授权开发人员沙盒。
  5. 在开发人员沙盒中执行开发任务。
  6. 从开发人员沙盒中检索更改。如果您有一些更改，您可以 指示以逗号分隔的元数据组件名称列表。如果您有很多更改，则可以 使用清单 （package.xml）。sf project retrieve start --manifest path/to/package.xml
  7. 将更改提交到源代码管理存储库。

下一个：部署团队对 Developer Pro 沙盒所做的所有更改，然后进行测试 这些变化。

生成并测试发布项目

在您的团队完成其开发任务后，过渡到内部版本 阶段，将您的更改集成到 Developer Pro 沙盒中。然后生成版本 人工制品。

下面是工作流中用于创建发布项目的高级步骤。

  1. 从存储库中提取更改，以便本地项目包含团队拥有的所有更改 䍬。
  2. 授权 Developer Pro 沙盒。
  3. 运行 deploy 命令，该命令模拟将部署到生产环境的内容，例如：sf project source deploy --manifest manifest/package.xml --target-org dev-pro-sandbox \ --test-level RunSpecifiedTests --tests TestMyCode
  4. 打开沙盒。
  5. 执行测试。
  6. 如果测试通过，请继续执行部署版本的测试发布阶段 项目添加到部分沙箱中。然后执行用户验收测试。

测试通过后，进入发布阶段，在完整版中执行回归测试 沙盒。

在暂存环境中测试发布项目

暂存更改并在完整模式下运行回归测试 沙盒。

根据集成测试进行所有更改后，下一步 是在完整沙盒中暂存更改。将更改部署到 完整沙盒类似于用于将更改部署到开发人员的过程 专业沙盒。此阶段包括回归测试，并模拟您发布 对生产的更改。

这些步骤提供了高级工作流。

  1. 授权完整沙盒。
  2. （可选）如果您根据 Developer Pro 中的测试进行了任何更改 沙盒中，创建发布工件 （.zip）。如果没有，请使用 现有发布项目。
  3. 要在不将组件保存在目标组织中的情况下验证部署，请运行 所有本地（回归）测试。通过验证，可以验证 将在部署期间执行但不提交任何测试 变化。sf project deploy validate --manifest manifest/package.xml --target-org full-sandbox --test-level RunLocalTests
  4. 在暂存沙盒中测试实际的生产部署步骤。设置 您计划针对生产组织执行的相同快速部署。sf project deploy validate --manifest manifest/package.xml --target-org full-sandbox --test-level RunSpecifiedTests这 命令返回您在快速部署中引用的作业 ID。
  5. 接下来，使用上一个中返回的作业 ID 测试快速部署 步。sf project deploy quick --target-org full-sandbox --job-id jobID

验证部署后，您有 10 天的时间来执行快速部署到 生产。

将应用发布到生产环境

现在，所有测试都已通过完整沙盒，可以部署到 生产。

  1. 在部署运行列表中，完成所有部署前任务。
  2. 授权您的生产组织。
  3. 通过验证部署来设置快速部署。sf project deploy validate --source-dir force-app --target-org prod-org --testlevel RunLocalTests此命令返回您在快速部署中引用的作业 ID。
  4. 运行测试后，验证所有 Apex 测试是否都已通过。确保 测试至少覆盖了 75% 的部署代码。
  5. 运行快速部署：sf project deploy quick --target-org prod-org --job-id jobID
  6. 打开生产组织，然后执行 部署运行列表。

取消元数据部署

您可以从 Salesforce CLI 取消元数据部署，并指定 命令完成。

要取消最近的部署，请运行 。可以通过使用标志指定 想要取消。project deploy cancel –use-most-recent–job-id <JOBID>

sf project deploy cancel --job-id <jobid>

cancel 命令完成并在 终端窗口为 33 分钟。如果命令在等待期结束时未完成， CLI 将终端窗口的控制权交还给您。您可以根据需要调整等待时间 通过指定标志中的分钟数， 如以下示例所示：–wait

sf project deploy cancel --wait 20 --use-most-recent

对已取消部署的状态感到好奇？运行部署报告。

sf project deploy report --use-most-recent