Salesforce发布训练（发布管理的实用方法） _发布管理

本文概述

元数据管理
版本控制和持续集成
沙箱管理
部署时应考虑的事项
资料来源

顾名思义, 发布管理是通过不同阶段和环境管理, 规划, 调度和控制软件构建的过程；包括测试和部署软件版本(Humble＆Farley, 2011年)。

它本身是一个很大的话题, 只有随着开发团队尝试不同的迭代并匹配业务需求或功能发布才能逐步完善。我们将尝试介绍元数据管理, 配置项构建和沙箱管理的行业实践, 以管理组织的发布训练。
但是什么是发行训练？
发布流程是一种增量且可预测的功能交付技术。它要求开发人员建立正式流程, 以对开发环境中进行的任何更改并将其部署到生产中。

文章图片
发布训练大致可分为三个部分：

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

元数据管理元数据是提供有关其他数据的信息的数据。 Salesforce通过其Metadata API提供了丰富而强大的元数据模型。你的应用程序元数据描述并包含了一组方法, 这些方法提供了对组织的源代码和配置的编程访问。
Metadata API是在Salesforce中管理自定义的最佳方法。它支持创建, 读取, 更新和删除方法。你可以使用变更集, Force.com IDE和Ant迁移工具将元数据从一个组织迁移到另一个组织, 因为它们都通过API提供迁移。
每种工具都有其自身的优势, 选择一种工具时需要考虑以下几点：
表1：元数据迁移的工具比较

变更集	Force.com IDE	蚂蚁迁移工具
变更集是通过标准Salesforce UI部署组件的方法。	Force.com IDE(Eclipse)主要用于Apex开发, 但可用于部署目的。	Ant Migration是一个功能强大的命令行工具, 专用于在环境之间迁移更改/元数据。
通常用于少量组件迁移。	开发人员通常使用IDE将更改迁移到测试或暂存环境。	蚂蚁迁移用于大型有效负载迁移, 并且需要具有Salesforce Metadata API的高级知识。
组织之间的连接必须手动建立, 因此不适用于自动部署。	它可以用于部署到任何组织, 但是需要一些容易出错的手动步骤。	自动部署可以非常容易地安排。
供管理员使用。	针对销售人员开发人员, 因为开发代码是其主要用途。	面向DevOps工程师。
添加依赖项非常简单且用户友好。	添加依赖项有点容易, 因为它提供了指向和单击的UI。	部署通常由于缺少依赖项而失败。
不允许进行破坏性更改。	确实允许使用破坏性的变更集, 但过程非常繁琐。	允许破坏性更改集。

在Force.com平台上开发和迁移更改时, 元数据API非常适合实现其目的。但是有一个小问题-Metadata API并不支持所有的Salesforce元数据。官方文档提供了不支持的组件的列表。
如果你的组织正在进行Metadata API不支持的更改, 则必须确保在目标组织中手动复制这些更改。跟踪这些更改的最佳方法是电子表格。如果你必须采用这种方法, 则始终建议一个人进行这些更改并进行跟踪。
这将是一个很好的常规列列表, 可用于跟踪电子表格中的这些更改：

组件名称
组件类型
变更拥有者
功能说明
能力映射
与其他组件的依赖
审阅者/审阅者姓名
网址
组织名称/ ID
其他的建议

版本控制和持续集成迁移生产变更应该是一个平稳的过程, 因为这只是在测试和登台环境中应用变更的重复。尽管如此, 总有可能出现问题, 然后你需要一个后备计划。保留组织元数据的备份非常重要, 这就是版本控制和CI构建的目的。
版本控制对于任何组织都是绝对必须的。它允许开发人员以协作, 高效和安全的方式工作。在Salesforce中, 管理多开发人员, 多沙盒代码的开发和迁移是一项挑战。 Salesforce还具有自己的发布和维护时间表。这些更新提供了新功能, 但是它们可能会在Metadata API中引入更改, 这可能会中断你的CI构建。因此, 除了开发人员覆盖彼此的更改的情况外, 版本控制还可以帮助你制定回滚策略。当你的应用程序在Force.com上运行时, 必须具有回滚策略。
以下流程图描述了版本控制和CI的实用结构。我们将尝试为你简要说明图表的含义。

开发人员将在版本控制系统中签入他们的更改。
CI Server / Jenkins会将最新的版本部署到CI沙箱并运行测试类。
如果步骤2中的部署成功, 则更改将合并到QA分支中。
然后, CI会将来自QA分支的最新提交部署到QA沙箱中。
如果QA由于测试失败而拒绝更改, 则应再次执行步骤1到3, 直到QA清除更改为止。
更改通过QA测试后, 更改将合并到Master分支中。
Master分支中的最新更改已部署到Master沙箱中。

文章图片
你可以根据组织的需要选择添加更多分支机构。但是, 上述结构对于中型到企业级的开发结构来说效果很好。
沙箱管理为了充分利用组织的DevOps流程, 设置沙盒结构非常重要。在深入研究之前, 让我们讨论Salesforce为我们提供的不同类型的沙箱。
沙盒几乎是一个人的生产元数据的副本。沙盒通常用于开发, 测试, 登台和训练目的。沙盒有四种类型, 一种在选择沙盒时应给予应有的考虑。完整副本沙箱可能会花费很多钱！
下表是Salesforce对不同沙箱强制实施的限制的表。
表2：限制比较

	开发者	开发人员专业版	部分复制	完整副本
生产数据	No	No	是	是
数据存储	200兆字节	1 GB	5GB(每个对象1万条记录)	完整资料
刷新期	1天	1天	5天	29天

我们可以看到, 价格并不是沙盒之间的唯一区别。
开发人员沙箱的更新时间为一日, 这使其适合于开发, 但只能容纳200 MB的数据, 而不能容纳生产数据。与之相反, 完整副本沙箱具有生产数据的精确副本；甚至记录ID也一样。这可能非常适合测试和登台, 但是29天的刷新期使其很难在完整副本沙箱中获取最新的生产元数据和数据。
下表是选择沙箱的经验法则：
表3：用于沙箱选择的用例

	开发者	开发人员专业版	部分复制	完整副本
发展历程	是	是	No	No
QA	是	是	是	No
整合测试	No	No	是	是
批处理数据测试	No	No	是	是
训练	No	No	是	是
UAT	No	No	是	是
负载测试	No	No	No	是
分期	No	No	No	是
用户训练	No	No	No	是

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

文章图片
Salesforce开发通常在开发人员沙箱(红色)中完成, 而更改将移至集成沙箱(绿色), 后者通常是开发人员专业版或部分副本沙箱。然后, 将来自多个集成沙箱的更改上移到应为部分副本沙箱的汇总沙箱(黄色)。
如果你的组织与需要进行集成测试和负载测试的第三方系统有任何集成, 则一个人需要拥有一组稳定的数据, 并且各个发行版之间都不会更改。因此, 最好有一个完整副本或部分副本沙箱。
然后, 将这些更改移到执行测试的集成测试沙箱中。然后将更改移到暂存沙箱, 该沙箱应该是完整副本沙箱。所有测试类都在部署之前运行。应该执行部署验证, 以确保进行部署时不会出现任何问题。
此过程可帮助我们确保更改经过多轮测试和双眼测试。缺点是需要大量时间来开发, 测试和部署更改。
通常, 迫切需要执行错误修复或补丁程序。为了快速处理这些问题, 应该保留一个开发人员沙箱, 该沙箱会将小的补丁直接推到汇总沙箱中。
如前所述, 沙盒几乎是生产元数据的精确副本, 但不是完全复制。沙盒中有禁用的组件/功能的正式列表。
刷新沙箱时要考虑的另一件事是, 它仅复制生产元数据和数据。无法将元数据从一个沙箱复制到另一个沙箱, 甚至无法创建没有任何元数据配置的空沙箱(例如免费的开发人员组织)。在现实生活中, 这有时会成为挑战。 Salesforce已计划解决此问题, 并且此功能可能很快就会普遍可用。
此外, 如果你在生产中有一些敏感数据, 而你觉得开发或测试团队无法访问这些数据, 则可以为完整和部分复制的沙箱创建沙箱模板。
部署时应考虑的事项我们已经介绍了Salesforce生态系统中应用程序生命周期管理的行业惯例。元数据和沙箱管理在创建部署程序包和有效负载中扮演着非常重要的角色。对于大型和复杂的Salesforce应用程序, 版本控制有助于确保跟踪元数据更改, 同时还有助于创建回滚策略。
沙箱管理对于大型或复杂项目至关重要。但是, 无论从财务资源还是时间上来说, 沙盒在Salesforce生态系统中都是昂贵的。制定沙箱管理策略对于发布管理流程始终至关重要。
【Salesforce发布训练（发布管理的实用方法）】我们会为你提供一些额外的要点, 以便你下次部署时牢记：