学习目标
完成本单元后，您将能够：
- 手动迁移更改
- 如何迁移元数据文件
- 什么会影响部署时间？
- 监控部署状态
- 测试部署的最佳实践
- 部署依赖性
迁移更改的最简单方法是在单个操作中部署所有更改。但是，您可能希望将部署分成较小的部分，原因如下。
- 部署过大 – 您可以一次部署或检索多达10,000个文件，部署或检索的.zip文件的最大大小为39 MB。 （在API版本43.0及更高版本中，AppExchange软件包最多可包含12,500个文件。）
- 长时间部署 – 如果您遇到异常长的部署，则可以将部署划分为更小的部分。较小的部署可以减少由于在长时间运行的操作中持有锁而导致的用户影响。
- Apex测试 – 您可能希望将组件分为两部分：默认情况下需要测试的部分和不需要测试的部分。仅测试那些需要测试的组件加速部署并锁定更少的组件。
确定要一起部署的文件
如果您需要将部署划分为更小的部分，那么了解要同时部署哪些组件非常重要。
- 部署不触发测试的组件 – 在API 34.0及更高版本中，默认情况下需要测试的唯一组件是Apex类和触发器。所有其他组件不需要测试。
- 不要拆分依赖组件 – 因为文件依赖关系在迁移元数据中起着如此重要的作用，所以重要的是不要分离依赖组件。
- 单独部署最多的组件 – 以下组件可以是最多的组件，因此您可能希望将它们与其他组件分开部署。
- 电子邮件模板可以单独部署，但必须在使用模板的组件之前部署。
- 仪表板可以单独部署，但在报告之前部署它们，以防自定义按钮链接到报告。
- 报告可以包含最多的组件。它们可以在所有其他组件之后以多个批次部署。
- 电子邮件模板可以单独部署，但必须在使用模板的组件之前部署。
使用Force.com IDE部署批量文件
有两种方法可以使用Force.com IDE来部署批量组件：通过更改项目内容或取消选择使用Lightning Platform部署向导时不想部署的组件。
部署批量文件的最简单方法是创建新的Lightning Platform项目，并使用“选择元数据组件”对话框仅选择要部署的组件。 “选择元数据组件”对话框是一种图形工具，允许您选择单个组件或特定类型的所有组件。创建项目时，可以使用此对话框确定项目中需要的组件，但也可以随时编辑项目内容。
以这种方式创建或编辑项目内容时，幕后发生的是对package.xml文件的修改。此文件也称为项目清单，并在您检索和部署组件时确定项目中的内容。您也可以手动编辑package.xml文件，方法是将其拖到“编辑器”窗格中。
警告：如果您必须具有比对话框可以提供的更精细的控制，则建议手动编辑package.xml文件。请注意，如果在编辑package.xml文件后打开“选择元数据组件”对话框，则可以撤消所做的一些更改。
控制部署计划的另一种方法是使用Lightning Platform部署向导。此向导允许您选择要部署的项目中的组件以及要采取的特定操作：添加，删除，覆盖或不执行任何操作。要使用该向导，请右键单击Lightning Platform项目，然后选择Lightning Platform> Deploy to Server。
警告：如果您必须具有比对话框可以提供的更精细的控制，则建议手动编辑package.xml文件。请注意，如果在编辑package.xml文件后打开“选择元数据组件”对话框，则可以撤消所做的一些更改。
控制部署计划的另一种方法是使用Lightning Platform部署向导。此向导允许您选择要部署的项目中的组件以及要采取的特定操作：添加，删除，覆盖或不执行任何操作。要使用该向导，请右键单击Lightning Platform项目，然后选择Lightning Platform> Deploy to Server。
使用Ant迁移工具迁移批量文件
如果使用Ant迁移工具，则没有用于编辑package.xml文件的图形用户界面，因此您必须熟悉XML文件的格式并手动编辑此文件。 您可以调用两个部署目标，这些目标将帮助您确定要在每个必须创建的package.xml文件中包含哪些组件。
- describeMetadata – 返回为组织启用的元数据类型列表。 当您想要在package.xml中标识元数据类型所需的语法时，此目标非常有用。
- listMetadata – 返回组织中各个元数据组件的名称和其他属性，以及有关每个组件的额外信息。如果要在package.xml中包含特定组件，或者希望在组织中使用特定元数据类型的高级视图，则此目标非常有用。例如，您可以使用此目标返回组织中所有报告的名称列表，并使用此信息创建package.xml文件，该文件返回要迁移的特定报告。
有关使用这些部署目标的详细信息，请参阅“Ant迁移工具指南”。
删除和重命名组件
将组件从一个组织迁移到另一个组织时，该操作类似于upsert。也就是说，您可以将更改部署到已存在的组件，但如果该组件不存在，则会创建该组件。例如，如果组织A中有一个名为foo的组件并且您更改了数据类型，则在将该更改部署到组织B时，只要组织B中存在foo，就会更改数据类型。但是，如果foo不存在在组织B中，创建整个组件。
如果重命名组织A中的组件并将该组件部署到组织B，则可能希望在组织B中更改名称，而是在组织B中创建新组件。这是因为部署操作会查找匹配的名称。由于组织B中不存在具有该名称的组件，因此会创建一个新组件。例如，如果在组织A中将foo重命名为foos，然后将该更改部署到组织B，则会在组织B中生成两个组件，foo和foos。
要重命名组件，必须删除该组件，然后使用新名称重新创建它。用于删除组件的过程取决于环境：
- 对于开发和测试环境 – 删除组件，使用新名称重新创建组件，然后重新加载测试数据。
- 对于生产环境或登台环境 – 使用Salesforce用户界面重命名组件。这样可以保留现有记录中的数据。
项目清单（package.xml）确定项目中部署的内容，但此文件不能用于处理删除。要删除Lightning Platform项目中的文件，必须创建项目清单并将其命名为DestructiveChanges.xml。在部署中包含此文件时，将在目标组织中删除指定要删除的组件。
使用AppExchange迁移更改
可以使用AppExchange在组织之间移动元数据，但这不是迁移更改的有效方法。非托管软件包不允许您安装相同名称的组件，因此在初始安装后无法进一步修改这些组件（通过非托管软件包）。
另一种包是托管包。托管包添加的约束条件使它们不适合用作IT开发工具。此外，虽然可以使用任何类型的组织来创建非托管包，但必须使用Developer Edition组织创建托管包。
注意：非托管包对于将初始组件分发给多个组织非常有用。例如，如果您希望所有开发环境都具有相同的核心Apex类集，则可以打包它们并将它们分发到AppExchange上。使用非托管包是将文件传送到多个开发环境的便捷方式，但不能用于对这些文件进行进一步更改。
部署到生产
部署到生产组织的工具和流程类似于将更改从一个开发环境迁移到另一个开发环境的工具和流程。但是，部署到生产中存在一些重要的差异，并涉及额外的步骤。部署到生产组织时所采取的步骤取决于IT部门的策略以及部署的内容。部署到生产没有规定的过程，但有一些最佳实践可以遵循。
在用户未对您的组织进行更改的期间进行部署非常重要。还要执行测试部署以确保生产部署的成功。这些步骤通常在维护窗口期间发生。在此期间，用户被锁定在系统之外，因此请在非高峰时段提前规划部署。部署是一个全有或全无的事件。例如，如果在部署组织中不存在此字段，则生产组织上的单个新字段可能导致整个部署失败。由于在部署阶段对生产所做的更改可能会使最终部署无效，因此在部署完成之前不会发生任何更改。
建议创建一个临时环境，允许您在部署到生产之前进行测试部署。登台环境通常是完整拷贝沙箱，因此它与生产组织尽可能类似。因此，您应该在维护窗口期间而不是之前创建或刷新登台环境。完整拷贝沙箱可能需要一些时间来创建或刷新，因此填写维护窗口以解决此问题非常重要。
部署到登台环境的过程与从一个开发组织迁移到另一个开发组织的过程相同。此过程包括手动迁移不在Metadata API中的组件以及使用Salesforce用户界面开发的功能。此外，建议在暂存环境中手动运行所有测试，以避免在生产部署之前出现可能的问题。开发环境不会强制执行Apex测试覆盖，但生产组织会执行。
注意：Lightning平台要求至少75％的代码由单元测试覆盖，然后才能将其部署到生产组织。理想情况下，争取100％的覆盖率。对沙箱或Developer Edition组织不强制执行代码覆盖限制。
成功部署到临时环境后，需要在部署到生产之前进行其他更改。如果您在开发环境中修改了环境依赖关系（例如，为开发人员提供他们在生产时没有的权限），请将这些值更改回生产值。如果您配置服务端点以测试与外部服务的集成，则还必须将这些端点更改为其生产值。
您现在可以部署到生产环境了。首先，将用户锁定在系统之外，然后在生产组织上执行Metadata API测试部署。此步骤是验证“仅检查”部署 – 完全模拟部署，并返回部署的成功或失败，但不部署任何组件。如果在部署阶段和发生部署之间存在时间间隔，则此步骤尤为重要。如果测试部署成功，您可以使用Metadata API或Web界面部署更改，具体取决于组件。
注意：如果将字段类型从Master-Detail更改为Lookup，反之亦然，则在使用checkOnly参数测试部署时不支持更改。测试部署不支持此更改，以避免永久更改数据。如果部署包中包含测试部署不支持的更改，则测试部署将失败并发出错误。
如果部署包将字段类型从Master-Detail更改为Lookup，反之亦然，则仍可在部署到生产之前验证更改。对另一个测试沙箱执行完全部署。完整部署包括在部署过程中验证更改。
在以下情况下，包含主 – 详细信息关系的元数据API部署将删除回收站中的所有详细信息记录。
- 对于具有新Master-Detail字段的部署，在继续部署Master-Detail字段之前，软删除（发送到回收站）所有详细记录，否则部署将失败。在部署期间，详细记录将从回收站中永久删除，无法恢复。
- 对于将Lookup字段关系转换为Master-Detail关系的部署，详细记录必须引用主记录或软删除（发送到回收站）以使部署成功。但是，成功部署会永久删除回收站中的所有详细记录。
请记住，所有IT组织都不同。以下过程概述了将企业应用程序部署到生产组织时可能遵循的高级步骤。
- 宣布维护窗口。
- 停止生产中的所有设置更改。
- 创建临时环境。
- 将更改迁移到登台环境。
- 将环境依赖关系和服务从测试设置更改为生产值。
- 将用户锁定在应用程序之外。
- 使用Metadata API测试部署。
- 部署到生产。
- 解锁生产组织。
安排发布
每次将更改部署到生产环境时，您的用户都会受到直接影响，因此最好有指导来推出新功能。 Salesforce在这方面拥有十多年的经验，您可能希望将我们的推出程序建立在我们的模型上：
- 不要破坏任何东西：
- 首先在测试环境中发布您的生产功能。如果您在完整副本沙箱中成功部署和测试，则可以确信您的最终生产部署将成功。
- 备份一切。
- 有一个后备计划，以防万一。
- 安排发布：
- 创建并公布维护窗口，在此期间您的组织将无法供大多数用户使用。
- 使用配置文件来控制维护更新。
- 告知用户每个变化：
- 创建详细的发行说明，记录新功能和现有行为的更改。
- 发送电子邮件，宣布主要功能，并附带发行说明的链接。
- 创建网络研讨会和培训课程以教育用户。
使用配置文件控制维护更新
在部署窗口期间，您可以使用用户配置文件来限制最终用户对生产组织的访问：
- 创建并公布维护窗口，在此期间您的组织对大多数用户不可用：
- 从“设置”中，在“快速查找”框中输入“Mass Email Users”，然后选择“Mass Email Users”以访问电子邮件向导，该向导允许您向维护窗口的所有激活的用户。
- 使用配置文件创建和管理维护窗口：
- 在用户配置文件中编辑登录时间以在维护窗口期间锁定大多数用户。确保任何系统管理员或集成用户在需要时都可以访问。
- 如果要允许某些用户访问用户验收测试，请有选择地将对象，选项卡和应用程序推出到不同的用户配置文件。
如果您的组织包含许多配置文件，请使用以下策略设置维护时段：
- 创建一个名为Maintenance的新配置文件，锁定所有登录时间。
- 使用数据加载器提取并保存用户及其用户配置文件的映射。
- 在维护窗口的开头，使用数据加载器将除管理员之外的所有用户配置文件更改为维护配置文件。请注意，与管理员保持登录访问权限非常重要，否则所有用户都可能无限期地被锁定在系统之外。如果要在维护窗口期间运行任何集成，则也不应锁定集成用户。
- 在维护窗口结束时，使用Data Loader以其原始配置文件重新加载用户。
修复错误
修复错误的位置取决于错误的严重程度以及IT部门的具体情况。一般来说，有两种选择：在生产组织或开发环境中进行修复。最佳做法是在一个地方进行所有更改，然后按照可重复的过程将更改移至生产环境。此过程的一个版本如下图所示：
当您具有需要立即投入生产的高优先级错误修复时，此过程并不总是切实可行。在这种情况下，您必须修复生产环境中的错误，然后将相同的错误修复迁移到您的开发环境。这很重要，因为从开发环境迁移更改时，可能会覆盖对生产组织所做的更改。此过程的一个版本如下图所示：
