分类： 应用程序生命周期和开发模型

学习目标

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

• 确定包开发和变更集开发之间的主要区别。
• 描述什么是软件包版本，以及它如何帮助您管理组织中的更改。
• 总结一下为什么在使用软件包开发模型时不必手动跟踪安装程序更改。

本单元描述了Calvin和他的同事为何决定从变更集开发模型转向软件包开发的原因。其他团队可能会发现软件包开发的不同方面。当您通读本单元时，请考虑为团队做出哪些选择，以及包装开发的哪个方面最引人注目。通过阅读本模块末尾列出的模块来进行动手操作，以学习该过程并就最适合您的情况做出最明智的决定。

变更集的变更管理挑战

随着时间的推移，Zephyrus的每个版本及其生产组织的项目和贡献者数量都在不断增长。这对用户来说很棒。公司对ALM步骤的一致应用为增强请求提供了良好的周转时间，同时将中断降到最低。

但是，协调这些更改，尤其是来自多个团队的许多无关的更改，对于Calvin来说确实是头疼的事。这些发行版的大小和复杂性继续增加。他担心，鉴于很难在一个版本中汇总和测试所有项目的变更，因此Zephyrus员工所依赖的功能将无法使用。

Calvin每次发布中都会进行大量更改以进行协调和跟踪，因此Calvin意识到他宁愿花时间进行更改。他还认为，在Zephyrus定制Salesforce的团队如果花更少的时间与其他项目中的变更进行协调，可能会提高生产力。

一个容器还是多个容器？

在Salesforce Trailblazer社区上，Calvin要求其他成员提供有关如何在每个版本中管理这么多项目的建议。他们告诉他一个新的Salesforce开发模型，该模型为发布管理提供了更大的灵活性。这就是所谓的包开发。

在程序包开发中，您将不同的自定义项作为单独的程序包进行管理，而不是作为对组织所做的一项重大更改来管理。还记得在变更集开发中，如何将多个项目中的一组变更管理到一个容器中吗？当发布变得如此复杂以至于需要将组织作为多个容器进行管理时，就该转向软件包开发模型了。如果您的团队已经在其他平台上构建模块化发行工件，那么他们会在软件包开发中发现一些相似之处。

例如，Zephyrus的软件包可能包含以下任何自定义项。

• 他们内部构建的自定义Force.com应用
• Sales Cloud，Service Cloud等的扩展
• AppExchange应用程序的扩展
• 更新共享库和功能

当您在程序包开发模型中工作时，您将构建一个发布工件，可以独立于其他项目的工件进行测试和发布。您的团队将创建一个包含所有相关元数据的包，而不是相对于生产进行一系列更改。程序包中的元数据包括已更改和未更改的组件。

通过软件包组织元数据更新还可以帮助您更好地构建组织中元数据结构的思维模型。如果要将组织作为多个容器管理，则每个软件包都代表这些容器之一。

甲包版本是包的内容和相关元数据的固定快照。软件包版本使您可以管理每次发布或部署添加到软件包的一组特定更改时的区别。如果要对已部署的软件包引入元数据更改，请从当前软件包版本升级到较新的软件包版本。

加尔文被转向包装开发的潜在生产率提高所激怒。他向创建销售Salesforce定制的其他部门的首席执行官Ernesto，首席执行官和董事提出了要求。他专注于三个要点。

• 创建清晰的审计线索，以了解组织元数据如何随时间变化
• 通过腾出当前用于跟踪安装程序更改的时间来提高生产力
• 获得更大的发布灵活性，因为每个软件包都可以独立于其他项目的软件包进行开发，测试和发布

您的真理之源是源中的元数据

在软件包开发中，真理的源头是软件包项目中的元数据。这样可以轻松集成到VCS，这可以帮助您的团队管理他们进行的项目更改。

在变更集开发中，真理的来源是环境中已经存在的元数据和变更集的最后构建的结合。单靠更改集无法呈现完整的画面，因为它仅包含更改的内容，例如差异。

告别手动跟踪设置更改

软件包开发中有一个称为“ scratch orgs”的开发环境。Scratch组织在大幅减少Calvin及其团队需要跟踪的每个版本的更改中扮演着关键角色。

临时组织是空组织（没有元数据或数据），可以根据需要轻松创建和处置。您可以将临时组织配置为具有不同功能和首选项的不同Salesforce版本。而且，您可以重新使用草稿组织定义文件并与其他团队成员共享，因为它是集成到VCS中的项目的一部分。这样，在所有人都有自己的开发环境时，所有人都可以在同一组织配置中工作要简单得多。

当使用草稿组织进行开发时，首先要在VCS中推送项目中的源，以将草稿组织与相同的元数据同步。如果您打算使用安装程序进行开发，则会自动跟踪您所做的更改。您可以下拉所做的修改，以将其包括在项目中，并使用VCS提交所有更改。

Calvin如何知道源跟踪中支持哪些组件？元数据覆盖率报告向您显示源跟踪，元数据API和其他元数据通道中是否支持元数据类型。该动态生成的报告是元数据覆盖信息的最佳来源。要访问“元数据覆盖率”报告，请访问https://developer.salesforce.com/docs/metadata-coverage。

每个包裹都有自己的比赛

在软件包开发中，您可以为每个软件包维护单独的发布计划。您使用包来分割组织元数据的所有权，因此每个项目都有其自己的包以及任何相关包。您可以通过每个后续软件包版本独立管理各个段的升级，从而可以维护单独的发布计划。

什么是包依赖关系？元数据组件一次只能位于一个包中。如果多个软件包需要相同的组件，则可以为该组件设计模块化的软件包策略。包含多个程序包共享的一个或多个元数据组件的程序包是程序包依赖项。

每个程序包（以及任何程序包依赖项）都可以与组织中的所有其他元数据隔离地进行测试。将这样的元数据隔离到程序包中，可以灵活地分别对这些元数据集（程序包）进行版本控制。这也使您可以灵活地独立发布软件包。

学习目标

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

• 说明使用版本控制如何使变更集版本受益。
• 描述变更集和组织开发模型之间的相似之处。

本单元描述了为什么Calvin和他的同事着手进行代码和版本控制系统的开发。在阅读本单元时，请考虑为团队做出哪些选择。通过完成本模块末尾列出的模块来进行动手操作，以学习该过程并就最适合您的情况做出最明智的决定。

为了应付日益增加的复杂性，转向组织发展模式

Zephyrus有一个伟大的四分之一。现在，Salesforce正在业务的其他部分中使用，而不仅仅是在Sales中。在咨询了Calvin和客户服务部门的负责人之后，COO同意迁移到企业版并购买Service Cloud Lightning。借助Service Cloud Lightning，公司可以为客户提供即时和个性化的支持。更好的是，客户服务部门拥有一些具有编码技能的团队成员，可以根据他们的团队需求开发Salesforce应用程序。

对于Calvin来说，很明显，组织的复杂性正在超出团队可以通过变更集开发流程管理的范围。公司现在需要更严格的变更管理流程和审核流程（例如版本控制系统）来帮助他们管理如此多的工作流。

团队还面临着使用变更集所能做的限制。例如，他们可以添加但不能删除字段（破坏性更改）。

在向Zephyrus的董事兼首席执行官的演讲中，卡尔文建议他们转向组织发展模式。

与变更集过程一样，他们正在创建的发布工件是相对于其生产组织的一组元数据变更。但是，在组织开发模型中，团队可以通过外部化所做的更改来获得重大的更改管理改进。他们可以使用Salesforce CLI从开发环境中提取元数据，以与版本控制系统（VCS）集成。

他们还可以使用Salesforce CLI编写日常任务的脚本，并提高贡献该版本的每个人的工作效率。卡尔文建议他们首先创建脚本以运行测试部署并运行Apex测试，这对他的董事和首席执行官很有意义。

得益于Calvin的业务驱动论点，他的董事和首席执行官批准了向组织开发的转变。为了表彰他对公司成功的贡献，Calvin被提升为业务分析师。此次晋升还使Calvin获得了跨部门管理发布所需的范围。

新优势和一些熟悉的主题

卡尔文（Calvin）和两个客户服务团队成员各自在具有单独开发环境的不同项目上工作。这三个项目都计划在同一发行版中进行。在组织开发过程中，他们会注意到一些熟悉的方面以及与变更集过程不同的地方。

就像他们在变更集开发中所做的一样，所有三个团队成员都将跟踪他们所做的变更。为什么？团队需要知道哪些组件发生了更改，他们是将这些组件添加到更改集中还是使用Salesforce CLI检索它们。此外，它们的某些自定义项无法部署到另一个组织，因为它们包含未在Metadata API中表示的已更改组件。此类更改必须在目标组织上手动重新创建，因此保持对它们的跟踪仍然很重要。

当团队成员完成各自的开发任务后，下一步就是将所做的更改移至构建环境进行集成。但是现在，他们使用Salesforce CLI从各自的开发环境中检索更改，而不是使用声明性工具创建更改集。他们将工作与VCS集成在一起，因此可以在VCS中提交和跟踪团队成员检索到的更改。

在VCS中提交和跟踪检索到的更改为团队提供了一个重要的好处。在使用变更集过程时，团队成员可以（有时确实）通过在先前的变更集上部署变更集来意外覆盖其他人的变更。通过使用向VCS提交更改的新过程，可以在更改被覆盖之前识别自定义冲突。

进入构建步骤，团队的自定义项已集成到源代码管理的项目中。这些更改将从VCS一起部署到构建环境中，以进行集成和测试。就像更改集过程一样，更改将在构建环境中一起进行测试。就像以前一样，结果是一个单一的发行工件，实际上是一组较大的合并变更。但是Calvin现在使用Salesforce CLI从构建环境中检索工件。并且随着组织开发过程的进行，发行工件不断从VCS转移到下一个环境。

尽管他们在组织开发过程中使用了其他工具，但基本的ALM步骤，变更集概念以及开发和测试环境是相同的。在新的开发模型下从事第一版工作的每个人至少都有一些熟悉的参考点。同样，加尔文很高兴使用Salesforce开发人员网站上的Trailhead和资源来发展他的技术技能和知识。

迁移到组织开发模型有助于使Zephyrus获得在整个公司范围内扩展使用Salesforce所需的控制权和效率。

学习目标

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

• 确定三个发行类别以及每个类别中进行的更改的种类。
• 描述一个变更集。
• 说明跟踪变更集发布的变更和依赖性的重要性。

在这个部门中，Calvin和他的同事开始应用ALM流程。在阅读时，请考虑为团队做出的选择。然后，完成本模块末尾列出的模块，以熟悉该过程，以便您确定适合自己的方法。

创建发布管理流程

Zephyrus团队将其定制实践调整为最佳实践ALM步骤。这个过程需要一点时间来适应，但是他们的努力是值得的。他们发现开发速度有所提高，而销售团队的中断却有所减少。这足以赢取团队，管理层对此感到高兴。

通过实施ALM周期，Zephyrus采用了基本的发布管理流程。但是，团队正在进行大型项目和小型项目，都处于ALM周期的不同步骤。为了帮助控制项目和期望，Calvin通过设置发布时间表和定义不同大小的发布标准来增加结构。

发布通常分为三类之一。补丁错误修复和简单更改。简单的更改包括报告，仪表板，列表视图和电子邮件模板。次要影响有限的更改，例如新的工作流程规则或触发影响单个业务流程的更改。这些发行版通常需要测试，但只需要有限的培训和变更管理。通常，团队会在几周内交付变更以进行次要发行。重大的具有重大影响的变更，包括具有一个或多个依赖性的变更。由于这些版本会极大地影响用户体验和数据质量，因此需要进行全面的测试，培训和仔细的变更管理。主要版本通常每季度交付一次（Salesforce一年交付3次）。

按一致的时间表发布。力求定期释放，并在一周的指定日期释放。例如，可能在每个月的第一个星期二东部时间晚上8点发布次要版本。计划一致性有助于整个公司范围内的计划，并为您的业务用户设定期望。还有一件事：尽量不要在假期或其他重大事件附近发布。

跟踪从生产到生产的一系列变更

在执行ALM步骤时，Zephyrus的团队将使用变更集开发模型。他们使用设置UI在开发环境中创建更改，并在完成ALM步骤时在环境之间迁移这些更改。

在变更集开发中，团队的发布工件是相对于生产组织中元数据的一组变更，例如diff或delta。发布的内容仅是已添加或更改的元数据-如果不更改，则不在发布中。

• 每个开发人员都会跟踪对其发行版的自定义所做的任何更改。跟踪工具可以是从电子表格到工作跟踪系统的任何东西。
• 某些更改的组件可能尚未在Metadata API中提供，因此必须在环境之间手动迁移。如果跟踪这些更改，您将不会忘记迁移它们。
• 作为发行经理，Calvin致力于发现发行版中的相关组件并将其包括在内。例如，如果目标组织中不存在其所属的自定义对象，则无法将新的自定义字段迁移到下一个环境。变更集工具可帮助Calvin识别这些依赖性。

注意

迁移配置文件和权限集可能很棘手。在继续之前，请查看有关部署和检索配置文件和权限集的特殊注意事项。

跟踪每个发行版中的更改都可以进行，但是如果保留您的书，则在正式发布时会顺利进行。

现在都在一起了！

您的发行版可以包含多个项目，并且每个项目都可以在单独的环境中进行开发和测试。但是在构建步骤之前，您需要将所有更改从每个项目迁移到同一环境中以进行集成。从那时起，您在发行版中的更改和自定义将作为单个集成变更集一起行进，即将投入生产。在构建之后的测试发布步骤中，您将一起测试所有更改。

作为发行经理，Calvin跟踪所有发行贡献者的变更。他还跟踪生产中尚未在开发和测试环境中反映的任何更改。为什么？这是他们成功部署自定义项而不会无意间覆盖生产组织中的更改的唯一方法。

学习目标

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

• 确定三个发行类别以及每个类别中进行的更改的种类。
• 描述一个变更集。
• 说明跟踪变更集发布的变更和依赖性的重要性。

在这个部门中，Calvin和他的同事开始应用ALM流程。在阅读时，请考虑为团队做出的选择。然后，完成本模块末尾列出的模块，以熟悉该过程，以便您确定适合自己的方法。

创建发布管理流程

Zephyrus团队将其定制实践调整为最佳实践ALM步骤。这个过程需要一点时间来适应，但是他们的努力是值得的。他们发现开发速度有所提高，而销售团队的中断却有所减少。这足以赢取团队，管理层对此感到高兴。

通过实施ALM周期，Zephyrus采用了基本的发布管理流程。但是，团队正在进行大型项目和小型项目，都处于ALM周期的不同步骤。为了帮助控制项目和期望，Calvin通过设置发布时间表和定义不同大小的发布标准来增加结构。

发布通常分为三类之一。补丁错误修复和简单更改。简单的更改包括报告，仪表板，列表视图和电子邮件模板。次要影响有限的更改，例如新的工作流程规则或触发影响单个业务流程的更改。这些发行版通常需要测试，但只需要有限的培训和变更管理。通常，团队会在几周内交付变更以进行次要发行。重大的具有重大影响的变更，包括具有一个或多个依赖性的变更。由于这些版本会极大地影响用户体验和数据质量，因此需要进行全面的测试，培训和仔细的变更管理。主要版本通常每季度交付一次（Salesforce一年交付3次）。

按一致的时间表发布。力求定期释放，并在一周的指定日期释放。例如，可能在每个月的第一个星期二东部时间晚上8点发布次要版本。计划一致性有助于整个公司范围内的计划，并为您的业务用户设定期望。还有一件事：尽量不要在假期或其他重大事件附近发布。

跟踪从生产到生产的一系列变更

在执行ALM步骤时，Zephyrus的团队将使用变更集开发模型。他们使用设置UI在开发环境中创建更改，并在完成ALM步骤时在环境之间迁移这些更改。

在变更集开发中，团队的发布工件是相对于生产组织中元数据的一组变更，例如diff或delta。发布的内容仅是已添加或更改的元数据-如果不更改，则不在发布中。

• 每个开发人员都会跟踪对其发行版的自定义所做的任何更改。跟踪工具可以是从电子表格到工作跟踪系统的任何东西。
• 某些更改的组件可能尚未在Metadata API中提供，因此必须在环境之间手动迁移。如果跟踪这些更改，您将不会忘记迁移它们。
• 作为发行经理，Calvin致力于发现发行版中的相关组件并将其包括在内。例如，如果目标组织中不存在其所属的自定义对象，则无法将新的自定义字段迁移到下一个环境。变更集工具可帮助Calvin识别这些依赖性。

注意

迁移配置文件和权限集可能很棘手。在继续之前，请查看有关部署和检索配置文件和权限集的特殊注意事项。

跟踪每个发行版中的更改都可以进行，但是如果保留您的书，则在正式发布时会顺利进行。

现在都在一起了！

您的发行版可以包含多个项目，并且每个项目都可以在单独的环境中进行开发和测试。但是在构建步骤之前，您需要将所有更改从每个项目迁移到同一环境中以进行集成。从那时起，您在发行版中的更改和自定义将作为单个集成变更集一起行进，即将投入生产。在构建之后的测试发布步骤中，您将一起测试所有更改。

作为发行经理，Calvin跟踪所有发行贡献者的变更。他还跟踪生产中尚未在开发和测试环境中反映的任何更改。为什么？这是他们成功部署自定义项而不会无意间覆盖生产组织中的更改的唯一方法。

学习目标

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

• 确定可以直接在生产组织中安全进行的自定义。
• 定义应用程序生命周期管理。
• 解释为什么使用应用程序生命周期管理流程可以帮助团队更快地开发应用程序。

介绍

Salesforce提供了各种开发工具和流程来满足客户的需求。本模块介绍了应用程序生命周期管理（ALM）流程和三种开发模型。

• 变更集开发
• 组织发展
• 包装开发

在较高级别上，所有三个开发模型都遵循相同的ALM流程。但是，这些模型的不同之处在于，它们允许您管理组织的更改。控制变更在软件开发中很重要，如果您了解自己的选择，则可以选择最适合您情况的开发模型。

让我们跟随Salesforce专业人员及其公司的发展历程，因为他们的发展挑战会随着时间而变化。在整个故事过程中，您将学习每种开发模型如何满足不同情况的需求。本教程的其他模块中涵盖了有关如何使用开发模型的详细信息。

注意

在类似的情况下，您和您的团队可能做出的选择与该模块中虚构的公司所做的选择不同。重要的是要了解您的选择。

与Zephyrus Relocation Services，Inc.的Salesforce管理员Calvin会面。

卡尔文·格林（Calvin Green）为弗吉尼亚州费尔法克斯的人才流动公司Zephyrus Relocation Services担任许多技术职务。卡尔文（Calvin）的职责之一是为公司规模虽小但不断壮大的销售团队定制Salesforce。使用生产组织中的Setup界面，他淘汰了各种令人印象深刻的新仪表板和报告。

卡尔文（Calvin）通过Vetforce开发了他作为Salesforce管理员的技能，该软件是针对军事服务人员，退伍军人和配偶的Salesforce工作培训和职业加速器计划。

什么是安全的生产变更？

您可以在生产组织中安全地开发某些新功能。在生产组织中可以安全地创建不影响数据的自定义设置，例如开发新的仪表板，报告和电子邮件模板。但是，某些直接在生产中进行的自定义设置可能会因删除数据而造成混乱，甚至更糟。

如果在将变更投入生产之前不测试变更，会发生什么？

• 工作流规则意外地创建了无限的处理循环。
• 字段类型的更改会以您无法撤消的方式修改数据。
• 验证规则中的逻辑错误会阻止您保存记录。
• 页面布局的更改会使人们感到困惑，而不是改善他们的体验。

定制组织的最安全方法是使用专用的开发环境进行和测试更改。实际上，必须在开发环境中进行一些更改。例如，您不能直接在生产组织中编写Apex代码。

移动到变更集以进行更安全的自定义

随着Zephyrus的不断增长，对Salesforce定制的需求也随之增长。该公司增加了另一名员工来提供帮助。越来越多的定制请求包括新的工作流程规则和页面布局，而Calvin明智地拒绝直接在生产组织中进行这些更改。

为了满足不断变化的业务需求，Zephyrus决定升级到专业版。在专业版中，Zephyrus可以在单独的开发环境中使用声明式（单击）开发工具来创建和测试其需求。

在变更集开发模型中，Calvin和他的同事Ella可以使用声明性工具来管理其应用程序。他们不需要使用命令行界面或版本控制系统来满足他们所支持的销售团队不断增长的定制需求。

借助声明性工具，Calvin和Ella可以创建许多精美的东西来提高销售团队的生产力。例如，加尔文使用Lightning App Builder创建一个过滤器，当金额至少为100万美元时，该过滤器会在机会页面上显示富文本格式的组件。

对混沌施加一点命令

现在，自定义是由多个人在多个环境中进行的，Calvin考虑了如何管理即使是很小的更改对下游的影响。

例如，“联系人”标准对象没有“联系人类型”字段。卡尔文（Calvin）可以轻松添加该自定义字段，并立即向所有用户发布新的联系人类型字段。但是他应该吗？

• 新的“联系人类型”字段是否与其他人的自定义冲突？
• 销售团队是否知道如何使用新领域或需要培训？
• 如果需要该字段，是否需要更新任何集成或导入过程？
• 该字段出现在哪里？在所有页面布局上？哪些列表视图？它会显示在任何报告或仪表板中吗？
• 该字段也应该位于Lead对象上吗？如果是这样，潜在客户转换流程会改变吗？
• 与其他系统集成是否需要该字段？如果是这样，您可能需要更改中间件，字段映射，端点等。

在Salesforce Trailblazer社区中，其他成员鼓励Calvin研究Salesforce建议的应用程序生命周期管理步骤，以开发新的和自定义的应用程序。

在Salesforce开发人员网站上，卡尔文了解到ALM定义了从设计到最终发布的管理应用程序开发的过程。ALM还建立了一个框架，用于随着时间的推移进行应用程序错误修复和功能增强。

等等，这不会增加流程速度吗？

在与IT部门主管ErnestoRondán的一次会议上，Calvin主张转向应用程序生命周期管理。ALM为他们提供了流程和策略，可帮助他们平稳且因此更快地构建应用程序，而不会造成麻烦。应用程序和工具可能会有所不同，但是ALM周期中的步骤适用于任何Salesforce开发项目。

• 步骤1：计划发布从计划开始定制或开发项目。收集需求并进行分析。让您的产品经理（或等效人员）创建设计规范，并与开发团队共享以执行。确定项目在ALM周期中进行时团队需要的各种开发和测试环境。
• 步骤2：开发按照设计规范完成工作。在包含生产组织的元数据副本但没有生产数据的环境中执行工作。使用说明性工具（Process Builder，Custom Object向导以及UI中的其他工具）和编程工具（开发人员控制台，源代码编辑器或Visual Studio Code）的适当组合在Lightning Platform上进行开发。
• 步骤3：测试在将其与其他人的工作集成之前，请练习您所做的更改以检查它们是否按预期工作。在与开发步骤中使用的环境类型相同的环境中进行测试，但将开发环境与集成测试环境分开。在这一点上，着重于自己测试更改，而不是了解更改如何影响发行版或整个应用程序的其他部分。
• 步骤4：内部版本将您在开发阶段创建或修改的所有资产聚合到一个发布工件中：一个逻辑定制包，您将其部署到生产中。从这一点开始，专注于您要发布的内容，而不是个人的贡献。
• 步骤5：测试发布测试您实际要部署的内容，但在尽可能模拟生产的临时环境中进行安全测试。使用大量实际的代表性生产数据。将您的测试环境与模拟生产系统集成点所需的所有外部系统连接起来。在此步骤中运行完整的回归和最终性能测试。与一小组提供反馈的有经验的人一起测试发行版（一种称为用户接受测试的技术）。
• 步骤6：放行完成测试并达到质量基准后，可以将定制部署到生产中。培训您的员工和合作伙伴，使他们了解变化。如果发行版对用户有重大影响，请创建一个包含实际数据的单独环境以培训用户。