学习目标
完成本单元后，您将能够：
- 确定包开发和变更集开发之间的主要区别。
- 描述什么是软件包版本，以及它如何帮助您管理组织中的更改。
- 总结一下为什么在使用软件包开发模型时不必手动跟踪安装程序更改。
本单元描述了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。
每个包裹都有自己的比赛
在软件包开发中，您可以为每个软件包维护单独的发布计划。您使用包来分割组织元数据的所有权，因此每个项目都有其自己的包以及任何相关包。您可以通过每个后续软件包版本独立管理各个段的升级，从而可以维护单独的发布计划。
什么是包依赖关系？元数据组件一次只能位于一个包中。如果多个软件包需要相同的组件，则可以为该组件设计模块化的软件包策略。包含多个程序包共享的一个或多个元数据组件的程序包是程序包依赖项。
每个程序包（以及任何程序包依赖项）都可以与组织中的所有其他元数据隔离地进行测试。将这样的元数据隔离到程序包中，可以灵活地分别对这些元数据集（程序包）进行版本控制。这也使您可以灵活地独立发布软件包。