部署最佳实践

为什么直接在生产中开发不是一个好主意

将更改直接部署到您的实时 Salesforce 生产环境通常不是一个好主意，因为它给您的业务和用户带来了巨大的风险。即使是很小的修改，也会产生意想不到的级联影响，扰乱您的系统。例如，更改字段的类型会不可逆地更改数据或导致 Apex 代码重新编译。一个未经测试的更新可能会破坏关键流程，扰乱您的数据，或者使您的团队或客户无法使用系统，从而导致在大家等待的时候争先恐后地解决问题。

当您开发或修改应用程序时，进行和测试更改的最安全的地方是在专门的开发环境中，例如 Sandbox 或临时组织。为了保护您的生产组织，必须在开发环境中进行一些更改，例如编写 Apex 代码。

具有多个测试阶段的强大的发布漏斗通过以下方式确保顺利部署到生产：

• 验证集成更改是否协同工作。
• 允许您实践部署以识别任何问题。
• 确保您在部署工件中包含您需要的一切。如果您错过了什么，当您测试它时会很明显。
• 为多个利益相关者提供在部分复制或完全 Sandbox 中测试更改的机会（用户验收测试）。

您可以直接在生产中进行哪些更改？

虽然通常不建议在生产组织中开发或修改应用程序，但一些管理任务完全可以直接在生产中执行。这些任务通常不涉及更改或构建应用程序本身，而是管理现有配置或用户访问。

例如，您可以安全地执行管理任务，例如：

• 开发电子邮件模板。
• 创建或编辑用户。
• 创建或编辑权限集和简档。

这些类型的操作很常见，可以直接在您的 Live 组织中执行。它们有助于保持平稳运行，而不会带来与更大的开发变化相关的风险。

拥抱变革管理和善治

保持健康稳定的生产环境对您的业务和客户至关重要。这需要基于治理和变更管理最佳实践的战略性部署方法，也称为应用程序生命周期管理 (ALM)。这些实践为变革建立了一个框架：定义引入变革的内容、时间和方式。这给了团队信心并提供可跟踪性，导致更顺利、更一致的部署。

以下是一些鼓励良好发展实践的建议治理规则。

• 最小化谁可以在生产中开发。将“自定义应用程序”访问权限限制为管理员。
• 将执行编程部署的权限限制为少量管理员。
• 请谨慎对待您在生产中通过设置所做的更改，并坚持执行管理任务。

对部署时间要有战略性

在 Salesforce 部署期间，对用户的影响从轻微的不便到完全中断不等，这取决于更改的类型和部署的时间。请确保在每个人积极使用系统时避开高峰时间。如果您的部署可能会导致 Apex 代码重新编译或导致 Apex 并发错误，这可能会大大降低应用程序性能，那么避免峰值时间尤其重要。

此外，避免在假期或重大事件前部署，以防止任何不必要的头痛或中断。相反，请尝试在大多数用户关闭系统时发布。

尝试遵守一致的发布时间表。例如，目标是在每周的指定日期定期发布。即使在 Salesforce 中，我们也计划定期发布暂停，以避免在关键时刻出现全系统中断。计划的一致性有助于公司范围的规划，并为您的业务用户和客户设定期望。

观察部署依赖性

在部署到 Salesforce 时，订购部署的简单方法可以显著简化流程，并帮助高效解决依赖性。在这里，我们提供了一些一般信息和指南。

备注 一些 Salesforce 功能和产品有自己的部署最佳实践特定信息。请确保在制定部署策略之前查看功能的产品文档。

推荐的顺序是，按以下顺序部署：

• 对象
• Apex 类
• Visualforce 组件和页面
• Lightning Web 组件 (LWC) 和 Aura 组件
• Apex 触发器和其他元数据
• 简档和权限集
• 共享规则

为避免在流程早期出现问题，请先部署对象。包括新的自定义对象、字段、记录类型和其他必要的元数据组件。此顺序对于紧凑布局和列表视图等组件尤其重要，因为它们直接依赖于对象。

对于简档和权限集，请确保预先部署所有相关元数据，因为简档充当总体层，将组织元数据中的多个依赖性联系在一起。

在部署窗口的末尾附近部署共享逻辑，因为它在记录级别操作。例如，部署包含共享规则的完整简档或权限集会在您每次尝试部署时触发计算，如果出现多次失败，这将非常耗时。由于共享重新计算过程，共享逻辑部署的时间至关重要。

此外,在组织中实施的任何更改，特别是对共享规则或小组设置的更改，或角色层次结构中的更改，都可能导致 Apex 代码重新编译，从而增加处理时间。