学习目标
完成本单元后，您将能够：
- 确定三个发行类别以及每个类别中进行的更改的种类。
- 描述一个变更集。
- 说明跟踪变更集发布的变更和依赖性的重要性。
在这个部门中，Calvin和他的同事开始应用ALM流程。在阅读时，请考虑为团队做出的选择。然后，完成本模块末尾列出的模块，以熟悉该过程，以便您确定适合自己的方法。
创建发布管理流程
Zephyrus团队将其定制实践调整为最佳实践ALM步骤。这个过程需要一点时间来适应，但是他们的努力是值得的。他们发现开发速度有所提高，而销售团队的中断却有所减少。这足以赢取团队，管理层对此感到高兴。
通过实施ALM周期，Zephyrus采用了基本的发布管理流程。但是，团队正在进行大型项目和小型项目，都处于ALM周期的不同步骤。为了帮助控制项目和期望，Calvin通过设置发布时间表和定义不同大小的发布标准来增加结构。
发布通常分为三类之一。补丁错误修复和简单更改。简单的更改包括报告，仪表板，列表视图和电子邮件模板。次要影响有限的更改，例如新的工作流程规则或触发影响单个业务流程的更改。这些发行版通常需要测试，但只需要有限的培训和变更管理。通常，团队会在几周内交付变更以进行次要发行。重大的具有重大影响的变更，包括具有一个或多个依赖性的变更。由于这些版本会极大地影响用户体验和数据质量，因此需要进行全面的测试，培训和仔细的变更管理。主要版本通常每季度交付一次（Salesforce一年交付3次）。
按一致的时间表发布。力求定期释放，并在一周的指定日期释放。例如，可能在每个月的第一个星期二东部时间晚上8点发布次要版本。计划一致性有助于整个公司范围内的计划，并为您的业务用户设定期望。还有一件事：尽量不要在假期或其他重大事件附近发布。
跟踪从生产到生产的一系列变更
在执行ALM步骤时，Zephyrus的团队将使用变更集开发模型。他们使用设置UI在开发环境中创建更改，并在完成ALM步骤时在环境之间迁移这些更改。
在变更集开发中，团队的发布工件是相对于生产组织中元数据的一组变更，例如diff或delta。发布的内容仅是已添加或更改的元数据-如果不更改，则不在发布中。
- 每个开发人员都会跟踪对其发行版的自定义所做的任何更改。跟踪工具可以是从电子表格到工作跟踪系统的任何东西。
- 某些更改的组件可能尚未在Metadata API中提供，因此必须在环境之间手动迁移。如果跟踪这些更改，您将不会忘记迁移它们。
- 作为发行经理，Calvin致力于发现发行版中的相关组件并将其包括在内。例如，如果目标组织中不存在其所属的自定义对象，则无法将新的自定义字段迁移到下一个环境。变更集工具可帮助Calvin识别这些依赖性。
注意
迁移配置文件和权限集可能很棘手。在继续之前，请查看有关部署和检索配置文件和权限集的特殊注意事项。
跟踪每个发行版中的更改都可以进行，但是如果保留您的书，则在正式发布时会顺利进行。
现在都在一起了！
您的发行版可以包含多个项目，并且每个项目都可以在单独的环境中进行开发和测试。但是在构建步骤之前，您需要将所有更改从每个项目迁移到同一环境中以进行集成。从那时起，您在发行版中的更改和自定义将作为单个集成变更集一起行进，即将投入生产。在构建之后的测试发布步骤中，您将一起测试所有更改。
作为发行经理，Calvin跟踪所有发行贡献者的变更。他还跟踪生产中尚未在开发和测试环境中反映的任何更改。为什么？这是他们成功部署自定义项而不会无意间覆盖生产组织中的更改的唯一方法。