作者： ponybai

学习目标

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

• 描述配置公司设置如何影响最终用户。
• 将公司的业务需求转换为您的公司设置。
• 实施对公司信息和会计年度的更改。
• 更新您的个人区域设置。

什么是公司设置？

你有没有想过一个替代身份？无论你的意图是好的，坏的，还是道德上的阴暗（嘿，我们都不判断），确保伪造护照，面部重建手术和背景故事都很棘手。在Salesforce中更改公司设置要容易得多。

您的公司设置是有关您组织的信息的集合。此集合主要在您购买Salesforce产品时捕获，但如果您的公司在全球范围内移动操作或扩展，则可以更新设置。它基本上是贵公司身份的快照。为了给这个主题带来一丝国际魅力，让我们帮助Mom＆Pop的间谍商店了解他们的公司设置包含的内容，并根据他们的情况变化更新它们。

但首先，让我们分解公司设置包括的内容：

		关键细节	例如
公司信息	姓名和地址	用于计费和支持	流行音乐的商店7 Wink Nudge Drive 弗里斯科，CA 94101
	主要联系人	还用于计费和支持	Mother Intrigue
	默认区域设置	更新此设置可确定Salesforce中显示大量信息的方式（我们稍后单独介绍）	美国英语
	默认货币	货币适用于记录	英语（美国）USD
	货币	组织中使用的所有货币的列表	仅限美元
	使用的存储	那些猫的照片堆得很快！	27.3 GB（11％）
	可用的许可证	包括Salesforce和功能许可证	Salesforce平台：15个中的14个使用过
财年信息	财政年度	用于报告和预测	标准，从1月开始
支持信息	营业时间	这些在升级规则升级时使用	周一至周五，上午8点至晚上8点
	假期	案件跳过升级的日子	10月1日（国际神秘日）

好的，但什么是区域设置？

以熟悉的方式向用户显示信息可以改善用户的Salesforce体验，并使他们成为更有效的秘密代理。 Salesforce区域设置确定日期和时间的显示格式，用户的名称，地址，逗号和句点的数字。作为管理员，您可以设置默认语言环境，但如果用户位于其他位置，则用户可以设置个人语言环境。我们稍后会介绍这两个设置，但让我们首先看看更新默认或个人区域设置会对哪些设置产生影响。

区域设置包括		例如
区域设置	日期和时间格式	mm / dd / yyyy或dd / mm / yyyy
	数字格式	1,000 or 1.000 for one thousand
	名称顺序	Last, First or First Last
	地址格式	国家，邮政编码，州，然后街
	电话号码格式	（123）456-7890或+12 2345 67-0
语言	所有文字	标准选项卡和字段
	网上帮助	帮助中的文本语言
时区	活动开始/结束时间	日历条目和事件
	日期或时间字段

更新您的公司信息

好消息！经过多年努力的秘密工作，Mom＆Pop的Spy Shop被最大和资金最充足的公司之一Nacho Secrets Agency收购。让我们来看看在重新定位和合并财务系统后如何更新公司设置。

为此模块创建一个新的Trailhead Playground。在检查挑战时使用现有组织可能会产生问题（甚至可能触发机器人革命）。单击启动动手组织按钮旁边的下拉箭头，然后选择创建Trailhead Playground。

1. 启动您的 Trailhead Playground.
2. 单击选择Setup.
3. 在快速查找框中输入Company Information，然后选择Company Information。此页面显示您的组织地址，区域设置，时区，货币，并允许您查看已使用的存储和许可证。
4. 单击Edit.
5. 更新与您的新位置相关的信息：
   
   • 地址:
     • 街: 007 Cipher Cl
     • 城市: London
     • 邮编/邮编: EC2N 2DB
     • Country: United Kingdom
   • 区域设置:
     • 默认语言环境: English (United Kingdom)
     • 默认时区: (GMT +00:00) Greenwich Mean Time
6. 单击Save.

注意我们可以更改的其他设置？我们将在下一个单元中介绍货币设置。但接下来，让我们看看如何更新会计年度：

1. 从“设置”中，在“快速查找”框中输入“Fiscal Year”，然后选择“Fiscal Year”。
2. 将会计年度开始月份更改为7月份。
   注意：您还可以选择更改会计年度是基于结束月份还是开始月份，或者配置完全自定义会计年度。
   
3. 保留其他设置并单击“ Save”，然后单击“OK”

更新您的个人区域设置

如您所知，“公司信息”页面包含贵公司的默认区域设置，语言和时区。但总部以外的员工可以选择自己的区域设置来匹配他们的情况。而且语言环境不仅涵盖了位置 – 想象一位居住在俄勒冈州的葡萄牙语用户，而是与巴西的客户合作。让我们看看我们如何更新个人设置，以便满足用户的需求，即使与公司区域设置不同，也可以满足用户的需求。

1. 在标题中，单击您的个人资料图标，然后选择Settings.
2. 在快速查找框中输入 Language  ，然后选择 Language & Time Zone.
3. 在此“设置”区域中，用户可以选择与其情况相匹配的时区，区域设置和语言。对于我们的示例，我们选择太平洋时区，英语（美国）语言环境和葡萄牙语。
   注意：请勿立即执行此操作，否则Salesforce组织将以葡萄牙语显示所有UI。 （当然，除非你说葡萄牙语，然后去找它！）
   
4. 如果启用并配置了多币种（我们将在下一个单元中向您展示），您还可以在此处设置个人货币 – 在本例中为巴西雷亚尔。
5. 单击 Save.

更改时间可能需要轻微或严重的身份更改。幸运的是，无论任务在何处，您的公司信息和个人区域都可以快速更新。接下来，我们将学习如何控制和更新货币以实现全球运营。

学习目标

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

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帮助中介绍了如何保存，同步和刷新文件。

整合开发环境的变化

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

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

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