应用程序生命周期和开发模型- 使用软件包开发获得更灵活的版本

学习目标

完成本单元后,您将能够:

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

本单元描述了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跟踪所有发行贡献者的变更。他还跟踪生产中尚未在开发和测试环境中反映的任何更改。为什么?这是他们成功部署自定义项而不会无意间覆盖生产组织中的更改的唯一方法。