发布管理, 顾名思义, 是管理的过程吗, 规划, scheduling and controlling a software build through different stages and environments; including testing and deploying software releases (Humble & 法利,2011).

它本身是一个相当大的主题，并且只能通过与开发团队一起尝试不同的迭代以及匹配业务需求或功能版本来完善. 我们将尝试介绍元数据管理的行业实践, CI构建, 沙盒管理用于管理组织的 释放的火车.

但是什么是释放列车?

发布序列是一种增量的、可预测的特性交付技术. 它要求开发人员建立一个正式的流程来处理开发环境中的任何更改，并将其部署到生产环境中.

一个发布序列可以大致分为三个部分:

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

元数据管理

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

的 元数据API 在Salesforce中管理自定义的最佳方式是什么. 它支持 创建, 读, 更新, 删除 方法. 你可以使用变更集，原力.com IDE, 以及蚂蚁迁移工具，将元数据从一个组织迁移到另一个组织, 因为它们都通过API提供迁移.

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

表1:元数据迁移的工具比较

 

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

如果您的组织正在进行元数据API不支持的更改, 您必须确保在目标组织中手动复制这些更改. 跟踪这些变化的最好方法是制作电子表格. 如果你不得不采取这种方法, 最好是由一个人来完成这些更改并对其进行跟踪.

这将是一个很好的通用列列表，人们可以使用它来跟踪电子表格中的这些变化:

• 组件名称
• 部件类型
• 改变所有者
• 功能描述
• 功能映射
• 与其他组件的依赖关系
• 审查/审稿人的名字
• URL
• 组织名称/标识
• 其他评论

版本控制和持续集成

将更改迁移到生产环境应该是一个顺利的过程, 因为它只是在测试和登台环境中应用更改的重复. 尽管如此，事情总是有可能变糟，然后你需要一个后备计划. 保持组织元数据的备份是非常重要的，这就是 版本控制 和 CI构建 是为.

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

下面的流程图描述了版本控制和持续集成的实用结构. 我们将试着给你一个简短的描述，这个图表代表了什么.

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

您可以根据组织的需要选择添加更多分支. 但是上面的结构只适用于中级到企业级的开发结构.

沙箱管理

充分利用组织的DevOps流程, 设置沙盒结构非常重要. 在我们深入研究之前, 让我们来讨论一下Salesforce提供给我们的不同类型的沙箱.

沙盒几乎是生产元数据的精确副本. 沙盒通常用于开发、测试、准备和培训目的. 有四种类型的沙盒，在选择沙盒时应该给予适当的考虑. 完整复制沙盒可能会花费很多钱!

下表列出了Salesforce对不同沙箱的限制.

表2:极限比较

 

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

开发者沙箱有一天的刷新周期, 是什么让它适合开发, 但只能容纳200mb的数据, 没有生产数据. 作为两极的对立面, full copy sandboxes have an exact copy of the production data; even the record IDs are the same. 这对于测试和分级来说是非常好的, 但是29天的刷新周期使得在完整复制沙盒中获取最新的生产元数据和数据变得困难.

下表是选择沙盒的经验法则:

表3:沙盒选择的用例

 

下面是中型项目采用的典型组织结构. 企业级客户端, 组织结构变得更加复杂，但大体上遵循下面的模型.

Salesforce发展 通常是在开发人员沙盒(红色)中完成的，然后将更改移动到集成沙盒(绿色)，通常是开发人员专业人员或部分复制沙盒. 然后，来自多个集成沙箱的更改向上移动到滚动沙箱(黄色)，它应该是一个部分复制沙箱.

如果您的组织与第三方系统有任何集成，需要执行集成测试和负载测试, 我们需要有一组稳定的数据，不会在每个版本之间发生变化. 因此，最好为它设置一个完整副本或部分副本沙盒.

然后将这些更改移动到集成测试沙箱中，在那里执行测试. 然后将更改移动到暂存沙盒，它应该是一个完整复制沙盒. 所有的测试类都在部署之前运行. 应该执行部署验证，以确保部署没有任何问题.

这个过程帮助我们确保这些变化经过多轮测试和双眼睛. 它的一个严重缺点是需要大量的时间来开发、测试和部署更改.

通常情况下，迫切需要执行错误修复或补丁. 为了快速处理这些问题, 开发者应该保留一个开发者沙盒, 哪一种方法可以将小补丁直接推送到卷起的沙盒中.

如前所述, 沙盒几乎是生产元数据的精确副本, 但也不完全是. 有一个 官方名单 在沙盒中禁用的组件/特性.

刷新沙盒时要考虑的另一件事是，它只复制生产元数据和数据. 没有办法将元数据从一个沙箱复制到另一个沙箱, 或者甚至创建一个没有任何元数据配置的空沙箱(像免费的开发人员组织). 这在现实生活中有时会成为一个挑战. Salesforce计划解决这个问题 功能 可能很快就会普遍可用.

另外, 如果您在生产中有一些敏感数据, 您认为您的开发或测试团队不应该访问哪些内容, 你可以创建 沙箱模板 对于完全和部分复制的沙盒.

部署时要考虑什么

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

沙盒管理对于大型或复杂的项目是至关重要的. 但在Salesforce生态系统中，沙箱的成本很高, 无论是财力还是时间. 制定沙盒管理的策略对于发布管理过程总是至关重要的.

我们将给你留下一些额外的要点，这些要点在你下次部署时应该牢记在心:

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

希望这篇概述能在您的下一个Salesforce版本中对您有所帮助.

---

来源