Salesforce开发生命周期（6）迁移环境之间的更改

学习目标

完成本单元后，您将能够：

手动迁移更改
如何迁移元数据文件
什么会影响部署时间？
监控部署状态
测试部署的最佳实践
部署依赖性

迁移是将配置更改从一个Salesforce组织移动到另一个组织的行为。在开发周期中，您可以多次迁移，以使开发组织保持同步，或者将更改通过开发组织转移到生产环境中。

迁移可以通过两种方式进行：手动或通过Metadata API。

手动迁移 – 必须在每个环境中手动迁移对Metadata API中不可用的组件的更改。也就是说，您必须在每个生产或开发组织中重复完全相同的修改。通过努力跟踪更改，可以更轻松地进行手动迁移。
元数据迁移 – 可以使用桌面工具或更改集迁移Metadata API中可用的组件。迁移更改的典型步骤是：

确定首先需要迁移哪些组件。如果要同时执行手动迁移和元数据迁移，这一点尤为重要。例如，如果需要针对自定义对象创建队列，则必须首先迁移自定义对象。
按所需顺序迁移组件：
- 查看更改列表以确定是否需要手动迁移任何内容。如果是，请登录要迁移的组织，并手动进行设置更改。
- 从服务器检索最新的元数据更改。
（可选）修改Lightning Platform项目或出站更改集，以仅部署组件的子集。
部署。

手动迁移更改

手动迁移需要通过Salesforce用户界面执行设置更改。例如，假设您在生产组织中需要新的搜索设置，但是在将其公开给用户之前，您希望在沙箱中进行开发和测试。由于Metadata API中没有搜索设置，因此将搜索设置迁移到生产组织的唯一方法是在沙箱中手动重新创建它们。

您可能认为避免手动迁移的最简单方法是在生产中进行所有更改，然后刷新沙箱。虽然这是可能的，但完整的沙箱只能每29天更新一次，还有其他重要的考虑因素。此外，必须在每个开发组织中手动迁移生产中的任何更改。由于组件依赖关系在部署中发挥重要作用，因此您在生产组织上所做的更改可能会阻止您部署在沙箱上开发的应用程序。如果您有多个开发组织，则必须多次手动将更改从生产迁移到沙箱。由于这些原因，开发生产可能比手动将更改从沙箱迁移到生产更困难。

注意：可以在生产中开发许多自定义和功能，但这些更改不需要测试和培训。

管理手动迁移的最佳方法是在生产组织上建立更改流程，并跟踪需要手动迁移的更改。

如何迁移元数据文件

使用元数据文件将更改从一个组织迁移到另一个组织需要使用Metadata API与两个环境交互的中间工具。下图显示了如何将更改从沙箱迁移到生产。

您可能想知道为什么需要本地项目来迁移存储在云中的文件。这是因为Metadata API旨在支持对源文件进行操作的传统软件开发工具，例如文本编辑器，差异/合并实用程序和版本控制系统，所有这些都需要本地文件系统。创建Lightning Platform项目后，您可以多次直接部署到生产组织;除非要与服务器同步，否则无需检索文件。

什么会影响部署时间？

通过调用Metadata API deploy（）方法，可以将元数据从本地目录迁移到Salesforce组织。 Force.com IDE和Ant迁移工具都使用此方法，因此使用任一工具时部署时间差别不大。 deploy（）方法是异步的，这意味着它可能不会立即返回结果，并且有几个因素决定了这些结果的返回速度：

文件的数量和大小 – 部署的越多，部署所需的时间越长。但是，网络有效负载很少大于10 MB，因此原始文件大小通常不起重要作用。
组件类型 – 某些组件的处理时间比其他组件长。例如，自定义字段，自定义联结对象和配置文件比其他组件需要更长的部署时间。
处理时间 – 进行需要重新计算数据的更改需要花费一定的时间与必须修改的数据量成比例。例如，更改字段类型可能需要修改使用该字段的所有记录。
测试执行 – 部署到生产组织时，Apex测试的数量和复杂性会对部署时间产生很大影响。
网络和服务器可用性 – 与其他因素相比，这些问题最少。但是，请考虑在非高峰时段安排长时间部署，以便您不会在工作时间等待部署或锁定组件使用。
锁定 – 如果用户在部署期间在组织中工作，则锁定可能会影响用户和部署。用户可能被锁定在组件之外，或者部署可能正在等待用户释放锁定。运行时间最长的进程是重组拥有大量记录的用户（或用户组）的进程。例如，如果规则共享由三个用户拥有的100个记录和另外六个用户，则更改共享规则不会花费太多时间。但是，如果该用户拥有一千兆字节的记录，则在角色或区域层次结构上移动一个用户需要很长时间。用户可以强制处理大量记录的其他方式包括：
1. 创建受预测影响的门户网站用户或用户
2. 创建，修改或删除共享规则
3. 当存在大量关联记录时，移动或更改用户，角色，组，帐户所有者或团队成员身份

监控部署状态

元数据组件的大小和复杂性会影响部署时间。要跟踪正在进行或已在过去30天内完成的部署的状态，请从“设置”中，在“快速查找”框中输入“Deployment Status”，然后选择“Deployment Status”。部署根据其状态列在不同的部分中。

此页面列出了所有部署 – 更改集，基于Metadata API的部署，包括从Force.com IDE和Ant迁移工具启动的部署以及程序包安装。

正在进行和排队的部署

运行部署时，“部署状态”页面会显示当前部署的实时进度。此页面包含可以直观显示整体部署进度的图表。第一个图表显示已经部署了多少组件，包括有错误的组件数量。例如，下图表示已成功处理了302个组件，其中有45个组件有错误。

在部署所有组件且没有错误之后，如果需要或启用，Apex测试将开始执行。第二个图表显示了测试总数和返回的错误数量中有多少Apex测试耗尽。此外，该图表还显示了当前运行的测试的名称。例如，在下图中，共有120个测试已完成执行，1个测试失败。

显示当前部署的以下信息。

字段	说明
名称	更改集名称或用于跟踪Metadata API部署的唯一标识符。对于Metadata API部署，deploy（）调用返回此值。
类型	部署类型：更改集或API。
部署者	执行部署的用户的名称。
开始时间	部署实际开始的日期和时间，而不是请求排队的时间。此值是部署状态设置为“正在进行”的时间。
验证	部署验证完成的日期和时间。

如果当前部署有错误，您可以通过单击“View Errors”在部署完成之前查看这些错误。

待部署

您可以启动多个部署，但一次只能运行一个部署。当前部署完成后，其他部署将保留在队列中等待执行。排队部署按照将要执行的顺序列在Pending Deployments下。

部署验证

部署验证是一种部署，仅用于检查部署组件的结果并进行回滚。验证不会以任何方式保存任何已部署的组件或更改Salesforce组织。您可以通过在“失败和成功”部分中检查待处理部署的信息或部署的“状态”列来确定部署是仅验证（验证）还是实际部署（部署）。

如果验证在过去10天内成功完成，并且所有测试都通过足够的代码覆盖率传递，则可以通过将此验证部署到生产中而不运行测试来执行快速部署。请参阅快速部署。

取消部署

您可以通过单击部署旁边的“Cancel ”来取消正在进行的部署或队列中的部署。然后，部署的状态为Cancel Requested，直到部署完全取消。已失败的部署列在“失败”部分中。

已完成部署

已完成的部署根据其状态列在“失败”或“成功”部分中。

已完成但已失败的部署以及已取消的部署将在“失败”部分中列出。未对这些部署的Salesforce组织进行任何更改，因为文件丢失，组件出错，测试失败或部署已取消。

成功完成或部分成功的部署列在“成功”部分中。只有部署到非生产组织才能部分成功。这些部署在部署选项中将rollbackOnError字段设置为false，并且在组件子集中存在错误。在部分成功的部署中，未提交失败的组件，并将其余组件提交给组织。

要获取有关部署的更多详细信息，请单击部署旁边的“查看详细信息”。使用“部署详细信息”页面上的信息可以查看错误并解决部署失败或部分成功的问题。 “部署详细信息”页面包括部署期间发生的错误消息，带有堆栈跟踪信息的Apex测试错误，代码覆盖率警告以及有关慢速测试的信息。为了成功部署，“部署详细信息”页面显示有关部署的信息，包括部署了多少组件以及运行了多少Apex测试。

部署状态

“失败”和“成功”部分中已完成部署的“状态”列列出了部署的类型和状态，并包含两部分：

前缀表示部署是仅验证（Validate :)还是实际部署（Deploy :)。
•状态值的第二部分包含部署状态：失败部署失败或取消，成功部署成功或部分成功部署成功。

快速部署

作为部署的一部分，所有Apex测试都在生产中运行。如果生产组织包含许多Apex测试，则执行测试可能非常耗时并且可能会延迟部署。为了减少生产的部署时间，您可以通过跳过测试的执行来执行快速部署。满足以下要求时，可以对变更集和Metadata API组件进行快速部署。

在过去10天内，组件已成功验证目标环境。
作为验证的一部分，目标组织中的Apex测试已通过。
符合代码覆盖要求。
1. 如果运行组织或所有本地测试中的所有测试，则整体代码覆盖率至少为75％，并且Apex触发器具有一定的覆盖率。
2. 如果使用“Run specified tests”测试级别运行特定测试，则所部署的每个类和触发器将至少分别覆盖75％。

验证是一种仅用于检查部署组件结果的部署，不会保存组织中的任何组件。通过验证，您可以查看实际部署时收到的成功或失败消息。您可以通过API或Ant迁移工具验证更改集或元数据组件。

要了解如何验证更改集，请参阅Salesforce帮助中的验证更改集。

要使用Ant迁移工具验证组件，请在部署目标中将checkOnly选项设置为true。请参见“Ant迁移工具指南”中的“将更改部署到Salesforce组织”。

通过用户界面或API执行快速部署

要执行快速部署，首先在需要部署的组件集上运行Apex测试执行的仅验证部署。如果验证成功并且有资格进行快速部署，则可以开始快速部署。

您可以在用户界面中快速部署经过验证的更改集和Metadata API组件。在“部署状态”页面中，通过单击验证旁边的“Quick Deploy ”或验证的详细信息页面来部署最近的验证。此按钮仅出现在合格验证中。

要了解如何快速部署更改集并运行特定测试，请查看此视频：发布管理：使用快速部署和测试级别（Salesforce Classic）有效部署更改。

或者，您可以通过Metadata API或元数据API组件的Ant迁移工具（不包括更改集）开始快速部署。对于Metadata API，请调用deployRecentValidation（）并将验证ID传递给它。对于Ant迁移工具，请使用任务。

注意：快速部署已启用最近验证，其中Apex测试已成功执行且已满足代码覆盖要求。请注意以下内容。

在生产中，支持快速部署以满足标准的验证。您可以部署最近的更改集和Metadata API组件的验证（包括使用Ant迁移工具验证的组件）。

在沙箱中，仅对显式启用测试执行的验证支持快速部署（例如，通过在验证入站集时选择测试选项或通过迁移工具的testLevel参数）。默认情况下，不需要Apex测试，也不在沙箱部署中运行。

如果在验证后执行部署，无论是通过快速部署，软件包安装还是常规部署，所有验证都不再符合快速部署的条件。重新验证要快速部署的组件集。

长期测试的性能调优资源

如果需要或已启用，在部署所有组件后，Apex测试将作为部署的一部分运行。 Apex测试需要很长时间才能执行延迟整个部署。前五个长期运行的测试，即运行时间超过两分钟的前五个测试，将在“部署详细信息”页面中标记为已完成的部署。您可以提高这些测试的性能，使其更高效，并加快未来的部署。导致性能下降的原因可能很多。例如，访问组织数据而不是使用测试数据，或者执行性能较差的SOQL查询或Apex代码。以下是一些可用于了解Apex和SOQL性能最佳实践的资源。

测试部署的最佳实践

使用这些建议在部署中运行测试到各种环境，以确保生产中的高质量部署和更短的部署时间。

通过在部署选项中设置RunLocalTests测试级别，将部署中的本地测试运行到开发环境（如沙箱）。在开发环境中运行测试使您有机会尽早捕获并修复任何故障，并确保更好的生产部署体验。
在部署之前通过执行部署验证来验证组件。部署验证是一种部署，仅用于检查部署组件的结果并进行回滚。验证不会以任何方式保存任何已部署的组件或更改组织。

使用在过去10天内成功执行快速部署的最近验证。快速部署是部署不运行测试的验证，并有助于缩短生产的部署时间。

使用RunSpecifiedTests测试级别指定要运行的测试。此选项使您可以运行测试子集，而不是运行组织中的所有测试，从而减少总测试执行时间。

部署依赖性

无论是在开发环境之间迁移更改还是将更改部署到生产组织，都有许多因素会影响部署是否成功。这些因素中最重要的是依赖性。

有几种不同的依赖关系：

Parent-child—元数据组件可能依赖于其他组件。例如，如果不部署自定义对象，则无法部署自定义字段，因为字段的存在取决于对象。这些对象依赖关系并不总是在同一个对象中; 它们可以跨越不同的对象。例如，如果目标对象未包含在部署中或已存在于目标组织中，则无法部署一个对象上的关系字段。

Referenced file—另一个文件引用的每个文件都必须包含在部署计划中，或者已经包含在目标组织中。例如，如果您有一个Visualforce页面将图像作为静态资源引用，并且目标组织中不存在该图像，则必须在部署中包含该图像。必须通过Metadata API提供引用的文件。例如，如果同一个Visualforce页面引用了个人文档文件夹中的图像，并且您在部署计划中包含了所有文件夹，则部署将失败，因为通过Metadata API无法获得个人文档。

Ordering—依赖关系要求以特定顺序部署组件，并且在单个部署操作中，此顺序由Metadata API自动处理。但是，如果部署组件的子集，或将部署拆分为多个批次，则必须自己考虑订购依赖关系。

Mandatory fields—使用Force.com IDE或Salesforce用户界面创建对象时，该工具会强制创建必填字段。但是，在处理本地目录中的文件时，可以创建或修改缺少必填字段的元数据文件，因此无法部署。您还可以通过在组件之间复制和粘贴来引入这些类型的错误。