标签： 开发生命周期

学习目标

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

1. 源控制系统和部署工具
   
2. 开发生命周期和沙箱环境
   
3. 补丁发布
   
4. 开发生命周期场景：AW计算
   
5. 持续集成过程
   
6. 处理API中不支持的元数据
   
7. 配置Ant迁移工具
   
8. 生产发布注意事项
   
9. 刷新沙箱环境

本章介绍了高级开发和发布管理的建议开发生命周期。

高级开发生命周期适用于发生并发应用程序开发以及以编程方式执行某些自定义的公司。当多个业务部门中的开发人员并行处理多个项目或同一团队中的开发人员共享应用程序的开发任务时，就会发生并发开发。在Salesforce中执行并发开发，集成来自不同开发人员的更改，测试以及通过多个中间环境将这些更改发布到生产的过程构成了开发生命周期。

描述了高级开发生命周期，并在虚构公司中举例说明了开发生命周期。

示例：示例公司：AW计算

对于本章中的场景，使用了一个名为AW Computing的虚构公司。 AW Computing是一家中型企业，为企业和个人消费者提供办公计算设备。 AW Computing拥有一个内部开发团队，其中包括四名开发人员，两名质量工程师，一名发布经理和一名产品经理等。 AW Computing已通过外部系统SAP，企业资源规划和业务系统将数据集成到Salesforce中。 AW Computing开发团队必须通过用户验收测试完成所有工作。此外，AW Computing在将版本部署到生产环境之前为员工提供正式的培训流程。该公司还需要能够快速将补丁修复程序部署到生产环境中。

以下是AW Computing的角色描述。

• 发布经理 – 负责管理发布计划并协调与业务的发布。发布经理还负责管理源控制系统。
  
• 产品经理 – 提供应用程序和功能的业务需求，并与开发团队合作实施这些需求。产品经理还执行用户验收测试，以确保已实施要求。
  
• 软件开发人员 – 在生产环境之外编写应用程序。
  
• 质量工程师 – 对正在开发的应用程序进行测试。
  
• 管理员 – 在生产组织中执行管理任务，例如创建报告。
  
• 培训师 – 对公司员工进行新的应用和功能培训。

源控制系统和部署工具

源控制系统

在迁移到其他环境之前，自定义将从沙箱迁移到中央源控制存储库。存储库（例如Git或Apache Subversion（SVN））有助于集成由并发开发实现的更改，并分离应用程序的不同版本。

源控制存储库包含Metadata API公开的整个组织元数据的副本。团队成员可以将自定义项（例如自定义对象，字段和报告）以及Apex或Visualforce代码添加到源控制存储库。然后，这些更改将与其他团队成员或其他团队开发人员所做的更改合并。源控制系统可确保质量开发过程并具有许多其他好处，包括仅部署特定版本的自定义项的能力，以及为每个项目维护单独的分支，而不会覆盖作为其他项目的一部分完成的自定义。

在您使用的源代码管理系统（例如Git）中，您可以创建具有多个分支的存储库。每个分支都包含一组由单独团队开发的更改。例如，一个开发团队可能正在开发一个在二月份上线的功能。另一个团队可能正在开发一个在三月份上线的功能。这些团队需要单独的开发人员组织和集成测试沙箱。此外，由于补丁版本包含错误修复，因此包含与新功能不同的自定义元数据和Apex代码，因此请为修补程序版本使用单独的分支。

您可以使用Ant迁移工具检索组织元数据的副本以提交源代码管理。相反，Ant迁移工具可用于将源代码管理中保存的元数据部署到组织。

Ant迁移工具

Ant Migration Tool是一个基于Java和Ant的命令行实用程序，用于从一个组织下载元数据并将其存储在文件系统的本地目录中。您还可以将本地目录中的元数据部署到其他Salesforce组织。 Ant迁移工具提供了易于自动化和灵活性。您可以通过脚本自动执行部署，并在控制文件中指定部署选项。此外，此工具还允许您在部署之前更改文件中元数据的内容。请参阅本指南前面的Ant迁移工具部分。

Force.com IDE

Force.com IDE是一个集成开发环境，用于通过使用Apex，Visualforce和元数据组件在Lightning平台上开发应用程序。 Force.com IDE构建于开源Eclipse平台之上，可作为插件使用。 IDE，Apex，Visualforce和元数据组件由本地文件系统保存。开发人员可以使用工具将这些更改从文件系统提交到源代码控制存储库。 Eclipse插件可用于直接从IDE与源控制系统交互，这使开发人员可以轻松快速地提交更改。请参阅本指南前面的Force.com IDE。

对于我们的AW Computing示例公司，以下是所使用工具的摘要。

• 源控制系统：在我们的示例公司中，我们使用Git，但任何源控制系统都可以。
• Ant迁移工具：工程师通常在其本地环境中配置Ant迁移工具。
• Force.com IDE用于开发。

变更集

变更集可用于迁移元数据组件。变更集的设计易于使用，但有局限性。例如，更改集只能包含通过Salesforce用户界面而不是Force.com IDE进行的更改，并且更改集不能用于重命名或删除组件。为了能够自动执行迁移并获得更广泛的元数据迁移支持，我们建议使用Ant迁移工具。

开发生命周期和沙箱环境

在开发生命周期中，多个任务由不同的团队执行。从开发应用程序到测试和发布，任务必须遵循特定的发布过程。一些开发和测试任务是并行完成的，而其他任务则依赖于首先完成的其他部署。为这些任务分离环境（开发，测试，集成和登台）使团队开发成为可能，并有助于确保发布的高质量。

可以使用以下沙箱环境。有关每种沙箱类型的完整说明，请参阅开发环境。

沙箱包含组织元数据的副本，有时也包含其数据。

沙箱类型

可以使用以下沙箱环境。有关每种沙箱类型的完整说明，请参阅开发环境。

• Developer
• Developer Pro
• Partial Copy
• Full

建议使用Developer和Developer Pro沙箱进行开发和测试。它们不包含任何数据（标准和自定义数据对象）。部分复制沙箱通常用于集成或用户验收测试（UAT）环境，除元数据外还包括组织数据的子集。完整沙箱是组织的所有数据和元数据的完整副本。完整沙箱是生产组织的精确副本，而其他沙箱是部分副本。

沙箱数据模板

将沙箱模板与“部分复制”和“完整沙箱”一起使用，以选择要复制到沙箱的特定对象和数据。沙箱模板使您可以控制每个沙箱的大小和内容。

在具有多个项目团队的大型组织中，您可以利用部分复制沙箱中的数据模板来分割测试工作。例如，您可以在具有较短刷新周期的多个沙箱中进行回归测试（而不是完整的沙箱）。

功能发布的推荐沙箱环境

对于功能发布，这些是推荐的沙箱环境，由任务分解。

• 对于开发和测试，建议使用以下沙箱。
  1. 用于开发的独家开发人员或Developer Pro沙箱（每个工程师一个）
  2. 用于共享测试的共享Developer或Developer Pro沙箱
• 对于集成和用户验收测试，共享部分副本沙箱
• 对于暂存更改，请使用完整沙箱

为登录共享沙箱的每个用户创建沙箱用户。每个用户使用唯一的用户帐户登录沙箱。

使用独家沙盒与共享沙箱进行开发

我们建议每个开发人员创建并使用自己的沙箱。每个开发人员拥有一个沙箱可为每个开发人员提供更多控制权 – 每个开发人员决定何时使用存储库中的最新更改或何时提交更改来刷新他或她的沙箱。

如果您的团队成员紧密合作并主要使用Salesforce用户界面中的点击式工具，则团队成员可以共享沙箱。可以通过为每个用户创建用户帐户来共享沙箱。共享沙箱使得管理沙箱并使其与源代码控制同步更容易，但这会使开发过程变得更加复杂。

下图说明了用于开发和测试的沙箱环境布局。这个高级图假设有任意数量（n）的开发人员和QA工程师，每个工程师都有一个沙盒。

用户验收测试沙箱

公司中的员工可以使用用户验收测试（UAT）沙箱来尝试新功能或执行临时测试。 例如，产品经理可能希望执行一些临时测试以确保实现功能并准备演示。 此外，培训师可以在应用程序在生产中推出之前使用新应用程序准备正式的培训材料。

建议使用部分副本沙箱或完整沙箱，以使用生产中的数据测试自定义项。部分副本沙箱包含所有组织的元数据和选定数量的生产数据，而完整沙箱包含所有生产的元数据和数据。下图基于前一个图表，并显示了使用的部分副本沙箱。

分期沙箱

登台环境是生产前开发生命周期中的最后一个环境。登台沙箱是一个完整的沙箱，其中包含生产中的所有数据和元数据 – 它是生产的完整副本，使您能够执行实际测试并捕获影响应用程序行为的任何数据相关问题。使用登台环境执行测试部署并执行最终回归测试 – 运行所有测试并确保部署成功。此任务等同于仅生成验证的部署。

注意：

• 对于Ant Migration Tool版本34.0及更高版本，通过将testLevel =“RunLocalTests”参数添加到部署目标，在暂存沙箱中运行本地测试。此参数确保在沙箱中运行的测试与生产中默认运行的测试（如果需要）相同。
• 对于Ant Migration Tool 33.0及更早版本，您可以通过将runAllTests参数设置为true，通过staging沙箱中的Ant Migration Tool运行所有测试，包括源自已安装的托管包的测试。使用runAllTests参数时，无法排除托管包测试。相反，在生产中自动运行的测试只是本地测试（没有命名空间），这些测试不是来自已安装的软件包。请参阅配置Ant迁移工具以运行测试的提示。

此外，使用登台环境执行压力和性能测试。请注意，由于Lightning Platform中的沙箱硬件与生产组织硬件不同，因此沙箱上的性能测试结果可能与生产中的不匹配。尽管如此，对分段沙箱的性能测试仍然可以帮助捕获由Apex调控器限制引起的性能问题和错误。

建议在开发过程中持续进行单元测试，以确保您的应用具有高质量。

有关更多信息，请参阅持续集成过程。

注意：更改通常仅以一种方式迁移：从源控制系统到生产组织。但是，有时如果在生产组织中手动进行更改，则必须将这些更改复制回源控制存储库，以便在下次部署时不会丢失这些更改。您可以通过在Developer沙箱中手动进行这些更改并将更改提交到源代码控制来实现。

功能发布的完整应用程序生命周期图

下图包含功能发布的应用程序开发生命周期中的所有阶段。

补丁发布

有时需要在应用程序发布后将新版本的应用程序作为补丁推送。更改的原因可能是需要快速解决的重要错误修复或更复杂的增强。对于紧急错误修复（修补程序），可以使用短发布周期将更改快速应用于生产。对于更大的变化，需要更彻底的测试，并且短周期是不合适的。相反，我们建议您使用与主要版本相同的发布过程进行重大更改。

在主要版本发布后，开发团队可能会转向新版本的自定义项。为了防止干扰新功能并将错误修复或功能增强功能与无法发布的功能混合使用，您必须将发布的自定义版本与开发团队正在处理的新版本隔离开来。因此，请使用单独的源控件分支进行新功能。

补丁发布生命周期

对于需要快速发布的小更改或修补程序，我们建议开发生命周期提供快速生产路径。使用以下沙箱：

• 使用生产中的最新工作配置的开发人员沙箱。该沙箱由负责生产支持的开发人员使用。
• 由Developer或Partial Copy沙箱组成的测试环境

使用单独的源控制分支进行修补程序发布和下一个功能发布。

• 修补程序版本的一个分支，对应于当前在生产中部署的版本（生产版本）
• 新定制的一个分支，将在未来的生产时间发布。此分支还包含修补程序发布分支的更改。

要应用修补程序版本，请从修补程序分支到生产组织进行部署。此外，需要将补丁更改从补丁分支集成到分支以进行下一个功能发布，以确保在下一个主要版本中不会丢失更改。

此图显示了包含沙箱和源控制系统的典型补丁环境。在将修补程序部署到生产环境之前，请对暂存沙箱执行测试部署。

开发生命周期场景：AW计算

让我们来看看我们虚拟公司AW Computing的一个典型的开发和部署过程。对于此流程，AW Computing正在开发和部署自定义Salesforce应用程序。

AW Computing使用以下工具进行开发。

• 用于开发应用程序的Force.com IDE
  
• Git作为源控制系统和Git存储库，例如GitHub或Bitbucket。
  
• Ant迁移工具，用于从源代码管理中更新沙箱

AW Computing的开发团队的每位工程师都拥有自己的沙箱。

AW计算：源控制设置

发布经理Nishi必须首先建立Git存储库。存储库中的默认分支是主分支，它对应于生产中的元数据。对于功能开发，Nishi必须创建一个单独的分支并与开发团队共享。功能分支将生产中的自定义项与正在开发的新功能隔离开来。

在创建Git存储库之后，Nishi使用生产中的元数据填充主分支。以下是Nishi遵循的步骤：

1. 使用默认主分支创建一个中央Git存储库。 Git存储库是远程的，必须由每个用户克隆一次。
   
2. 准备package.xml清单，该清单使用通配符指定组织中的所有元数据类型。 Nishi可以从Force.com IDE或手动获取此文件（请参阅为所有元数据生成package.xml的提示）。
   
3. 使用Ant Migration Tool和package.xml清单从生产中检索所有元数据。
   
4. 将下载的元数据文件，package.xml清单和工具的控制文件提交给主分支，并将它们推送到远程存储库。请参阅配置Ant迁移工具。

现在已经设置了主分支并已填充，Nishi为基于master的新功能工作创建了一个分支，并将此分支推送到中央存储库。我们将此分支称为功能分支。此分支特定于团队正在开发的一组功能。

功能分支现在可供开发团队使用。团队中的每个开发人员都必须克隆Git存储库以在其系统上获取本地快照。接下来，每个开发人员必须切换到功能分支。由于Git存储库对于每个用户都是本地存储库，因此在本地存储库中提交的开发人员所做的任何工作最终都必须推送到远程存储库。

注意：此场景中描述的Git工作流是分支模型的一种方法。 Git为分支机构的工作提供了很大的灵活性。您可能希望选择最适合您组织的分支模型。有关更多信息，请访问Git网站。

AW Computing：First Developer为源代码控制添加了第一个功能

1. 安德鲁，一位高级开发人员，首先创建他的开发人员沙箱。 Andrew的沙箱包含生产应用程序和配置信息的副本。
2. Andrew使用Force.com IDE连接到他的沙箱组织。 Andrew选择将其沙盒组织中可用的所有元数据检索到IDE。 IDE会为此检索动态创建package.xml文件。
   
3. 安德鲁克隆功能分支以获取本地副本。
4. Andrew通过添加新组件，Apex代码和Visualforce页面来构建应用程序。所有这些组件都从IDE保存到沙箱组织中。
   
5. 安德鲁完成他的第一部特征后，他进行了单元测试。
   
6. 现在是时候将他的更改提交到Git中的功能分支了，但是首先安德鲁需要更新他的IDE，使用他的沙盒用户界面中手动完成的任何更改都不在他的IDE中。为此，Andrew在Force.com IDE中运行Refresh from Server命令。
7. Andrew将其文件提交到其本地存储库中的功能分支，然后使用git push命令将其提交到远程存储库。这些文件由IDE创建的文件夹及其内容组成，这些文件夹对应于沙箱的元数据。

AW计算：第二个开发人员与其他变化集成

Jane是团队中另一位想要为应用添加功能的开发人员。

1. Jane根据生产组织创建了她的沙箱。
   
2. Jane克隆功能分支以获取包含Andrew自定义的本地副本。
   
3. 为了将她在上一步中获得的元数据文件部署到她的沙箱中，Jane使用了Ant迁移工具。首先，Jane配置该工具。
   
4. Jane使用Git中的package.xml运行Ant迁移工具，以获取从Git到她自己的沙箱的最新更改。现在简的沙箱包含安德鲁的变化。
   
5. Jane在Force.com IDE中添加了自己的自定义。
   
6. 要获取Jane在其沙箱用户界面中手动进行的任何更改，她将在Force.com IDE中运行“从服务器刷新”命令。
   
7. Jane完成了她的工作并测试了她的变化。
   
8. Jane在当地承诺改变。
   
9. 在更新Git存储库之前，Jane执行git fetch和git merge命令，以包含Andrew或其他开发人员自创建本地项目以来可能已上载到存储库的任何更改。她解决了任何冲突。
   
10. Jane执行git push命令将她的更改推送到Git存储库。 Jane creates her sandbox based on the production organization.

AW计算：质量工程师测试应用程序

罗伯特是团队中的质量工程师，他想测试安德鲁和简的变化。他遵循与Jane一样的过程来创建他的沙箱并从Git获得更改。接下来，Robert添加了更多Apex测试方法，运行这些测试，并根据需要执行额外的临时测试。 Robert将他的测试添加到Git功能分支。

AW计算：工程师在同步应用程序开发期间同步更改

当团队中的其他工程师需要处理相同的应用程序或测试应用程序时，他们需要遵循与Jane一样的过程，将更改从Git部署到他们的沙箱，然后将新的更改提交回Git。

此图显示了团队成员拥有的沙箱以及如何将更改同步到源控制存储库。

AW计算：集成和共享测试

现在自定义已经完成并经过全面测试，团队希望执行更全面的测试，以确保组织中的数据来自外部系统将与这些自定义一起使用。为此，Robert创建了一个Partial Copy沙箱，并通过从Git存储库启动部署来为其部署最新的自定义项。 Robert使用沙盒模板作为Partial Copy沙箱。该模板允许选择要复制的数据，并允许控制沙箱的大小和内容。罗伯特遵循这个过程：

• 
  

1. 创建部分复制沙箱，然后使用沙箱模板填充它。
   
2. 使用Ant迁移工具和Git中的package.xml文件，从Git将最新的自定义项部署到此沙箱。
   
3. 在此沙箱上为将要执行集成测试的所有用户创建用户帐户。
   
4. 如果发现错误，我们建议使用Force.com IDE在Developer沙箱中完成修复，然后将其提交到Git中。

此外，Robert还创建了共享QA沙箱，用于测试团队以外的其他员工进行测试。共享QA沙箱是Developer沙箱，因此它不包含数据或支持数据模板。 Robert为将访问此沙箱的所有用户创建多个用户帐户。

AW计算：用户验收测试和培训

现在集成和共享测试已经完成，应用程序可以与其他员工共享。

1. 发布经理Nishi为用户验收测试设置了一个Partial Copy沙箱，并从Git部署了自定义。
   此过程类似于设置集成沙箱。自定义包含团队在进行其他测试后所做的最新错误修复。
2. 公司的其他团队想要验证新的更改或检查新功能。例如：
   • 产品经理可能希望执行一些临时测试，以确保实现功能并准备演示。
   • 在应用程序在生产中推出之前，培训师可以使用新应用程序准备正式的培训材料。

如果在用户验收测试沙箱中发现问题，则修补程序将在Developer沙箱中实现并提交到Git中。

此过程类似于设置集成沙箱。自定义包含团队在进行其他测试后所做的最新错误修复。

AW计算：分期环境和最终发布到生产

现在他的应用程序已经过测试和审核，该应用程序已准备好进行生产发布。在将已批准的应用程序发布到生产环境之前，应执行测试部署以及最终回归，性能和压力测试。为此，建立了用于分段的中间沙箱环境。此沙箱类似于生产组织 – 它具有生产包含的所有配置和数据。

1. 发布经理Nishi创建了一个用于登台的Full sandbox。
2. Nishi通过将应用程序部署到登台沙箱环境并运行所有Apex测试来模拟部署。
3. 质量保证团队执行压力和性能测试以及最终回归测试。
   注意：由于Lightning Platform中沙箱的硬件与生产组织硬件不同，因此沙箱上的性能测试结果可能与生产中的不匹配。尽管如此，对分段沙箱的性能测试仍然可以帮助捕获性能问题（即使与生产完全相同）和Apex调控器限制引起的错误。
   

注意：

• 对于Ant Migration Tool版本34.0及更高版本，通过将testLevel =“RunLocalTests”参数添加到部署目标，在暂存沙箱中运行本地测试。此参数确保在沙箱中运行的测试与生产中默认运行的测试（如果需要）相同。
• 对于Ant Migration Tool 33.0及更早版本，您可以通过将runAllTests参数设置为true，通过staging沙箱中的Ant Migration Tool运行所有测试，包括源自已安装的托管包的测试。使用runAllTests参数时，无法排除托管包测试。相反，在生产中自动运行的测试只是本地测试（没有命名空间），而这些测试不是来自已安装的软件包。请参阅配置Ant迁移工具以运行测试的提示。
  

在发布管理器完成部署并在登台沙箱上获得成功结果后，她会将发布计划到生产并在计划的时间执行到生产组织的最终部署。

AW计算：修复补丁环境中的错误

1. 1.将应用程序部署到生产环境后，Andrew会刷新Developer sandbox以从生产中获取最新的更改。
2. Andrew在他的开发人员沙盒中进行修复，并将他的更改上传到Git中的补丁分支。
   
3. 发布经理Nishi使用Ant迁移工具执行从Git到登台沙箱的验证部署。
4. Nishi执行从Git到生产的修补程序部署。

注意：必须定期将对修补程序分支所做的所有更改合并到主分支中，以便将更改合并到下一个功能发行版中。

持续集成过程

对于强大的质量保证流程，使用持续集成系统（如Jenkins）为源控制存储库中的每次添加自定义项运行测试部署。您可以在专用沙箱中执行这些部署以进行持续集成。

Apex测试作为每个部署的一部分执行。配置Ant迁移工具以启用测试。请参阅配置Ant迁移工具以运行测试的提示。

您可以使用持续集成系统来自动部署。例如，您可以使用Jenkins自动部署到用户验收测试（UAT）沙箱。

下图显示了持续集成服务器，沙箱和源代码控制之间的关系。

处理API中不支持的元数据

Metadata API不支持某些元数据组件，因此不会通过Ant Migration Tool等工具进行迁移。 例如，不支持邮件合并模板或会计年度。 有关不受支持的元数据的完整列表，请参阅“Metadata API开发人员指南”中的“不支持的元数据类型”。 每次使用源控件中的新元数据更新沙箱时，都必须创建此元数据。 您可以手动或以自动方式在Salesforce用户界面中创建此元数据。 如果手动创建元数据组件，我们建议您记录这些元数据更改并保留这些更改的清单以验证迁移。 要自动创建此元数据，您可以使用浏览器用户界面自动化工具，例如Selenium。 有关Selenium的更多信息，请参阅Selenium Browser Automation。

配置Ant迁移工具

以下是Ant迁移工具的常见配置任务的提示。

为Git配置Ant迁移工具的提示

要将Ant迁移工具与源控制系统（如Git）集成，必须以与在命令行上运行它并使用本地文件系统进行存储时不同的方式配置该工具。通过将Ant迁移工具与Git集成，您可以让工具存储其输出并从存储库中获取其输入。以下是为Git配置此工具的一些最佳实践。

• 在Git中，在包含package.xml的项目文件夹中创建source（src）文件夹。
  
• 将build.properties和build.xml从工具的示例目录复制到Git项目源（src）文件夹。
  
• 不要将包名称用于元数据检索或部署。而是使用未打包的检索和部署。

使用远程Git存储库的提示

对于远程Git存储库，您可以将Ant迁移工具与Git存储库集成以访问Git分支中的文件。将此代码段添加到build.xml。

<macrodef name=”git”>

<attribute name=”dir” default=”” />

<attribute name=”branch” default=”master” />

<sequential>

<exec executable=”git” dir=”@{dir}”>

<arg value=”pull” />

<arg value=”origin” />

<arg value=”@{branch}” />

</exec>

</sequential>

</macrodef>

<target name=”checkoutFromGit”>

<echo>Issuing git pull from directory: ${git.dir}</echo>

<echo>Pulling from branch: ${git.branch}</echo>

<git dir=”${git.dir}” branch=”${git.branch}” />

</target>

配置Ant迁移工具以运行测试的提示

部署到登台沙箱时，我们建议您运行Apex测试。默认情况下，不需要测试，也不在沙箱中运行。但是，您可以通过将buildLevel =“RunLocalTests”参数添加到build.xml文件中的部署目标（标记）来在Ant迁移工具中启用测试运行。此部署选项运行本地测试，并排除源自已安装的受管软件包的测试。此测试执行对应于生产中运行的测试（如果需要）。以下示例显示如何通过testLevel =“RunLocalTests”属性（以粗体显示）在部署目标中启用测试运行。

<sf:deploy username=”${sf.username}” password=”${sf.password}” testLevel=”RunLocalTests” … />

注意：如果您使用的是以前版本的Ant迁移工具（版本33.0或更早版本），则testLevel =“RunLocalTests”参数不可用。而是添加runAllTests =“true”参数。此参数导致运行已安装的受管软件包的测试 – 不仅是本地测试。如果这些托管包中的测试未通过，请将runAllTests设置为false，然后使用Apex Test Execution控制台在生产组织中部署后运行测试，您可以通过在快速查找框中输入Apex Test Execution来从安装程序访问该控制台，然后选择Apex Test Execution。

为所有元数据生成package.xml的提示

要使用Ant迁移工具迁移所有元数据组件，必须使用引用组织中所有元数据组件的package.xml清单文件。以下步骤说明如何手动创建此文件。

1. 使用Ant Migration Tool，运行以下命令：ant describeMetadata。
   此命令的输出将列出所有元数据组件以及子对象。您只需要包含父对象（XMLName字段），因为在使用Ant迁移工具检索或部署元数据时，子对象包含在其父对象中。
2. 通过使用InFolder：true属性（仪表板，文档，EmailTemplate和报告）排除类型来过滤返回的列表。
3. 从筛选列表中，将每个XMLName字段的值复制到嵌套在package.xml中的中的标记中，然后将标记与*值关联。例如，对于CustomLabels，标记对是：

<types>

<members>*</members>

<name>CustomLabels</name>

</types>

此示例显示了package.xml的一部分。 package.xml的内容取决于组织中可用的元数据。

<?xml version=”1.0″ encoding=”UTF-8″?>

<Package xmlns=”http://soap.sforce.com/2006/04/metadata”> <fullName>SampleManifest</fullName>

<types>

<members>*</members>

<name>AnalyticSnapshot</name>

</types>

<types>

<members>*</members>

<name>AuthProvider</name>

</types>

<types>

<members>*</members>

<name>CustomLabels</name>

</types>

<types>

<members>*</members>

<name>CustomObject</name>

</types>

. . .

<version>31.0</version>

</Package>

生产发布注意事项

将自定义项部署到生产组织时：

• 确保计划的Salesforce版本不会影响您的版本。围绕Salesforce升级安排发布。
• 确保测试作为发布的一部分运行。
• 规划Salesforce Sandbox预览。我们建议您指定一些沙箱以参与我们的发布预览。在每个主要版本发布前一个月，Salesforce会升级一组沙盒实例。驻留在这些实例上的所有沙盒组织都可以访问即将发布的Salesforce版本。使用这些沙箱进行回归测试或尝试新功能。

刷新沙箱环境

我们建议您定期刷新沙箱，以确保它们具有当前配置信息和数据。登台和用户验收测试（UAT）沙箱可以随时从中央源控制存储库刷新。由于存储了所有最新更改并且可以从源控制存储库中检索，因此无需等到生产部署完成并成功完成。可以使用持续集成过程自动化源控件中的沙箱刷新。请参阅持续集成流程。

沙箱刷新建议

要刷新沙箱，请遵循以下建议。

• 在每个功能部署期间或每个月（以较长者为准）后刷新登台沙箱环境。
• 定期刷新UAT沙箱环境，以确保部分数据副本具有当前数据。
• 根据需要刷新开发人员沙箱。 例如，开发人员可以刷新他们的沙箱，以获得组织的配置和元数据的干净副本，他们可以将其用作基线并添加自定义。

学习目标

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

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

迁移更改的最简单方法是在单个操作中部署所有更改。但是，您可能希望将部署分成较小的部分，原因如下。

• 部署过大 – 您可以一次部署或检索多达10,000个文件，部署或检索的.zip文件的最大大小为39 MB。 （在API版本43.0及更高版本中，AppExchange软件包最多可包含12,500个文件。）
• 长时间部署 – 如果您遇到异常长的部署，则可以将部署划分为更小的部分。较小的部署可以减少由于在长时间运行的操作中持有锁而导致的用户影响。
• Apex测试 – 您可能希望将组件分为两部分：默认情况下需要测试的部分和不需要测试的部分。仅测试那些需要测试的组件加速部署并锁定更少的组件。

确定要一起部署的文件

如果您需要将部署划分为更小的部分，那么了解要同时部署哪些组件非常重要。

• 部署不触发测试的组件 – 在API 34.0及更高版本中，默认情况下需要测试的唯一组件是Apex类和触发器。所有其他组件不需要测试。
  
• 不要拆分依赖组件 – 因为文件依赖关系在迁移元数据中起着如此重要的作用，所以重要的是不要分离依赖组件。
  
• 单独部署最多的组件 – 以下组件可以是最多的组件，因此您可能希望将它们与其他组件分开部署。
  1. 电子邮件模板可以单独部署，但必须在使用模板的组件之前部署。
     
  2. 仪表板可以单独部署，但在报告之前部署它们，以防自定义按钮链接到报告。
     
  3. 报告可以包含最多的组件。它们可以在所有其他组件之后以多个批次部署。

使用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用户界面开发的功能。此外，建议在暂存环境中手动运行所有测试，以避免在生产部署之前出现可能的问题。开发环境不会强制执行A​​pex测试覆盖，但生产组织会执行。

注意：Lightning平台要求至少75％的代码由单元测试覆盖，然后才能将其部署到生产组织。理想情况下，争取100％的覆盖率。对沙箱或Developer Edition组织不强制执行代码覆盖限制。

成功部署到临时环境后，需要在部署到生产之前进行其他更改。如果您在开发环境中修改了环境依赖关系（例如，为开发人员提供他们在生产时没有的权限），请将这些值更改回生产值。如果您配置服务端点以测试与外部服务的集成，则还必须将这些端点更改为其生产值。

您现在可以部署到生产环境了。首先，将用户锁定在系统之外，然后在生产组织上执行Metadata API测试部署。此步骤是验证“仅检查”部署 – 完全模拟部署，并返回部署的成功或失败，但不部署任何组件。如果在部署阶段和发生部署之间存在时间间隔，则此步骤尤为重要。如果测试部署成功，您可以使用Metadata API或Web界面部署更改，具体取决于组件。

注意：如果将字段类型从Master-Detail更改为Lookup，反之亦然，则在使用checkOnly参数测试部署时不支持更改。测试部署不支持此更改，以避免永久更改数据。如果部署包中包含测试部署不支持的更改，则测试部署将失败并发出错误。

如果部署包将字段类型从Master-Detail更改为Lookup，反之亦然，则仍可在部署到生产之前验证更改。对另一个测试沙箱执行完全部署。完整部署包括在部署过程中验证更改。

在以下情况下，包含主 – 详细信息关系的元数据API部署将删除回收站中的所有详细信息记录。

1. 对于具有新Master-Detail字段的部署，在继续部署Master-Detail字段之前，软删除（发送到回收站）所有详细记录，否则部署将失败。在部署期间，详细记录将从回收站中永久删除，无法恢复。
2. 对于将Lookup字段关系转换为Master-Detail关系的部署，详细记录必须引用主记录或软删除（发送到回收站）以使部署成功。但是，成功部署会永久删除回收站中的所有详细记录。

请记住，所有IT组织都不同。以下过程概述了将企业应用程序部署到生产组织时可能遵循的高级步骤。

1. 宣布维护窗口。
   
2. 停止生产中的所有设置更改。
   
3. 创建临时环境。
   
4. 将更改迁移到登台环境。
   
5. 将环境依赖关系和服务从测试设置更改为生产值。
   
6. 将用户锁定在应用程序之外。
   
7. 使用Metadata API测试部署。
8. 部署到生产。
9. 解锁生产组织。

安排发布

每次将更改部署到生产环境时，您的用户都会受到直接影响，因此最好有指导来推出新功能。 Salesforce在这方面拥有十多年的经验，您可能希望将我们的推出程序建立在我们的模型上：

1. 不要破坏任何东西：
   
   • 首先在测试环境中发布您的生产功能。如果您在完整副本沙箱中成功部署和测试，则可以确信您的最终生产部署将成功。
   • 备份一切。
   • 有一个后备计划，以防万一。
2. 安排发布：
   • 创建并公布维护窗口，在此期间您的组织将无法供大多数用户使用。
   • 使用配置文件来控制维护更新。
3. 告知用户每个变化：
   • 创建详细的发行说明，记录新功能和现有行为的更改。
   • 发送电子邮件，宣布主要功能，并附带发行说明的链接。
   • 创建网络研讨会和培训课程以教育用户。

使用配置文件控制维护更新

在部署窗口期间，您可以使用用户配置文件来限制最终用户对生产组织的访问：

1. 创建并公布维护窗口，在此期间您的组织对大多数用户不可用：
   • 从“设置”中，在“快速查找”框中输入“Mass Email Users”，然后选择“Mass Email Users”以访问电子邮件向导，该向导允许您向维护窗口的所有激活的用户。
2. 使用配置文件创建和管理维护窗口：
   • 在用户配置文件中编辑登录时间以在维护窗口期间锁定大多数用户。确保任何系统管理员或集成用户在需要时都可以访问。
   • 如果要允许某些用户访问用户验收测试，请有选择地将对象，选项卡和应用程序推出到不同的用户配置文件。

如果您的组织包含许多配置文件，请使用以下策略设置维护时段：

1. 创建一个名为Maintenance的新配置文件，锁定所有登录时间。
2. 使用数据加载器提取并保存用户及其用户配置文件的映射。
3. 在维护窗口的开头，使用数据加载器将除管理员之外的所有用户配置文件更改为维护配置文件。请注意，与管理员保持登录访问权限非常重要，否则所有用户都可能无限期地被锁定在系统之外。如果要在维护窗口期间运行任何集成，则也不应锁定集成用户。
4. 在维护窗口结束时，使用Data Loader以其原始配置文件重新加载用户。

修复错误

修复错误的位置取决于错误的严重程度以及IT部门的具体情况。一般来说，有两种选择：在生产组织或开发环境中进行修复。最佳做法是在一个地方进行所有更改，然后按照可重复的过程将更改移至生产环境。此过程的一个版本如下图所示：

当您具有需要立即投入生产的高优先级错误修复时，此过程并不总是切实可行。在这种情况下，您必须修复生产环境中的错误，然后将相同的错误修复迁移到您的开发环境。这很重要，因为从开发环境迁移更改时，可能会覆盖对生产组织所做的更改。此过程的一个版本如下图所示：

学习目标

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

1. 开发企业应用
   
2. 安排并行开发项目
   
3. 在发布列车上提供应用程序
   
4. Salesforce升级如何影响交付计划

Lightning平台最具生产力的功能之一是可以直接在Web用户界面中进行自定义，并立即供最终用户使用。 这些类型的更改不需要精心设计的开发工具或流程。 从发布管理的角度来看，只需要很少的努力。

更复杂的升级（例如为现有应用程序创建新的用户界面）需要一个可以将开发工作与生产用户隔离开的环境。 将您在开发环境中所做的更改重新集成到生产组织中会为开发过程带来新的复杂性，因为您的生产组织可能在同一时间内发生了变化。 此级别的发布管理需要跟踪各种环境之间的更改，以确保在部署时不会发生冲突。

影响所有用户的复杂应用程序可能需要多个开发和测试环境。 通过在不同的开发周期中同时进行项目，这种长期项目可能会进一步复杂化，并且在将应用程序部署到生产环境之前可能需要多次集成。 在许多情况下，所有这些开发工作同时发生。 此级别的发布管理是一个非常复杂的难题。

您如何管理这些开发项目，以免彼此冲突或IT部门的流程发生冲突？ 你如何兼顾不同的时间框架和生产生命周期？ 您如何合并环境之间的更改，以便在生产组织中推出功能时没有冲突？ 这些问题的答案与构建应用程序生命周期管理过程的方式有关，只有通过了解所有变量才能做出这些决策。

开发企业应用

大型组织往往具有跨多个发布计划的复杂开发流程。 在这种情况下，不仅开发和测试之间的划分很重要，而且不同时间表上的项目同步。 在此开发方案中，您有多个开发环境，必须在合并到临时区域之前相互集成。 可以添加其他环境用于培训，生产支持或其他目的。 组织可以通过多种方式管理此类企业开发。 一种可能的方法如下图所示：

根据不同的发布计划管理各种复杂性和持续时间的多个项目需要一个发布计划和严格的变更跟踪流程。 包含分布式开发人员和测试人员的开发团队还需要同步和集成他们的更改，以便有效地进行协作。

安排并行开发项目

与传统软件开发不同，所有升级都在单个版本中进行，在线应用程序可以随时升级。 可以非常快速地向最终用户发布更易于开发，需要较少测试或具有更高优先级的增强功能。 因此，发布管理中的一个重要步骤是安排您的开发工作。 对于IT组织而言，这意味着将开发项目分为短期，中期和长期等类别。 这些类别通常由开发地点，需要进行多少测试以及何时必须提供新功能来定义。

虽然您可以根据需要使用尽可能多的类别，但三层方案是一个很好的起点。 除了项目的持续时间之外，还有一些其他可能的方法可以对您的开发工作进行分类。

发展的地方：

• 仅限生产 – 如果可以在生产Web界面中完全开发和测试功能，则开发周期更快，用户可以更快地获得功能。
• 元数据API组件 – 如果Metadata API中提供了所有必需的组件，则可以更轻松地跟踪和合并环境之间的更改。
• 单个沙箱 – 如果可以在沙箱中开发功能，然后立即部署到生产组织，则开发周期不需要集成或暂存环境。
• 多个环境 – 开发项目可以跨越多个沙箱，在这种情况下，集成代码行的复杂性会增加。 复杂的项目不应该保持简单的推出。

按开发人员数量：

• 单一 – 如果单个开发人员可以创建，测试和部署功能，则不太可能遇到合并更改或其他耗时问题的问题。
• 小团队 – 一个小型开发团队可以将大型项目划分为可管理的部分，并且仍然能够快速开发。 这种性质的项目可以轻松地与单个开发人员项目集成，并快速推出。
• 大型团队 – 大型开发项目需要一个完整的开发团队。 这种性质的项目需要跟踪和合并来自不同代码分支，验收测试以及可能减慢开发过程的其他相关过程的更改。

在发布列车上提供应用程序

发布系列是一种定期提供应用程序升级的调度技术。 发布列车是可预测和增量的，因此它们通过限制在任何一个开发周期中可以完成的工作来简化开发过程。 由于Salesforce升级会影响您的应用程序更新，因此您可能会发现在Salesforce升级发生之前安排发布是有用的。

在发布列车上交付多个应用程序的一般过程如下：

1. 围绕Salesforce升级计划发布。
2. 安排您的并发开发项目。 这将帮助您确定现在可以在当前版本中还是在将来的某个时间完成新功能。
3. 建立生产组织变更流程。
4. 跟踪所有环境中的变化。 这将确保从开发环境部署时不会覆盖提供给生产的短期功能。
5. 集成更改并部署到登台或测试环境。
6. 发布到生产。

Salesforce升级如何影响交付计划

当Salesforce升级到下一个版本时会发生一些事情。 对于初学者，沙盒和生产实例在不同时间升级。 这意味着，您的沙箱和生产组织会在短时间内运行不同版本的Salesforce。 沙箱可以比生产组织更早或更晚升级，具体取决于实例。 时间表由沙箱复制日期决定。

升级安排在非高峰时段，很少影响用户。 但是，IT部门通常会在这几个小时内安排自己的批处理流程，因此避免任何冲突非常重要。 升级期间发生的事情是：

• 新徽标 – Salesforce徽标是验证您使用的版本的快速方法。 沙箱可能会在生产组织之前或之后升级; 因此，最好在Salesforce发布时检查沙箱主页左上角的徽标，以查看沙箱是否已升级。
• 新功能 – 每个版本都包含新功能。 其中包括通过Metadata API提供的新组件。 单击“帮助和培训”窗口中的“新增内容”链接以查看发行说明。
• 增加的API版本 – API版本在每个版本中递增，对新功能的访问需要连接到新版本的API。
• 交错升级 – 由于您的生产和沙箱组织可能在升级窗口期间未运行相同版本的平台，因此您可能必须等待部署新的组件或具有其他元数据。 如果您尝试将具有较新组件的更改集上载到尚未升级以支持它们的组织，则部署将失败。

您可以访问trust.salesforce.com/trust/status并单击View Upcoming Maintenance Schedule链接查看即将到来的维护计划。

学习目标

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

1. 建立生产环境变更流程
2. 手动跟踪更改
3. 使用Ant迁移工具跟踪更改
4. 使用Force.com IDE跟踪更改
5. 同步更改
6. 同步多个沙箱
7. 整合开发环境的变化

发布管理的一个挑战是跟踪更改。这在概念上听起来很简单，但在实践中，它可能不是。生产和开发组织以及Metadata API中可用和不可用的组件中的更改可以同时发生。

跟踪更改的最简单方法是使用传统开发工具对代码进行区分，合并和版本化。但是，这些工具仅适用于Metadata API中可用的组件，因此需要手动跟踪更改。这可能看起来很多工作，但能够跟踪和复制所有环境中的更改是确保在不覆盖生产组织更改的情况下成功部署功能的唯一方法。在Lightning平台上，跟踪更改的最重要原因是您可能必须手动将某些更改从一个组织迁移到另一个组织。

建立生产环境变更流程

使用Salesforce Web用户界面快速开发和定制生产组织中的应用程序的能力是Lightning Platform的众多优势之一。 但是，在开发企业应用程序时，这种易于开发可能会导致生产组织发生变化，同时在沙箱中开发应用程序。 为了确保成功部署到生产组织，您的开发环境必须具有与生产相同的更改。 将修改从生产组织转移到开发环境似乎是一件倒退的事情，但这是必要的，因为从开发迁移到生产可以覆盖已经在生产中进行的更改。

在生产组织上进行修改时，您可以执行沙箱刷新并获取最新更改。 但是，沙盒刷新并不总是可行（对于完整的沙箱，您只能每29天刷新一次），并且可能需要您执行配置更改，例如修改用户配置文件或权限集，以便您的开发人员具有必要的权限。

因此，跟踪生产和开发环境之间的变化，然后将这些差异从生产合并到开发，可能是一个必要的过程。 为了使这些任务更容易，为您的生产组织建立变更流程是个好主意。 更改过程确定可以对生产组织进行哪些类型的修改，何时可以发生以及谁负责进行更改。 您采用的更改过程取决于生产环境中所需的修改类型。 以下列表提出了一些变更流程的最佳实践，从最简单到最复杂。

• 不允许更改生产 – 这是您可以执行的最简单，但也是最严厉的措施。 实际上，您正在牺牲即时设置更改以便于部署。 如果选择此过程，则所有开发都在沙箱上进行。
• 仅修改元数据API中的组件 – 手动跟踪和部署更改比使用元数据API复杂得多。 如果您可以将生产更改限制为可通过Metadata API访问的组件，那么这将简化更改跟踪，合并和部署。
• 只允许一个管理员进行设置更改 – 有些组织发现分配一个负责生产所有设置更改的管理员很有用。 这样可以更轻松地跟踪生产组织的更改，并将这些更改复制回沙箱刷新之间的开发环境中。 这是一种更灵活的方法，允许同时更改生产和基于项目的开发。 但是，如果您的组织足够小，以至于一个管理员可以进行所有设置更改，那么这只是一个可行的解决方案。
• 安排生产更改 – 如果您的组织需要频繁更改生产环境，则可以安排时间将这些更改迁移到开发环境。 根据您拥有的组织数量，这可能是经常轻松迁移（可能是每周一次），也可能是较不复杂的流程（每季度一次）。

手动跟踪更改

您可以使用桌面工具跟踪和合并您对Metadata API中可用组件所做的任何更改。 如果使用Force.com IDE或Ant迁移工具，则可以将文件放在版本控制系统中，并且可以使用版本控制系统的内置功能跟踪更改。 但是，大多数IT组织会对未在Metadata API中表示的组件进行大量更改，因此需要手动跟踪生产和开发组织的更改。

拥有一种跟踪所有更改的方法非常重要，尤其重要的是，如果这些更改需要手动迁移。 一个有用的工具是一个更改请求表单，用户和管理员填写所请求的每个增强或执行的更改。 您可以在Salesforce中创建自定义应用程序，以记录更改请求和所做的实际更改。

提示：AppExchange包含可以安装以管理此过程的自定义应用程序，例如免费的 Change Control应用程序。

大多数IT组织还使用电子表格来记录和跟踪这些更改。 电子表格允许您在迁移或跟踪这些更改时按标题排序，创建数据透视表以及执行其他有用的操作。 在电子表格列表中发生的每个更改，包括：

• 谁做出了改变
• 发生变更的组织
• 日期和时间
• 哪个组件已更改

您何时需要手动跟踪更改？

• 对不在Metadata API中的组件所做的更改 – 您必须手动跟踪对Metadata API中不可用的组件的每个更改。
• 使用Salesforce Web用户界面所做的更改 – 即使组件通过Metadata API可用，您也应该跟踪使用Web工具所做的更改。 Web工具和Metadata API之间的并发更改通常会创建依赖关系，并且是部署问题的常见来源。 为了安全起见，最好手动跟踪通过Web界面进行的所有更改。

Salesforce Web用户界面中所做的更改将记录在安装审核跟踪中。 将审计跟踪与手动更改跟踪工具结合使用是确保您不会错过任何更改的最佳方法。 您如何管理此流程取决于您，但最好定期将审计跟踪中的所有更改传输到您的更改列表（例如，每周一次），或仅使用审计跟踪来交叉检查更改 你的变更清单。 有关使用设置审计跟踪的详细信息，请参阅Salesforce联机帮助中的“监视设置更改”。

使用Ant迁移工具跟踪更改

Ant迁移工具对于基于脚本的部署尤其有用，例如迁移批量组件。 另一个特别有用的批处理脚本可以编写为diff元数据更改。 这样的脚本允许您在预定的时间或不同的组件集执行差异。

1. 创建一个列出要比较的组件的xml文件。
2. 创建检索目标以下载组件。 例如：
   <target name=”retrieve-production”>
   <sf:retrieve
   username=”${sf.username}”
   password=”${sf.password}”
   serverurl=”${sf.serverurl}”
   retrieveTarget=”production”
   unpackaged=”package.xml” />
3. 编写外部脚本来区分文件。
4. 指定调用脚本的目标并将结果输出到文件。 例如：
   <target name=”show-production-differences”>
   <!– get metadata from organization –>
   <antcall target=”retrieve-production”/>
   <!– perl script to find changes –>
   <exec executable=”/bin/bash”>
   <arg value-“-c” />
   <arg value-“cd production;
   svn stat|../showdiffs.perl>../report.txt”/>
   </exec>
   </target>

注意：此过程仅是执行编程差异所需的基本步骤的示例。 您可能希望定义多个文件夹和package.xml文件，以便可以批量检索组件。

使用Force.com IDE跟踪更改

使用Eclipse中的内置功能或任何其他更改跟踪实用程序，可以轻松跟踪和合并Force.com IDE中所做的任何更改。 有关更多信息，请单击Force.com IDE中的“帮助”。

同步更改

Metadata API将Lightning Platform组件描述为可在不同环境之间传输的基于文本的文件。 使用第三方工具，可以在开发人员和开发环境之间存储，版本化和划分这些文件。 随着您引入诸如多个开发环境，代码分支，版本等概念，应用程序开发生命周期的复杂性也会增加。

同步所有这些变化可能是一个挑战。 例如，您可能有一个开发沙箱专用于生产组织中现有应用程序的增强，另一个开发沙箱用于新应用程序。 每个组织都可以有多个项目，所有项目都在同一时间进行更改。 合并这些更改需要两个单独的流程：在同一组织中的项目之间同步更改，然后在组织之间集成更改。

同步多个沙箱

传统软件开发和云计算之间的根本区别在于，在云计算中，服务器始终具有组件的真实定义。 您在本地Lightning Platform项目中使用的文件是服务器上对象的表示。 这是一个重要的区别，因为直接在项目之间，但在每个项目和服务器之间不会发生同步：

如果使用Force.com IDE，则将更改与主组织同步就像单击“保存”按钮一样简单。 对于在两个组织中同时发生的更改，同步工具允许您以任一方向覆盖文件，或合并更改。 Force.com IDE帮助中介绍了如何保存，同步和刷新文件。

整合开发环境的变化

如果您有多个开发环境，则必须将所有更改合并到可以部署的组织中。 如果您只有两个沙箱，则可以非常轻松地在它们之间来回迁移更改。 每个沙箱都可用于将更改部署到其他组织或生产。

在添加开发环境时，同步它们的复杂性呈指数级增长。 在这种情况下，将更改合并到单独的集成沙箱组织中要比彼此更容易。 在这种情况下，从开发沙箱迁移到集成只是一种方式：

如果使用更改集来迁移组件，则可以编辑部署连接，以使更改遵循定义的集成路径。

学习目标

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

1. Lightning Platform App Builder工具
2. Force.com IDE
3. 关于Metadata API
4. Ant迁移工具
5. Data Loader

无论您在开发过程中的角色如何，重要的是要从高层次了解所有Lightning Platform开发工具的运行方式以及彼此重叠的开发任务。 发布管理的一个挑战是跟踪每个组织的变化，并且对工具的了解使跟踪更改变得更容易。

您可能熟悉如何使用Salesforce Web用户界面构建应用程序。 基于项目的开发也需要使用桌面工具。 Force.com IDE是团队开发，选定组件迁移和编写Apex的最佳工具。 另一方面，Ant迁移工具对于在环境之间迁移大规模或重复的更改非常有用。 以下各节将介绍这些和其他Lightning Platform工具。

Lightning Platform App Builder工具

虽然您可以使用许多工具来创建和修改应用程序组件，但Web界面是最容易启动的地方。

Salesforce用户界面通过点击式应用程序构建工具轻松实现应用程序开发。 在“设置”中，您可以修改组织的元数据。

由于Web界面易于使用，因此管理员通常直接在生产组织中进行更改，而不是使用开发环境。 这对于立即需要该功能的用户来说非常有用，但需要跟踪生产中的更改，以便您可以在必要时将相同的功能迁移到测试或登台沙箱。

Force.com IDE

Force.com IDE是一个集成开发环境，用于使用Apex，Visualforce和元数据组件在Lightning平台上开发应用程序。 IDE专为开发人员和开发团队而设计，提供了加速Salesforce应用程序开发的工具。 这些工具包括向导，源代码编辑器，测试执行工具，部署辅助工具，集成帮助和交互式调试器。

Force.com IDE构建于开源Eclipse平台之上，可作为插件使用。 该插件是开源的 – 您可以在GitHub上找到并贡献其源代码。

Lightning Platform基于项目的开发利用传统软件开发的工具和流程，例如开发环境（沙箱），集成开发环境（IDE）和源代码控制系统。 Lightning Platform通过使用基于文本的文件来表示Salesforce组织中的各种组件，从而实现基于项目的开发。这些文件易于传输，可以在源控制系统中存储和版本化，并支持传统开发。所有这一切都可以通过Metadata API实现。

Lightning Platform项目是收集在一起的元数据文件的集合，以便您可以在本地处理这些文件。根据您的需要，您可以创建一个Lightning Platform项目，该项目包含组织中的单个组件或每个组件。后一种情况，从组织中检索每个可移植组件并不总是最佳选择，因为它可以使部署更长，更困难。

注意：您可以一次部署或检索多达10,000个文件，并且已部署或检索的.zip文件的最大大小为39 MB。 （在API版本43.0及更高版本中，AppExchange程序包最多可包含12,500个文件。）如果需要检索或部署超过这些限制之一，则必须批量执行此操作。

构建项目的一个好方法是考虑要完成的任务，然后仅为这些组件创建项目。

如果您要添加或删除组件，可以稍后编辑项目。

关于Metadata API

Metadata API提供了两个协同工作的部分：丰富而强大的元数据模型和应用程序编程接口（API）。 元数据模型描述了组织中的组件。 例如，可以通过操纵Metadata API提供的XML文件来控制Salesforce自定义对象及其字段。 Metadata API还包括一组Web服务方法，这些方法提供对元数据组件的配置和源的编程访问。 换句话说，它描述了您可以对这些组件执行的操作，例如创建对象或部署对象。 如果它可以帮助您将它们分成两部分，您可以将元数据组件视为名词，并将API调用为动词。

使用Metadata API，您可以：

• 将设置配置用作元数据文件。
• 使用熟悉的工具（如文本编辑器，IDE，批处理脚本和源代码控制系统）复制，粘贴，合并和操作元数据文件。
• 在两个开发环境之间或从开发到生产之间迁移组织之间的配置更改。
• 创建自己的工具来管理组织和应用程序元数据。

有关更多信息，包括支持和不支持的组件列表，请参阅Metadata API Developer’s Guide。

Ant迁移工具（Ant Migration Tool）

Ant Migration Tool是一个基于Java / Ant的命令行实用程序，用于在本地目录和Salesforce组织之间移动元数据。 Ant迁移工具允许您在不相关的组织之间迁移元数据，因此从这个意义上说它比更改集更强大。 与Force.com IDE不同，Ant迁移工具没有图形用户界面。 通过在文本编辑器中编辑控制文件并使用命令行参数，可以选择要部署的组件，服务器地址和其他部署详细信息。

大多数人会发现Force.com IDE的图形用户界面比编辑文本文件和在命令行上提供参数更容易使用。 但是，Ant迁移工具在以下方案中特别有用：

• 需要使用大量设置更改来填充测试环境的开发项目 – 使用自动脚本进行更改比手动输入更快。
• 需要在组织之间更改文件内容的部署 – 例如，如果要在仪表板上更改正在运行的用户，则可以从组织A检索正在运行的用户，进行更改，然后将正在运行的用户部署到 组织B.如果您尝试在Force.com IDE中执行此操作，IDE将强制您在启动部署向导以部署到组织B之前将更改保存回组织A（组织B用户可能不存在） Ant迁移工具使您可以完全控制retrieve（）和deploy（）命令; 在您选择部署文件之前，在本地文件系统上编辑和保存文件不会更改任何组织中的元数据。
• 多阶段发布流程 – 典型的开发流程需要在发布到生产环境之前进行迭代构建，测试和分段。脚本检索和组件部署可以使此过程更加高效。
• 使用相同参数的重复部署 – 您可以从组织中检索元数据，进行更改并将更改部署到组织。如果需要重复此过程，则只需再次调用相同的部署目标即可。
• 当从高级技术资源完成从分段到生产的迁移时 – 任何喜欢在脚本环境中进行部署的人都会发现Ant迁移工具是一个熟悉的过程。

有关更多信息，请参阅“Ant迁移工具指南Ant Migration Tool Guide.”。

Data Loader

Data Loader是用于批量导入或导出数据的客户端应用程序。 使用它来插入，更新，删除或导出Salesforce记录。

导入数据时，Data Loader从逗号分隔值（CSV）文件或数据库连接中读取，提取和加载数据。

导出数据时，它会输出CSV文件。

Data Loader可用于将数据加载到测试环境中，例如不包含任何数据的Developer Pro沙箱。 对于回归测试，建议使用一组稳定的数据，这些数据在发行版之间不会发生变化，因此在本地存储一组数据并使用Data Loader填充测试环境非常有用。 Data Loader具有命令行界面，因此脚本可以自动将数据加载到新组织中。

注意：Data Loader严格来说是一个加载数据的工具，而不是元数据。 您无法在对象上添加或删除字段或加载任何类型的设置更改。

要导入数据，可以使用导入向导或数据加载器。 Data Loader补充了可从在线应用程序的“设置”菜单访问的基于Web的导入向导。 请参阅以下指南以确定哪种导入方法最适合您的业务需求：

在以下情况下使用基于Web的导入：

• 您正在加载少于50,000条记录。
• 导入向导支持您需要导入的对象。要查看可用的导入向导以及它们支持的对象，请从“设置”中，在“快速查找”框中输入“Data Management”，然后选择“Data Management”。
• 您希望根据帐户名称和站点，联系电子邮件地址或潜在客户电子邮件地址上载记录来防止重复。

在以下情况下使用Data Loader：

• 您需要加载50,000到5,000,000条记录。数据加载器支持最多500万条记录。如果您需要加载超过500万条记录，我们建议您与Salesforce合作伙伴合作，或访问AppExchange以获取合适的合作伙伴产品。
• 您需要加载到导入向导尚不支持的对象。
• 您希望安排常规数据加载，例如夜间导入。
• 您希望导出数据以进行备份。

有关导入数据的更多信息，请参阅Salesforce联机帮助和“Data Loader Guide.”中的“将数据导入Salesforce”。

学习目标

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

1. 隔离开发和测试
2. 使用集成，测试和分段开发多个项目
3. 开发环境
4. 沙箱用途
5. 沙盒注意事项和限制
6. 创建开发沙箱
7. 更新环境依赖性
8. 创建用户模板
9. 管理沙箱

在Lightning平台上进行开发需要一个开发环境，一个可以在不影响其他用户的情况下工作的地方。在传统的软件开发中，开发环境只不过是一个自己调用的空间，但在Lightning平台上，每个开发环境都是自己的全功能Salesforce组织。

在快速入门：使用沙盒和变更集中，我们使用单个开发环境（开发人员沙箱）来进行与生产组织隔离的更改。在更复杂的场景中，您可能有多种环境用于各种目的，例如开发，集成，测试和培训。还有不同类型的开发环境最适合不同的用途。

使用单个开发环境进行开发和测试时，必须停止开发以进行测试，并且只能在部署后恢复开发。除非您有一个开发人员执行所有这些任务，否则这可能是资源的低效使用。更复杂的开发模型允许在进行测试和部署时继续开发。在这种情况下，您需要两个隔离的环境，一个用于开发，另一个用于测试。

隔离开发和测试

具有单独的开发和测试环境会增加开发过程的复杂性，并引入一个问题：现有组件的更改在哪里发生？例如，假设您有一个开发的应用程序，然后将这些更改迁移到您的测试环境。在测试期间，您发现需要进行一些更改才能部署到生产环境。您是在测试环境中进行这些更改还是返回开发组织并再次启动该过程？如果您只有两个沙箱，则可能需要在测试组织中进行这些更改，因为这是一个更快速，更简单的过程，并且您的开发沙箱可能已经更改为无法轻松重新开始的地方。但是，您仍然希望将测试环境中所做的任何更改复制回开发环境，以确保下次从开发升级到测试时保留修复。应用程序开发过程的安排和流程如下图所示：

典型的开发生命周期：

1. 创建开发环境。
2. 使用Salesforce Web和本地工具进行开发。
3. 创建测试环境。
4. 将更改从开发环境迁移到测试环境。
5. 测试。
6. 在其他环境中复制生产更改。
7. 将您开发的内容部署到生产组织。

典型的开发项目：

• 新的自定义对象，选项卡和应用程序
• 与其他系统的集成
• 涉及工作流程或新验证规则的应用

使用集成，测试和分段开发多个项目

如果您有多个开发人员和多个正在开发的项目将同时发布，则需要进行集成测试以确保可以合并单独的代码行而不会发生冲突。将来，您可能希望包括用户验收测试（UAT）以确定是否满足原始设计要求。更复杂的开发过程还可以包含一个临时环境，您可以确保生产部署完全按计划进行。

在这种开发方案中，您可能想知道在哪里更改代码行。如果某个功能在生产部署的方式上未通过任何测试，您是否在组织失败的情况下修复该功能，或者重新启动整个过程？随着应用程序开发过程的复杂性增加，您会发现随时修复并不是一个好模型。相反，您将希望在开发组织中进行所有修复，并遵循可重复的过程将该更改迁移到生产中。下图描绘了此过程：

典型的开发生命周期：

1.创建开发环境。
2.使用Salesforce Web和本地工具进行开发。
3.创建测试环境，包括UAT和集成。
4.将更改从开发环境迁移到集成环境。
5.测试。
6.将更改从集成环境迁移到UAT环境。
7.执行用户验收测试。
8.将更改从UAT环境迁移到登台环境。
9.在分段环境中复制生产更改。
10.安排发布。

典型的开发项目：

• 在多个环境中同时开发新应用程序
• 需要团队开发的项目

开发环境

有两种类型的开发环境：sandbox orgs和Developer Edition orgs。

沙箱是从您的生产组织中复制的新组织。 本节列出了支持沙箱的Salesforce版本。 有不同类型的沙箱适合不同的用途。

 

沙箱类型	描述
Developer	Developer 沙箱复制自定义（元数据），但不将生产数据复制到单独的环境中进行编码和测试。
Developer Pro	Developer Pro沙箱复制自定义（元数据），但不将生产数据复制到单独的环境中进行编码和测试。 Developer Pro比开发人员沙箱拥有更多存储空间。 它包含许多开发人员沙箱，具体取决于您的生产组织的版本。
Partial Copy	部分副本沙箱是开发人员沙箱以及您在沙箱模板中定义的数据。
Full	完整沙箱会复制整个生产组织及其所有数据，包括标准和自定义对象记录，文档和附件。 使用沙箱编码和测试更改，并培训团队有关更改的信息。 您可以每29天刷新一次完整沙箱。

沙箱还可以包含部分，无或所有生产数据，具体取决于预期用途。对于开发，您可能只需要一小组数据来确保工作正常。对于QA测试，尤其是回归测试，您需要一组不会随时间变化的大量数据。对于预部署分段，您需要一个尽可能靠近生产环境的沙箱，包括数据。只有完整的沙箱在创建数据时才会复制数据，但您可以使用导入向导或数据加载器将数据添加到沙箱中。

另一种类型的开发环境是Developer Edition组织。 Developer Edition提供对Professional，Enterprise，Unlimited和Performance版本提供的许多独有功能的免费访问。您可以完全访问Lightning平台和API，以便您可以扩展Salesforce，与其他应用程序集成，以及开发新的工具和应用程序。 Developer Edition组织主要由独立软件供应商（ISV）使用，用于在AppExchange上创建分发应用程序。有关更多信息，请参阅ISVforce指南。

沙箱用途

如果您的组织有多个沙箱可用，请在规划哪些沙箱用于何种目的时考虑以下因素。

使用	沙盒的类型	说明
开发	Developer或Developer Pro沙箱	完整的沙箱在创建和刷新时间方面成本更高，并且还允许开发人员访问可能不合适的数据。
测试	•单元测试和Apex测试：Developer或Developer Pro沙箱 •功能测试和回归测试：部分复制沙箱（加载标准数据集）
测试外部集成	当外部系统期望存在完整的生产数据时，完整的沙箱是最佳选择。	如果要使用样本数据或实际数据的子集，则在特殊情况下，部分复制沙箱可能是合适的。 如果您使用外部ID，则效果很好。
分期和用户验收测试	完整沙箱最适合根据生产配置和数据验证新应用程序。	如果针对生产数据子集进行测试是可接受的（例如，区域测试），则部分复制沙箱是合适的。
生产调试	完整的沙箱

沙盒注意事项和限制

沙箱功能与生产不同，您需要规划差异以及复制过程本身。

创建或刷新沙箱时请考虑以下事项：

• 创建或刷新沙箱副本是一项长时间运行的操作，可能在几分钟，几天甚至一周以上完成。有几个条件会影响持续时间，包括自定义数量，数据大小和配置（完整副本），对象数量和服务器负载。此外，沙箱刷新已排队，因此您请求后的副本可能无法立即启动。因此，请尽可能提前计划，并尽可能接受完整沙箱中可选数据的默认最小值。
• 刷新沙箱会删除并重新创建沙箱，作为生产组织的新副本。实际上，这会反转您执行的任何手动访问更改。如果您在沙箱中创建了用户，则它们将不再存在;如果您更改了用户的权限和访问设置，那么这些设置将恢复为生产组织中的值。这意味着刷新后，必须在新副本中重复执行的任何访问更改。要避免此过程，您可以在生产组织中创建用户模板，然后在沙箱组织中激活它们。
• 在沙箱创建和刷新操作期间，对生产组织的设置和数据更改可能会导致沙箱中出现不一致。因此，最好在创建或刷新沙箱时冻结或最小化对生产组织的更改。

以下功能已禁用，无法在沙箱中启用：

• 合同到期警告
• 案件升级
  合同到期警告和案例升级被禁用，因为它们会自动向联系人，客户和生产组织用户发送电子邮件。
• 订阅摘要
• 数据导出（通过单击“安装”中“每周导出服务”页面上的“立即导出”或“计划导出”）
• 创建Salesforce沙箱的功能
• 能够将您在沙盒中创建的电子邮件服务地址复制到生产组织
• 发布Site.com网站的能力

创建开发沙箱

确定特定项目或任务所需的开发环境类型后，请创建生产组织的沙箱副本。

1. 从“设置”中，在“快速查找”框中输入“沙箱”，然后选择“Sandboxes”。
2. 单击“New Sandbox”。
3. 输入沙箱的名称和描述。
4. 选择沙箱类型。
5. 单击“Start Copy”。
   该过程可能需要一段时间，具体取决于您的组织的大小。沙箱完成复制后，您会收到通知电子邮件。
6. 单击通知电子邮件中的链接以访问您的沙箱。
   您可以通过将.sandbox_name附加到您的用户名来登录test.salesforce.com/login.jsp中的沙箱。例如，如果您的生产组织的用户名是user1@acme.com，那么名为“test”的沙箱的用户名是user1@acme.com.test。您的密码与生产中的密码相同。
7. 进行小的更改以确保沙箱不会意外地与生产组织通信。在使用您在此跟踪中创建的沙箱之前，请务必按照更新环境依赖关系中的说明调整这些设置。
   提示：可用沙箱的数量和类型取决于Salesforce组织。

更新环境依赖性

创建沙箱后，将其配置为更新环境依赖项并在开始开发之前合并项目内容。 如果您有多个开发环境，则需要在项目进行时将更改与其他团队成员的更改合并到单个开发环境中。 在此阶段，您必须跟踪所有环境中的更改，以便您可以成功合并这些更改。

环境依赖性是开发环境和生产组织之间不同的设置。 当您在开发环境中工作时，您需要更新谁有权访问什么，打开或关闭某些功能，以及更新内部和外部系统的地址，以便它们指向开发环境而不是生产环境。 反之亦然 – 当您部署到生产环境时，您可能需要更新在开发中使用的某些设置，以便它们与生产一起使用。

环境依赖	细节
Login privileges	如果您的开发人员和测试人员没有生产登录，或者没有必要的权限，则需要在开发环境中为他们提供必要的访问权限。
Email addresses	创建沙箱时，会自动更改电子邮件地址，以便在开发期间不会从沙箱发送电子邮件警报和其他自动通知。当您的开发人员和测试人员登录沙箱时，他们必须将其电子邮件地址更改回真实地址，以接收从沙箱发送的电子邮件。
Email recipients	如果要测试出站电子邮件以获取升级或仪表板等功能，则必须更新收件人列表，因为在创建沙箱时会删除这些列表以防止不必要的电子邮件。
External URLs	如果您的生产组织与外部系统集成，您可能不希望沙箱副本与这些外部系统的生产版本进行通信，以免混合生产和非生产数据。例如，如果使用出站消息传递或Web服务标注，则需要更新这些服务调用的URL以指向这些应用程序的外部开发环境。同样，由于沙箱运行在与生产组织不同的实例上，要测试与沙箱的集成，您需要将API端点主机名从login.salesforce.com更改为 test.salesforce.com。
Hard-coded URLs	通常，当从一个Lightning Platform页面链接到另一个时，链接应该是相对的（省略主机名）而不是绝对的，并且是动态的（按名称查找ID，记录或页面）而不是静态。这允许您在不同组织之间迁移URL，这些组织可能具有不同的主机名或记录ID。如果您的应用程序包含从一个Lightning Platform页面到另一个Lightning Platform页面的硬编码URL，那么当它们从沙箱中单击时可能会中断，或者更糟糕的是，将认为自己处于开发环境中的用户带回生产组织。
Hard-coded IDs	一些组件通常通过其ID访问，例如RecordTypes。创建沙箱副本时，使用这些ID引用这些组件的代码将继续工作，因为沙箱副本会保留生产ID。但是，反之亦然 – 从沙箱迁移到生产（或任何两个组织之间）通过元数据维护组件的名称，但如果目标组织中不存在该组件，则将生成新的ID。因此，迁移包含硬编码ID的代码可能会导致代码中断。作为最佳实践，只要有可能，您应该通过按名称查询组件的ID来获取组件的ID。
Existing projects	如果您有现有的开发项目，则需要将该工作合并到新的开发环境中。

创建用户模板

刷新沙箱会创建生产组织的新副本。 这意味着沙箱中的所有用户权限都是从生产中复制的，并且必须重新应用在刷新之前在沙箱中进行的用户访问或权限更改。 如果您有多个沙箱，或定期刷新沙箱，请考虑在生产组织上创建开发人员用户模板。 开发人员用户模板是具有在沙箱上开发所需权限的抽象用户（例如，“修改所有数据”权限），但在您的生产组织中不活动。 创建或刷新沙箱后，激活沙箱中的开发人员用户并将其分配给将在那里开发的人员。

要创建开发人员模板：

1. 在生产组织上创建新用户。
2. 编辑用户以授予其必要的权限。
3. 停用生产组织上的用户。
4. 创建或刷新沙箱。
5. 在沙箱上激活用户。
6. （可选）更改电子邮件地址，密码或其他环境设置。

警告：在包含从生产中复制的敏感信息（例如，社会保险号）的沙箱组织中授予权限时请务必谨慎。

您可能会发现为不同角色创建多个模板很有帮助。例如，您可以拥有具有“修改所有数据”权限的开发人员角色，以及具有标准用户权限的QA测试人员角色。

您的沙箱具有与生产相同数量的许可证，但您的所有用户都不太可能登录它。创建或刷新沙箱时，生产中处于活动状态的相同用户在沙箱中处于活动状态，因此，如果所有许可证都已占用，则需要停用活动用户以激活非活动开发人员用户。只需确保您在沙箱中停用的用户是永远不会登录该环境的众多生产用户之一。同样，您应该使生产开发人员用户模板在生产组织上处于非活动状态，因此它不会使用付费生产许可证。

有关如何激活，停用或编辑用户的详细信息，请参阅Salesforce联机帮助中的“编辑用户”。

管理沙箱

要管理沙箱，请从“设置”中的“快速查找”框中输入“Sandboxes”，然后选择“Sandboxes”。 显示现有沙箱的列表。

• 单击“New Sandbox”以创建沙箱。当组织达到其沙箱限制时，Salesforce会停用“New Sandbox”按钮。如有必要，请与Salesforce联系，为您的组织订购更多沙箱。
• 单击“Sandbox History”以查看沙箱刷新历史记录的日志，包括何时创建沙箱以及创建沙箱的人员。
• 单击“Refresh”以使用新副本替换现有沙箱。 Salesforce仅显示适用于刷新的沙箱的“Refresh”链接，该链接因不同类型的沙箱而异。在等待刷新完成时，您现有的此沙箱副本仍然可用。刷新的副本在您激活之前处于非活动状态。
• 单击“Activate”以激活刷新的沙箱。您必须先激活刷新的沙箱才能访问它。 Salesforce仅为未激活的沙箱显示此选项。
  警告：激活刷新的沙箱会使用刷新的版本替换现有的沙箱，永久删除现有版本及其中的所有数据。您的生产组织及其数据不受影响。
• 单击Del删除沙箱。
  警告：删除沙箱将永久删除沙箱及其中的所有数据，包括已从沙箱上载的所有出站更改集。
• 管理员可以单击“Login”以用户身份登录沙箱。 Salesforce仅为活动沙箱显示此选项。用户可以通过将.sandbox_name附加到其Salesforce用户名来登录https://test.salesforce.com上的沙箱。例如，如果生产组织的用户名是user1@acme.com，沙箱名为“test”，则登录沙箱的修改后的用户名为user1@acme.com.test。
• 单击沙箱名称以查看有关沙箱的详细信息，包括沙箱类型及其创建时间。

学习目标

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

1. 隔离开发和测试
2. 使用集成，测试和分段开发多个项目
3. 开发环境
4. 沙箱用途
5. 沙盒注意事项和限制
6. 创建开发沙箱
7. 更新环境依赖性
8. 创建用户模板
9. 管理沙箱

在Lightning平台上进行开发需要一个开发环境，一个可以在不影响其他用户的情况下工作的地方。在传统的软件开发中，开发环境只不过是一个自己调用的空间，但在Lightning平台上，每个开发环境都是自己的全功能Salesforce组织。

在快速入门：使用沙盒和变更集中，我们使用单个开发环境（开发人员沙箱）来进行与生产组织隔离的更改。在更复杂的场景中，您可能有多种环境用于各种目的，例如开发，集成，测试和培训。还有不同类型的开发环境最适合不同的用途。

使用单个开发环境进行开发和测试时，必须停止开发以进行测试，并且只能在部署后恢复开发。除非您有一个开发人员执行所有这些任务，否则这可能是资源的低效使用。更复杂的开发模型允许在进行测试和部署时继续开发。在这种情况下，您需要两个隔离的环境，一个用于开发，另一个用于测试。

隔离开发和测试

具有单独的开发和测试环境会增加开发过程的复杂性，并引入一个问题：现有组件的更改在哪里发生？例如，假设您有一个开发的应用程序，然后将这些更改迁移到您的测试环境。在测试期间，您发现需要进行一些更改才能部署到生产环境。您是在测试环境中进行这些更改还是返回开发组织并再次启动该过程？如果您只有两个沙箱，则可能需要在测试组织中进行这些更改，因为这是一个更快速，更简单的过程，并且您的开发沙箱可能已经更改为无法轻松重新开始的地方。但是，您仍然希望将测试环境中所做的任何更改复制回开发环境，以确保下次从开发升级到测试时保留修复。应用程序开发过程的安排和流程如下图所示：

典型的开发生命周期：

1. 创建开发环境。
2. 使用Salesforce Web和本地工具进行开发。
3. 创建测试环境。
4. 将更改从开发环境迁移到测试环境。
5. 测试。
6. 在其他环境中复制生产更改。
7. 将您开发的内容部署到生产组织。

典型的开发项目：

• 新的自定义对象，选项卡和应用程序
• 与其他系统的集成
• 涉及工作流程或新验证规则的应用

使用集成，测试和分段开发多个项目

如果您有多个开发人员和多个正在开发的项目将同时发布，则需要进行集成测试以确保可以合并单独的代码行而不会发生冲突。将来，您可能希望包括用户验收测试（UAT）以确定是否满足原始设计要求。更复杂的开发过程还可以包含一个临时环境，您可以确保生产部署完全按计划进行。

在这种开发方案中，您可能想知道在哪里更改代码行。如果某个功能在生产部署的方式上未通过任何测试，您是否在组织失败的情况下修复该功能，或者重新启动整个过程？随着应用程序开发过程的复杂性增加，您会发现随时修复并不是一个好模型。相反，您将希望在开发组织中进行所有修复，并遵循可重复的过程将该更改迁移到生产中。下图描绘了此过程：

典型的开发生命周期：

1.创建开发环境。
2.使用Salesforce Web和本地工具进行开发。
3.创建测试环境，包括UAT和集成。
4.将更改从开发环境迁移到集成环境。
5.测试。
6.将更改从集成环境迁移到UAT环境。
7.执行用户验收测试。
8.将更改从UAT环境迁移到登台环境。
9.在分段环境中复制生产更改。
10.安排发布。

典型的开发项目：

• 在多个环境中同时开发新应用程序
• 需要团队开发的项目

开发环境

有两种类型的开发环境：sandbox orgs和Developer Edition orgs。

沙箱是从您的生产组织中复制的新组织。 本节列出了支持沙箱的Salesforce版本。 有不同类型的沙箱适合不同的用途。

 

沙箱类型	描述
Developer	Developer 沙箱复制自定义（元数据），但不将生产数据复制到单独的环境中进行编码和测试。
Developer Pro	Developer Pro沙箱复制自定义（元数据），但不将生产数据复制到单独的环境中进行编码和测试。 Developer Pro比开发人员沙箱拥有更多存储空间。 它包含许多开发人员沙箱，具体取决于您的生产组织的版本。
Partial Copy	部分副本沙箱是开发人员沙箱以及您在沙箱模板中定义的数据。
Full	完整沙箱会复制整个生产组织及其所有数据，包括标准和自定义对象记录，文档和附件。 使用沙箱编码和测试更改，并培训团队有关更改的信息。 您可以每29天刷新一次完整沙箱。

沙箱还可以包含部分，无或所有生产数据，具体取决于预期用途。对于开发，您可能只需要一小组数据来确保工作正常。对于QA测试，尤其是回归测试，您需要一组不会随时间变化的大量数据。对于预部署分段，您需要一个尽可能靠近生产环境的沙箱，包括数据。只有完整的沙箱在创建数据时才会复制数据，但您可以使用导入向导或数据加载器将数据添加到沙箱中。

另一种类型的开发环境是Developer Edition组织。 Developer Edition提供对Professional，Enterprise，Unlimited和Performance版本提供的许多独有功能的免费访问。您可以完全访问Lightning平台和API，以便您可以扩展Salesforce，与其他应用程序集成，以及开发新的工具和应用程序。 Developer Edition组织主要由独立软件供应商（ISV）使用，用于在AppExchange上创建分发应用程序。有关更多信息，请参阅ISVforce指南。

沙箱用途

如果您的组织有多个沙箱可用，请在规划哪些沙箱用于何种目的时考虑以下因素。

使用	沙盒的类型	说明
开发	Developer或Developer Pro沙箱	完整的沙箱在创建和刷新时间方面成本更高，并且还允许开发人员访问可能不合适的数据。
测试	•单元测试和Apex测试：Developer或Developer Pro沙箱 •功能测试和回归测试：部分复制沙箱（加载标准数据集）
测试外部集成	当外部系统期望存在完整的生产数据时，完整的沙箱是最佳选择。	如果要使用样本数据或实际数据的子集，则在特殊情况下，部分复制沙箱可能是合适的。 如果您使用外部ID，则效果很好。
分期和用户验收测试	完整沙箱最适合根据生产配置和数据验证新应用程序。	如果针对生产数据子集进行测试是可接受的（例如，区域测试），则部分复制沙箱是合适的。
生产调试	完整的沙箱

沙盒注意事项和限制

沙箱功能与生产不同，您需要规划差异以及复制过程本身。

创建或刷新沙箱时请考虑以下事项：

• 创建或刷新沙箱副本是一项长时间运行的操作，可能在几分钟，几天甚至一周以上完成。有几个条件会影响持续时间，包括自定义数量，数据大小和配置（完整副本），对象数量和服务器负载。此外，沙箱刷新已排队，因此您请求后的副本可能无法立即启动。因此，请尽可能提前计划，并尽可能接受完整沙箱中可选数据的默认最小值。
• 刷新沙箱会删除并重新创建沙箱，作为生产组织的新副本。实际上，这会反转您执行的任何手动访问更改。如果您在沙箱中创建了用户，则它们将不再存在;如果您更改了用户的权限和访问设置，那么这些设置将恢复为生产组织中的值。这意味着刷新后，必须在新副本中重复执行的任何访问更改。要避免此过程，您可以在生产组织中创建用户模板，然后在沙箱组织中激活它们。
• 在沙箱创建和刷新操作期间，对生产组织的设置和数据更改可能会导致沙箱中出现不一致。因此，最好在创建或刷新沙箱时冻结或最小化对生产组织的更改。

以下功能已禁用，无法在沙箱中启用：

• 合同到期警告
• 案件升级
  合同到期警告和案例升级被禁用，因为它们会自动向联系人，客户和生产组织用户发送电子邮件。
• 订阅摘要
• 数据导出（通过单击“安装”中“每周导出服务”页面上的“立即导出”或“计划导出”）
• 创建Salesforce沙箱的功能
• 能够将您在沙盒中创建的电子邮件服务地址复制到生产组织
• 发布Site.com网站的能力

创建开发沙箱

确定特定项目或任务所需的开发环境类型后，请创建生产组织的沙箱副本。

1. 从“设置”中，在“快速查找”框中输入“沙箱”，然后选择“Sandboxes”。
2. 单击“New Sandbox”。
3. 输入沙箱的名称和描述。
4. 选择沙箱类型。
5. 单击“Start Copy”。
   该过程可能需要一段时间，具体取决于您的组织的大小。沙箱完成复制后，您会收到通知电子邮件。
6. 单击通知电子邮件中的链接以访问您的沙箱。
   您可以通过将.sandbox_name附加到您的用户名来登录test.salesforce.com/login.jsp中的沙箱。例如，如果您的生产组织的用户名是user1@acme.com，那么名为“test”的沙箱的用户名是user1@acme.com.test。您的密码与生产中的密码相同。
7. 进行小的更改以确保沙箱不会意外地与生产组织通信。在使用您在此跟踪中创建的沙箱之前，请务必按照更新环境依赖关系中的说明调整这些设置。
   提示：可用沙箱的数量和类型取决于Salesforce组织。

更新环境依赖性

创建沙箱后，将其配置为更新环境依赖项并在开始开发之前合并项目内容。 如果您有多个开发环境，则需要在项目进行时将更改与其他团队成员的更改合并到单个开发环境中。 在此阶段，您必须跟踪所有环境中的更改，以便您可以成功合并这些更改。

环境依赖性是开发环境和生产组织之间不同的设置。 当您在开发环境中工作时，您需要更新谁有权访问什么，打开或关闭某些功能，以及更新内部和外部系统的地址，以便它们指向开发环境而不是生产环境。 反之亦然 – 当您部署到生产环境时，您可能需要更新在开发中使用的某些设置，以便它们与生产一起使用。

环境依赖	细节
Login privileges	如果您的开发人员和测试人员没有生产登录，或者没有必要的权限，则需要在开发环境中为他们提供必要的访问权限。
Email addresses	创建沙箱时，会自动更改电子邮件地址，以便在开发期间不会从沙箱发送电子邮件警报和其他自动通知。当您的开发人员和测试人员登录沙箱时，他们必须将其电子邮件地址更改回真实地址，以接收从沙箱发送的电子邮件。
Email recipients	如果要测试出站电子邮件以获取升级或仪表板等功能，则必须更新收件人列表，因为在创建沙箱时会删除这些列表以防止不必要的电子邮件。
External URLs	如果您的生产组织与外部系统集成，您可能不希望沙箱副本与这些外部系统的生产版本进行通信，以免混合生产和非生产数据。例如，如果使用出站消息传递或Web服务标注，则需要更新这些服务调用的URL以指向这些应用程序的外部开发环境。同样，由于沙箱运行在与生产组织不同的实例上，要测试与沙箱的集成，您需要将API端点主机名从login.salesforce.com更改为 test.salesforce.com。
Hard-coded URLs	通常，当从一个Lightning Platform页面链接到另一个时，链接应该是相对的（省略主机名）而不是绝对的，并且是动态的（按名称查找ID，记录或页面）而不是静态。这允许您在不同组织之间迁移URL，这些组织可能具有不同的主机名或记录ID。如果您的应用程序包含从一个Lightning Platform页面到另一个Lightning Platform页面的硬编码URL，那么当它们从沙箱中单击时可能会中断，或者更糟糕的是，将认为自己处于开发环境中的用户带回生产组织。
Hard-coded IDs	一些组件通常通过其ID访问，例如RecordTypes。创建沙箱副本时，使用这些ID引用这些组件的代码将继续工作，因为沙箱副本会保留生产ID。但是，反之亦然 – 从沙箱迁移到生产（或任何两个组织之间）通过元数据维护组件的名称，但如果目标组织中不存在该组件，则将生成新的ID。因此，迁移包含硬编码ID的代码可能会导致代码中断。作为最佳实践，只要有可能，您应该通过按名称查询组件的ID来获取组件的ID。
Existing projects	如果您有现有的开发项目，则需要将该工作合并到新的开发环境中。

创建用户模板

刷新沙箱会创建生产组织的新副本。 这意味着沙箱中的所有用户权限都是从生产中复制的，并且必须重新应用在刷新之前在沙箱中进行的用户访问或权限更改。 如果您有多个沙箱，或定期刷新沙箱，请考虑在生产组织上创建开发人员用户模板。 开发人员用户模板是具有在沙箱上开发所需权限的抽象用户（例如，“修改所有数据”权限），但在您的生产组织中不活动。 创建或刷新沙箱后，激活沙箱中的开发人员用户并将其分配给将在那里开发的人员。

要创建开发人员模板：

1. 在生产组织上创建新用户。
2. 编辑用户以授予其必要的权限。
3. 停用生产组织上的用户。
4. 创建或刷新沙箱。
5. 在沙箱上激活用户。
6. （可选）更改电子邮件地址，密码或其他环境设置。

警告：在包含从生产中复制的敏感信息（例如，社会保险号）的沙箱组织中授予权限时请务必谨慎。

您可能会发现为不同角色创建多个模板很有帮助。例如，您可以拥有具有“修改所有数据”权限的开发人员角色，以及具有标准用户权限的QA测试人员角色。

您的沙箱具有与生产相同数量的许可证，但您的所有用户都不太可能登录它。创建或刷新沙箱时，生产中处于活动状态的相同用户在沙箱中处于活动状态，因此，如果所有许可证都已占用，则需要停用活动用户以激活非活动开发人员用户。只需确保您在沙箱中停用的用户是永远不会登录该环境的众多生产用户之一。同样，您应该使生产开发人员用户模板在生产组织上处于非活动状态，因此它不会使用付费生产许可证。

有关如何激活，停用或编辑用户的详细信息，请参阅Salesforce联机帮助中的“编辑用户”。

管理沙箱

要管理沙箱，请从“设置”中的“快速查找”框中输入“Sandboxes”，然后选择“Sandboxes”。 显示现有沙箱的列表。

• 单击“New Sandbox”以创建沙箱。当组织达到其沙箱限制时，Salesforce会停用“New Sandbox”按钮。如有必要，请与Salesforce联系，为您的组织订购更多沙箱。
• 单击“Sandbox History”以查看沙箱刷新历史记录的日志，包括何时创建沙箱以及创建沙箱的人员。
• 单击“Refresh”以使用新副本替换现有沙箱。 Salesforce仅显示适用于刷新的沙箱的“Refresh”链接，该链接因不同类型的沙箱而异。在等待刷新完成时，您现有的此沙箱副本仍然可用。刷新的副本在您激活之前处于非活动状态。
• 单击“Activate”以激活刷新的沙箱。您必须先激活刷新的沙箱才能访问它。 Salesforce仅为未激活的沙箱显示此选项。
  警告：激活刷新的沙箱会使用刷新的版本替换现有的沙箱，永久删除现有版本及其中的所有数据。您的生产组织及其数据不受影响。
• 单击Del删除沙箱。
  警告：删除沙箱将永久删除沙箱及其中的所有数据，包括已从沙箱上载的所有出站更改集。
• 管理员可以单击“Login”以用户身份登录沙箱。 Salesforce仅为活动沙箱显示此选项。用户可以通过将.sandbox_name附加到其Salesforce用户名来登录https://test.salesforce.com上的沙箱。例如，如果生产组织的用户名是user1@acme.com，沙箱名为“test”，则登录沙箱的修改后的用户名为user1@acme.com.test。
• 单击沙箱名称以查看有关沙箱的详细信息，包括沙箱类型及其创建时间。

学习目标

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

1. 在生产组织中开发
2. 用Sandbox开发
3. 沙箱组织
4. 快速入门：使用沙箱和更改集
5. 创建开发人员沙箱
6. 授权部署连接
7. 创建和上载出站变更集
8. 验证入站变更集
9. 部署入站变更集

 

1. 在Lightning平台上开发应用程序非常简单，直接且高效。开发人员可以使用Web界面的点击工具定义应用程序组件，例如自定义对象和字段，工作流规则，Visualforce页面以及Apex类和触发器。可以立即实施和部署简单更改，而不会影响生产组织中的其他用户。更复杂的功能可以保留在开发状态，直到它们经过全面测试，然后部署到生产组织中的每个人。
2. 但是，与其他几个开发人员合作构建大型企业应用程序时，这些相同的开发实践如何运作？在使用高度自定义的逻辑和用户界面开发复杂应用程序时，在单一环境中即时配置不再有意义。这些应用程序需要时间来开发，并需要更多正式的实践来​​确保它们按预期工作并满足用户的需求。

   还有很多中间立场。您的项目可能看起来不那么大，也许您正在自己进行开发以及日常管理任务。您仍然可以使用沙箱作为开发环境 – 您可以在不影响最终用户的情况下开发自定义和代码的地方。更传统的基于项目的开发为Lightning Platform开发开辟了新的可能性，但也需要新的开发，迁移和同步流程。

   无论您是架构师，管理员，开发人员还是经理，本指南都将帮助您准备在Lightning平台上开发和发布应用程序。它从最基本的场景开始，使用开发人员沙箱和更改集。后面的章节介绍了更复杂的企业方案的其他开发环境，工具和流程。

   Develop in a Production Organization

   开发新功能的最简单方法是使用Salesforce Web用户界面自定义生产组织。 您可以使用功能强大且易于使用的声明性工具开发新对象和应用程序。 在这种情况下，所有开发都在生产组织上进行，因此不需要单独的开发或测试环境。 虽然此过程是完成开发生命周期循环的最快方法，但您可以完成的任务有限。 例如，您无法直接在生产组织中编写Apex代码。

   

 

典型的开发生命周期：

1. 规划功能要求。
2. 使用Salesforce Web工具进行开发，使用配置文件隐藏您的更改，直到它们准备好部署。
3. 更新配置文件以显示对相应用户的更改。
4. 通知最终用户更改。

单个管理员可以有效地开发新的仪表板，报告和电子邮件模板，或者以这种方式向现有对象添加新的自定义字段。但是，当开发更复杂并且涉及多个团队成员时，更正式的应用程序生命周期场景是合适的。

用Sandbox开发

对于稍微复杂一些或必须与生产组织隔离的开发任务，您可以使用单独的开发环境，通常是沙箱。在此方案中，所有开发和测试都在开发环境中进行，然后将更改提升到生产组织。

如果要同时在生产和沙箱组织中开发项目，请考虑跟踪在生产组织中进行的设置更改并在沙箱中复制它们。这很重要，因为如果您的沙箱具有过时的自定义设置，则在从沙箱中提升时，您可能会无意中使用这些较旧的自定义项替换生产中的较新更改。

典型的开发生命周期：

1. 创建开发环境。
2. 使用Salesforce Web和本地工具进行开发。
3. 在开发环境中进行测试。
4. 在开发环境中复制生产更改。
5. 将您开发的内容部署到生产组织。 典型的开发项目：
   • 新的自定义对象，选项卡和应用程序
   • 与其他系统的集成
   • 涉及Apex，Visualforce，工作流程或新验证规则的应用程序

沙箱组织

沙箱是您的生产组织的副本。 沙箱包含相同的元数据 – 作为生产组织的配置信息，例如自定义对象和字段，应用程序和工作流的类型。 该元数据以及完整沙箱中的数据将复制到与生产组织隔离的新组织中。 您在沙箱中执行的操作不会影响您的生产组织。

沙盒可用于Professional，Enterprise，Unlimited和Performance Edition。 使用Unlimited和Performance Edition，您可以创建多个不同类型的沙箱副本。 使用沙箱进行开发，测试，培训或其他目的，而不会影响Salesforce生产组织中的数据和应用程序。 每个沙箱实例都与其他所有沙箱实例隔离，就像它们来自生产一样。

关于在组织之间迁移更改

将配置更改从一个组织发送到另一个组织的最简单方法是使用更改集。 要将当前组织的自定义项发送到其他组织，请创建出站更改集。 发送更改集后，接收组织会将其视为入站更改集。

更改集只能包含您可以通过“设置”菜单进行的更改，并且它们不支持可自定义的每种类型的组件。您也无法使用更改集来重命名或删除组件。如果进行更改集不支持的更改，则可以通过重复在其他组织中执行的步骤手动迁移它们。有关更改集中可用组件的更多信息，请参阅Salesforce联机帮助。

某些组件依赖于其他组件。例如，自定义对象的自定义字段依赖于该自定义对象的存在。如果您尝试将这些自定义字段迁移到不包含它们所依赖的自定义对象的组织，则部署将失败。创建更改集时，可以轻松查看和添加依赖项，以确保迁移所有必需的组件。

在两个组织之间发送更改集需要部署连接。变更集只能在与生产组织相关联的组织之间发送。例如，生产组织和沙箱，或从同一组织创建的两个沙箱可以发送或接收更改集。

仅部署连接不允许在组织之间发送更改集。 必须授权每个组织发送和接收变更集。 这种增加的安全级别强制执行代码提升路径，并防止组织设置元数据被错误覆盖。

快速入门：使用沙箱和更改集

按照以下步骤创建开发人员沙箱，并使用更改集将您在其中创建的配置更改迁移到生产组织。

创建开发人员沙箱

使用开发人员沙箱确保您的更改与生产隔离，直到您准备好部署它们为止。

沙盒可用于Professional，Enterprise，Unlimited和Performance版本。

1. 从“设置”中，在“快速查找”框中输入“Sandboxes”，然后选择“Sandboxes”。
2. 单击“New Sandbox.”。
3. 输入沙箱的名称和描述。
4. 选择Developer作为沙箱类型。
5. 单击“开始复制”。
   此过程可能需要一段时间，具体取决于您的组织规模。沙箱完成复制后，您会收到通知电子邮件。
6. 单击通知电子邮件中的链接以访问您的沙箱。
   您可以通过将.sandbox_name附加到您的用户名来登录test.salesforce.com/login.jsp中的沙箱。例如，如果您的生产组织的用户名是user1@acme.com，那么名为“test”的沙箱的用户名是user1@acme.com.test。
   注意：Salesforce会自动更改沙箱用户名，但不会更改密码。

如果您想在将更改集用于开发项目之前尝试使用更改集，请立即在开发人员沙箱中使用自定义字段创建测试自定义对象。 您可以在接下来的步骤中练习部署这些自定义项，并在完成后删除它们。

授权部署连接

在您可以从沙箱或其他组织接收更改集之前，请在接收更改的组织中授予部署连接。

1. 登录将接收入站变更集的组织。 通常，这是与您的沙箱关联的生产组织。
2. 从“设置”中，在“快速查找”框中输入“Deployment ”，然后选择“Deployment Settings”
3. 单击要从中接收出站更改集的组织旁边的“Edit”。 通常这是你的沙箱。
4. 选择“Allow Inbound Changes”并单击“Save”。

创建和上载出站变更集

通常，您在沙箱组织中创建出站更改集并将其部署到生产中。 但是，根据您的开发生命周期，您可以选择在相关组织之间以任一方向迁移更改。

1. 从“设置”中，在“快速查找”框中输入“Outbound Change Sets”，然后选择“Outbound Change Sets”。
2. 单击“New”。
3. 输入更改集的名称，然后单击“Save”。
4. 在“更改集组件”部分中，单击“Add”。
5. 选择组件类型（例如，“自定义对象”或“自定义字段”），要添加的组件，然后单击“Add To Change Set.”。
   如果您正在尝试测试自定义对象和自定义字段，请尝试首先将其中一个添加到更改集。
6. 单击“View/Add Dependencies”以查看您添加到更改集的组件是否依赖于其他自定义项。
   对于测试自定义对象和自定义字段，将列出相关组件和页面布局。
7. 选择要添加的从属组件，然后单击“Add To Change Set”。
8. 单击“Upload”并选择目标组织。
   出站更改集详细信息页面显示一条消息，并在上载完成时收到电子邮件通知。

验证入站变更集

通过验证更改集，您可以在不提交更改的情况下查看成功或失败消息。

1. 从“设置”中，在“快速查找”框中输入“入站变更集”，然后选择“入站变更集”。
2. 单击更改集的名称。
3. 单击“验证”。
   我们建议在非高峰使用时间开始验证，并在验证过程中限制对组织的更改。验证过程会锁定正在部署的资源。在验证过程中对锁定资源或与这些资源相关的项目所做的更改可能会导致错误。
   注意：如果将字段类型从Master-Detail更改为Lookup，反之亦然，则在使用Validate选项测试部署时不支持更改。测试部署不支持此更改，以避免数据丢失或损坏。如果部署包中包含测试部署不支持的更改，则测试部署将失败并发出错误。
   如果部署包将字段类型从Master-Detail更改为Lookup，反之亦然，则仍可在部署到生产之前验证更改。对另一个测试沙箱执行完全部署。完整部署包括在部署过程中验证更改
4. 验证完成后，单击“查看结果”。
   如果收到错误消息，请在部署之前解决它们。 最常见的错误原因是未包含在更改集和Apex测试失败中的相关组件。

部署入站变更集

部署更改集会将其包含的更改提交给目标组织。

1. 从“设置”中，在“快速查找”框中输入“入站变更集”，然后选择“入站变更集”。
2. 在“更改集等待部署”列表中，单击要部署的更改集的名称。
3. 单击“部署”。
   变更集部署在单个事务中。 如果部署由于任何原因无法完成，则回滚整个事务。 部署成功完成后，所有更改都将提交到您的组织，并且无法回滚部署。