Salesforce 发布火车：发布管理的实用方法

顾名思义，发布管理是通过不同阶段和环境管理、计划、调度和控制软件构建的过程； 包括测试和部署软件版本（Humble & Farley，2011）。

它本身就是一个相当大的话题，只有通过与开发团队尝试不同的迭代并匹配业务需求或功能发布，才能随着时间的推移而完善。 我们将尝试涵盖用于管理组织发布列车的元数据管理、CI 构建和沙盒管理的行业实践。

但什么是发布火车？

发布列车是一种增量且可预测的功能交付技术。 它要求开发人员建立一个正式的流程来接受在开发环境中所做的任何更改并将它们部署到生产环境中。

发布火车大致可以分为三个部分：

• 元数据管理
• 持续集成构建
• 沙盒管理

元数据管理

元数据是提供有关其他数据的信息的数据。 Salesforce 通过其元数据 API提供丰富而强大的元数据模型。 您的应用程序元数据描述并包含一组方法，这些方法提供对您组织的源代码和配置的编程访问。

元数据 API 是在 Salesforce 中管理自定义的最佳方式。 它支持create 、 read 、 update和delete方法。 您可以使用变更集、Force.com IDE 和 Ant 迁移工具将元数据从一个组织迁移到另一个，因为它们都通过 API 提供迁移。

每种工具都有自己的优势，选择一种时需要考虑以下几点：

表 1：元数据迁移工具比较

在 Force.com 平台上开发和迁移更改时，元数据 API 非常适合其用途。 但有一个小问题 - 并非所有 Salesforce 元数据都受元数据 API 支持。 官方文档提供了不支持的组件列表。

如果您的组织正在进行元数据 API 不支持的更改，您必须确保在目标组织中手动复制这些更改。 跟踪这些更改的最佳方法是使用电子表格。 如果您必须采用这种方法，则始终建议一个人进行这些更改并进行跟踪。

这将是一个很好的通用列列表，可用于跟踪电子表格中的这些更改：

• 组件名称
• 组件类型
• 更改所有者
• 功能描述
• 能力映射
• 与其他组件的依赖关系
• 审稿人/审稿人姓名
• 网址
• 组织名称/ID
• 其他的建议

版本控制和持续集成

将更改迁移到生产应该是一个平稳的过程，因为它只是在测试和暂存环境中应用更改的重复。 尽管如此，事情总是有可能向南发展，然后你需要一个后备计划。 保留组织元数据的备份非常重要，这就是版本控制和CI 构建的目的。

版本控制对于任何组织都是绝对必要的。 它允许开发人员以协作、高效和安全的方式工作。 管理多开发人员、多沙箱代码开发和迁移是 Salesforce 的一项挑战。 Salesforce 也有自己的发布和维护时间表。 这些更新提供了新功能，但它们可能会在元数据 API 中引入更改，这可能会破坏您的 CI 构建。 因此，除了开发人员相互覆盖更改的情况外，版本控制还可以帮助您构建回滚策略。 当您的应用程序在 Force.com 上运行时，必须有一个回滚策略。

以下流程图描述了版本控制和 CI 的实用结构。 我们将尝试为您简要介绍该图表所代表的内容。

1. 开发人员将检查他们在版本控制系统中的更改。
2. CI Server/Jenkins 会将最新的构建部署到 CI 沙箱并运行测试类。
3. 如果步骤 2 中的部署成功，则将更改合并到 QA 分支中。
4. 然后 CI 会将来自 QA 分支的最新提交部署到 QA 沙箱。
5. 如果 QA 因测试失败而拒绝更改，则应再次执行步骤 1 到 3，直到 QA 清除更改。
6. 在更改通过 QA 测试后，更改将合并到 Master 分支中。
7. 来自 Master 分支的最新更改将部署到 Master 沙箱。

可以根据组织的需要选择添加更多分支机构。 但上述结构适用于中型到企业级开发结构。

沙盒管理

要充分利用组织的 DevOps 流程，设置沙盒结构非常重要。 在深入探讨之前，让我们讨论一下 Salesforce 为我们提供的不同类型的沙盒。

沙盒几乎是一个生产元数据的精确副本。 沙盒通常用于开发、测试、登台和培训目的。 沙箱有四种类型，在选择沙箱时应适当考虑。 完整副本沙箱可能会花费很多钱！

下表列出了 Salesforce 对不同沙盒实施的限制。

表 2：限制比较

我们可以看到，价格并不是沙盒之间的唯一区别。

开发者沙箱有一天的刷新周期，适合开发，但只能容纳200MB的数据，没有生产数据。 相反，完整副本沙箱具有生产数据的精确副本； 甚至记录ID都相同。 这可能使其非常适合测试和登台，但 29 天的刷新期使得在完整副本沙箱中获取最新的生产元数据和数据变得困难。

下表作为选择沙箱的经验法则：

表 3：沙盒选择用例

以下是中型项目采用的典型组织结构。 对于企业级客户，组织结构变得更加复杂，但大致遵循以下模型。

Salesforce 开发通常在开发人员沙箱（红色）中完成，并且更改被移动到集成沙箱（绿色），该沙箱通常是开发人员专业版或部分复制沙箱。 然后，来自多个集成沙箱的更改被向上移动到汇总沙箱（黄色），该沙箱应该是部分复制沙箱。

如果您的组织与需要执行集成测试和负载测试的第三方系统有任何集成，则需要有一组稳定的数据，不会因发布而改变。 所以，最好有一个完整的副本或部分副本沙箱。

然后将这些更改移至执行测试的集成测试沙箱。 然后将更改移动到暂存沙箱，它应该是一个完整的复制沙箱。 所有测试类都在部署之前运行。 应执行部署验证以确保部署顺利进行。

这个过程帮助我们确保更改通过多轮测试和多对眼睛。 它有一个严重的缺点，即需要大量时间来开发、测试和部署更改。

很多时候，迫切需要执行错误修复或补丁。 为了快速处理这些问题，应该保留一个开发人员沙箱，它将小补丁直接推送到汇总沙箱。

如前所述，沙盒几乎是生产元数据的精确复制品，但并不完全。 有一个在沙盒中禁用的组件/功能的官方列表。

刷新沙箱时要考虑的另一件事是它只复制生产元数据和数据。 无法将元数据从一个沙箱复制到另一个沙箱，甚至无法在没有任何元数据配置的情况下创建一个空沙箱（例如免费的开发人员组织）。 这有时会成为现实生活中的挑战。 Salesforce 已计划解决此问题，并且此功能可能很快就会普遍可用。

此外，如果您在生产中有一些敏感数据，您认为您的开发或测试团队不应该访问这些数据，您可以为完全和部分复制的沙箱创建沙箱模板。

部署时要考虑什么

我们已经介绍了 Salesforce 生态系统中应用程序生命周期管理的行业实践。 元数据和沙盒管理在创建部署包和有效负载方面发挥着非常重要的作用。 对于大型和复杂的 Salesforce 应用程序，版本控制有助于确保跟踪元数据更改，同时还有助于创建回滚策略。

沙盒管理对于大型或复杂项目至关重要。 但沙盒在 Salesforce 生态系统中的成本很高，无论是在财务资源还是时间方面。 制定沙盒管理策略对于发布管理过程始终至关重要。

我们将为您留下一些额外的要点，在您下次部署时请牢记：

1. 一次只能部署 10,000 个文件或 39 MB 的 ZIP 文件。 当然，如果有效负载太大，您必须将包分成多个部分，然后进行部署。
2. 如果由于request timeout错误而导致部署失败，请尝试从包中删除对象、自定义字段和配置文件。 这些组件需要更长的时间来部署。
3. 如果更改了字段类型，或者角色层次结构发生了变化，那么由于数据重新计算可能会出现很长的延迟，需要一些时间才能完成。
4. Salesforce 会锁定系统中用户当前正在使用的任何组件。 如果我们在这种情况下尝试部署，部署将失败。

希望此概述将在您的下一个 Salesforce 版本中对您有所帮助。

来源