Salesforce开发生命周期（8）高级开发生命周期场景

学习目标

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

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沙箱环境，以确保部分数据副本具有当前数据。
• 根据需要刷新开发人员沙箱。 例如，开发人员可以刷新他们的沙箱，以获得组织的配置和元数据的干净副本，他们可以将其用作基线并添加自定义。