架构师的 Salesforce DevOps 指南（二）

原文：annas-archive.org/md5/6eb8e0881caa9511876ed36f7f355527

译者：飞龙

协议：CC BY-NC-SA 4.0

第九章：数据与元数据备份

在本章中，我们将探讨将数据和元数据备份作为全面 Salesforce DevOps 战略的一部分的关键重要性。我们将讨论组织面临的数据丢失和系统停机带来的巨大成本，包括生产力损失、收入损失和声誉损害。有效的备份可以通过快速恢复减少业务中断的影响。我们将探讨一些关键功能，如外部存储、自动化、集成、安全性和智能恢复功能，帮助您为 Salesforce 架构备份方案。

本章强调在备份中同时捕获元数据和数据，以充分保护业务连续性。将重点介绍元数据在保障数据安全、提供上下文、支持自动化以及维护配置中的不可或缺作用。类似地，我们将讨论如何在大规模备份 Salesforce 灵活数据模型时使用有效的技术。您将学会如何将备份工具集成到开发工作流中，以增加其价值，不仅限于保护功能，还能优化恢复过程。

我们将涵盖以下主要主题：

• 为何备份应成为 DevOps 流程的一部分：我们将首先探讨定期且准确备份在整体 DevOps 战略中所扮演的基础性角色。

• 元数据备份：在本节中，我们将讨论为何制定元数据架构的备份计划至关重要，而不仅仅是备份其中的数据。

• 数据备份：接下来，我们将讨论在数据备份时需要考虑的因素。

• 恢复过程：备份仅仅是挑战的一半——在本节中，我们将探讨从备份恢复时需要考虑的步骤和流程。

• 事件与灾难恢复计划：高效的数据恢复依赖于有效的规划，尤其是在出现问题时。本节将介绍在规划恢复方法时需要考虑的因素。

• 确保备份数据安全：您的备份需要与 Salesforce 实施的安全性一样高。因此，在本节中，我们将讨论如何加强备份的安全措施。

• 如何应对 GDPR 与 CCPA 数据备份法规：您备份的数据与您的工作数据一样，受相同的法律和法规约束。在本节中，我们将简要讨论可能适用于您数据备份的两个最常见法规——通用数据保护条例（GDPR）和加利福尼亚消费者隐私法案（CCPA）。

• 数据保留考虑事项：在本节中，我们将回顾可能影响您数据保留政策的因素，探讨您应保留备份数据的时长。

• Salesforce 备份选项：最后，在前述主题讨论完毕后，我们将探讨当前可用于有效 Salesforce 备份的选项。

到本章结束时，您将了解有效的数据和元数据备份在限制业务中断中的关键作用，并获得实用的见解，以评估和实施专为 Salesforce 平台定制的强大备份解决方案。

技术要求

本章没有技术要求，因为这里讨论的原则可以与市场上多种 Salesforce 备份解决方案一起使用。

为什么备份应该成为 DevOps 流程的一部分

Salesforce 常常作为许多组织的关键参与和运营系统。Salesforce 中的数据提供了客户的 360 度全景视图，并支持营销、销售和服务活动。因此，Salesforce 中的任何长时间停机或数据丢失都可能严重影响组织的业务运作。客户关系受损、创收活动停滞、生产力陷入停顿。

根据多项研究，大多数公司每小时的停机成本超过$300,000. 对于一些大型企业而言，这一小时的成本可能达到数百万美元。如果停机时间延长，几小时或几天的停机将造成巨大的财务和声誉损失。在最坏的情况下，缺乏足够的数据保护和恢复计划的公司可能会因为灾难性的数据丢失而完全退出市场。

然而，切实可行的集成数据备份为组织提供了快速恢复服务并限制中断的能力。与其永久丢失数据和生产力，公司可以从最近的备份中恢复并继续运营，在恢复过程中只有短暂的活动受限。先进的工具可以自动化备份过程，使恢复过程无缝衔接。

除了防止灾难发生外，完全将备份工具和流程纳入 DevOps 工具链还有其他好处。备份让开发人员更加有信心进行快速创新和实验，因为他们知道自己的工作是受到保护的。集成的备份还鼓励在开发、测试和生产过程中使用一致的流程和环境，以减少恢复时的混乱。

将备份视为 Salesforce DevOps 的核心元素可以减少潜在的业务中断，增强开发人员的能力，并确保组织的关键 Salesforce 数据得到充分保护。

数据丢失的成本

关键系统停机的平均每小时成本会根据组织规模、行业和受影响的具体系统有所不同。然而，研究表明，大型企业的平均停机成本每小时在$300,000 到$400,000 之间（来源：www.statista.com/statistics/753938/worldwide-enterprise-server-hourly-downtime-cost/）。对于中小型企业，每小时停机成本通常在$10,000 到$23,000 之间。

这些数字代表的是平均值，但对于与收入密切相关的系统或受严格监管的行业，实际成本可能会更高。导致停机成本的几个关键因素包括：

• 生产力和收入损失：员工无法工作，收入生成停滞

• 客户不满：停机侵蚀客户信任、满意度和忠诚度

• 恢复和修复成本：恢复系统和数据的过程会产生大量 IT 费用

• 违规罚款：医疗、金融及其他受监管行业会面临高额罚款

• 声誉损害：品牌声誉因长时间停机而受损，影响未来业务

鉴于关键系统停机可能带来的巨大潜在成本，业务连续性规划对于最小化影响至关重要。诸如冗余系统、全面的灾难恢复计划、定期备份、测试、监控和维护等策略有助于降低停机成本。投资于业务连续性帮助组织在停机期间维持运营和客户服务。

备份有助于减少中断

尽管数据丢失和系统停机无法完全避免，但可行的数据备份为组织提供了快速恢复服务并限制中断的能力。与其永久丢失数据并遭受长期的生产力损失，企业可以从最近的备份中恢复，并在恢复过程中经历短暂的受限活动后恢复运营。

在适当的备份系统到位的情况下，组织可以将恢复时间目标（RTO）缩短至仅几个小时或几分钟，尤其是像 Salesforce 这样的关键系统。例如，针对 Salesforce 平台优化的先进备份工具使管理员在许多情况下能够在不到一小时的时间内恢复到停机前的状态。

精心设计的备份解决方案集成了一系列关键功能，可以在停机后实现快速而安全的恢复，同时无缝集成到日常开发工作流中。

例如，外部基于云的备份存储对于确保在主系统完全瘫痪时仍能访问数据副本至关重要。通过将备份存储在与实时数据不同的位置，企业能够防止灾难同时影响两个系统。配置自动化的定期备份，无论是按日还是按日内计划执行，都能通过持续捕获时点快照来提供持续保护，无需人工监督，从而避免可能的备份漏洞。

专注于与现代开发实践对齐的备份解决方案，允许在有风险的发布事件前触发按需备份，在出现问题时提供一个故障恢复点。高级分析有助于通过检测备份中的异常数据变化来识别潜在的损坏或丢失，从而进行调查。

与现有开发工具、环境和工作流的集成，利用熟悉的界面简化了恢复过程。这减少了事故发生时的困惑，加速了恢复进程。经过成千上万次实际恢复优化的强大恢复引擎确保能够快速重建故障前的配置。

企业级安全性，包括访问控制和对静态数据及传输数据的强加密，对于保护高度敏感的备份副本至关重要。通过引入这些复杂的功能，备份解决方案可以在确保可靠保护的同时，增强开发成果。

通过将具备这些功能的解决方案融入常规运营，团队可以快速诊断问题，迅速恢复服务，并将数据丢失或系统故障带来的业务中断限制在最短的恢复窗口内。整体成本和声誉损害都被控制在从可行备份恢复所需的短暂恢复时间内。

备份与开发相辅相成

将备份工具和程序完全融入开发生命周期和 DevOps 工具链中，带来的好处远远超出了灾难恢复的准备。当备份被视为开发过程的一个重要组成部分而非事后的补救措施时，它能增强开发者的敏捷性，提升测试效率，并加快发布周期。

对于开发者而言，可靠的备份提供了一个安全网，使得创新速度和自由度得以提高。开发者不再因担心不良后果而小心翼翼地限制变更，而是可以快速实现新特性和演进系统架构，因为他们知道如果出现问题，可以回滚到备份快照。备份让开发者从谨慎地修改系统转变为大胆推动系统发展。

备份还促进了创建更真实和可复现的测试和暂存环境。捕获数据和配置细节可以让你刷新沙箱环境，使其更接近生产环境。这有助于更精确的测试和培训模拟。备份数据还可以用来生成经过脱敏的测试数据集，用于开发和质量保证测试，同时不影响安全性。

在日常开发操作中，集成备份提供了额外的优势。异常检测算法帮助在编码周期早期识别数据问题，从而快速修复。与持续集成/持续交付（CI/CD）管道的流畅集成使得备份能够在每次新的构建时轻松捕获，以便在管道变更产生意外影响时，进行后续恢复。

对于那些由数据（而非元数据）决定业务逻辑的应用程序（如 Salesforce CPQ），开发人员在部署后能快速回滚的能力，可能比在每次更改前进行大量端到端的自动化测试更有效。

对于在空白组织上构建的开发人员，恢复功能通过在必要时恢复到之前已知的良好状态，保持他们的生产力，尤其是在进行激进的定制化实验后。包括代码、配置和依赖项的全面备份有助于开发人员进行故障排除和调试。

对于管理员和发布经理来说，在部署前进行按需备份，如果新的变更或升级导致生产环境出现问题，可以提供即时的回滚点。这个安全网使得持续交付（CD）能够以较低的风险进行。发布经理可以在知道可以回滚的情况下，放心地持续改进系统。

通过促进开发人员的自由、增强测试和加速发布周期，集成备份提高了业务敏捷性，并缩短了新创新的上市时间。将备份视为开发和运维的补充过程，而不仅仅是灾难恢复工具，能在现代 DevOps 实践中放大其价值。

备份保护免受错误影响

即使是最谨慎的管理员和开发人员，也难免会犯一些影响数据完整性的错误。尽管出于最好的意图，偶然的配置变更或无意间的代码部署总会发生。更令人担忧的是，受损用户的恶意行为也对组织构成威胁。当发生人为错误或故意篡改时，可靠的备份作为快速恢复的最后防线。

在开发方面，即使是经过广泛测试的代码变更，在部署到生产环境后，仍可能会产生无法预见的下游影响，影响数据的准确性或可用性。备份可以帮助快速回滚代码更改，以恢复系统稳定性和数据可靠性。通过比较部署前后的备份，可以正确诊断与代码相关的事件并找出根本原因。

数据事故也可能发生，例如对错误数据集执行批量记录删除或修改。没有备份的情况下，丢失数据的重新输入可能需要数小时或数天，甚至可能根本无法恢复。如果原始数据丢失，数据保留政策可能还会要求长期备份某些数据集。通过定期的备份计划和存储，快速恢复信息可以最大限度地减少业务中断。

在内部安全威胁和恶意行为的情况下，备份可能是灾难性事件（如大规模数据删除）后的唯一恢复选项。尽管预防是理想的，但备份提供了一种应对最坏情况的保险政策。备份的法医分析还可以帮助调查安全漏洞的可疑活动。

2016 年的 NA14 故障和 2019 年的Permageddon权限问题等显著的 Salesforce 特定事件，Salesforce 需要重置集成了 Pardot 的团队的权限，以保护用户数据，最终要求管理员重建配置文件和权限，这些事件突显了即使依赖于主要云平台，仍然需要可行的备份。没有可访问的备份，公司可能会面临巨大的成本和中断。

最终，在管理像 Salesforce 这样的大型复杂系统时，必须考虑到人为错误和故意滥用作为现实情况。维护可行的备份、适当保护访问权限，并在变更上实施检查和警报，可以帮助组织快速撤销不可避免的错误或恶意行为的影响。拥有可靠的数据恢复能力可以为管理员和开发人员提供更大的日常安心。

备份验证发布

现代开发环境中变化的快速节奏意味着新的功能和升级不断发布给用户。尽管在发布前会进行广泛的测试，但预见所有用户如何与变更互动，在即使是大规模的测试环境中也是不可能的。因此，随着时间的推移，由于真实世界的使用与预测模式不同，无法预见的影响不可避免地发生。

为了在这个动态环境中实现增量改进的持续交付，开发团队需要一种快速诊断和解决新发布引入的问题的方法。通过在任何给定发布部署之前捕获一个已知的良好状态，备份提供了这种能力。如果用户在发布后遇到问题，管理员可以通过快速恢复到部署前的备份快照来确定根本原因是否源于该发布。

凭借备份回滚和基于备份进行根本原因分析的能力，开发团队在频繁发布变更时获得了信心。由于他们知道如果出现重大问题，可以回滚发布，因此对持续交付增量改进、新功能和升级的抵触心理较少。发布速度和创新加快。

在每次部署之前的按需备份还创建了可重复使用的发布测试环境。可以反复部署到从同一备份恢复的测试环境中，以精确验证所有更改。将按需备份自动化为 CI/CD 流水线的一部分进一步增强了发布验证。

对于用户而言，基于备份快速解决与发布相关的缺陷维护了他们的信心和满意度。当可以使用备份快速恢复到之前的稳定状态时，就无需等待漫长的调试和新的修补版本。开发流程的总体质量和响应能力得到提升。

可行的备份使开发团队能够加速创新，并确信可以管理持续交付的风险。在知道可以撤销任何负面影响的情况下，可以大胆进行发布更改。

元数据备份

在当今数字时代，数据通常被称为新黄金。然而，在 Salesforce 领域，如果数据被视为黄金，那么元数据可以被看作是展示如何提取、精炼和塑造这些有价值实体的复杂蓝图。这种比较突显了元数据在 Salesforce 复杂世界中的重要意义。

元数据不仅仅是信息的孤立层面；它是一个全面的配置、定义和自动化的马赛克，为数据注入生命。元数据决定了每个对象和字段的行为方式、它们之间的关系以及它们向用户展示的方式。它充当 Salesforce 组织的 DNA，控制着形式和功能。

解释和理解数据的能力与元数据所建立的上下文基础密不可分。设想一个情境，其中包含数百万条记录，但没有任何关于它们结构或相互关系的提示。这就像在没有盒子上图像的情况下尝试拼接一个复杂的十亿块拼图。数据，例如账户记录，只有与相关的元数据结合时，才能实现其最大潜在价值。这种结合确保了数据不仅仅是一些数字和字符的堆砌，而是一个连贯且具有影响力的编译体，推动决策和操作。从实际角度来看，这意味着数据恢复往往完全依赖于匹配的元数据状态。包含不存在字段值（如选择列表值）的记录可能会成为问题，存储在新增必要字段之前的记录也是如此。

此外，对于 Salesforce 管理员和开发人员来说，真正关心的并不仅仅是潜在的数据丢失本身，而是可能会丢失数月或数年的精心定制的配置。重建数百个自定义对象、重新定义成千上万的页面布局配置、重新校准复杂的用户权限、重新开发复杂的流程和触发器的前景是一个令人生畏的场景。如此大规模的重建意味着需要大量的时间、精力和资源，才能恢复到以前的业务流程自动化水平。在这种背景下，强大的元数据备份作为一个至关重要的安全网出现，确保能够迅速从中断中恢复。

我们无法过分强调元数据在保护组织数据安全和访问控制中的核心作用。虽然数据可能代表离散的记录，但正是元数据包含了规定哪些用户可以查看和修改这些记录的策略，以及如何查看和修改。元数据不仅仅决定了用户可以访问哪些原始数据，还调节了他们如何与数据互动及数据与其他数据组件之间的关系。在缺乏有效元数据备份的情况下，你可能拥有一堆宝贵的数据，但却缺乏适当的机制来安全地保护和控制对数据的访问。

此外，虽然静态数据提供了有形的历史记录，但正是元数据通过自动化将其推动到动态行动中。从简化日常任务（如线索分配）到协调跨部门的复杂多步骤流程，元数据在幕后默默运作，使 Salesforce 能够保持响应能力。编码在元数据中的规则、验证和触发器确保了数据的准确性和一致性。

在 Salesforce 庞大的框架内，数据和元数据是综合组织的元素，描绘出一个全面的画卷。尽管备份数据对于保留历史记录和洞察力至关重要，但这些数据的相关性、安全性和可操作性牢牢地根植在周围的元数据中。随着企业继续投入大量资源来定制 Salesforce 部署以满足其独特的需求，全面元数据备份策略的不可或缺性显而易见。一个真正强大的备份策略必须无缝整合数据和元数据，确保这两个基础元素都不会被忽视。

数据备份

虽然元数据在 Salesforce 中捕捉了结构蓝图和逻辑，组织也必须备份其数据以全面保护业务运营。数据包括用户在 Salesforce 中创建、更新和管理的实际记录和内容，作为其日常工作的一部分。这包括账户、联系人、潜在客户、机会、案例和自定义对象。

Salesforce 中的数据通常代表核心客户信息、销售交易、服务问题历史记录和其他运营数据集。丢失对当前生产数据的访问可能使运营倒退数月或数年，具体取决于数据量。

然而，在 Salesforce 内进行大规模数据备份引入了独特的挑战。灵活的数据模型，结合涵盖数百个对象和大量数据量的复杂关系，需要备份技术和工具专门为 Salesforce 优化。

例如，Salesforce 的声明性、可配置的架构允许创建业务域的相互链接的多对象数据图。一个账户记录可以在联系人、机会、案例和其他对象中拥有数百个相关的子记录。为 Salesforce 设计的备份解决方案可以在捕获和恢复数据时保留这些复杂的对象关系网。

数据的数量也要求优化备份性能和精细恢复能力。Salesforce 生产实例通常包含数千亿条记录的数 TB 数据。必须高效执行完整数据备份和还原，以适应有限的维护窗口。精细恢复功能帮助通过仅恢复被意外修改的选择记录或字段来应用手术性更改。

最后，Salesforce 的灵活架构要求在对象和字段随时间变化时保持数据完整性。备份工具需要将备份映射到当前结构，而不是强制使用僵化的模式，在数据模型演变时出现故障。跟踪字段历史记录有助于正确对齐变化的数据类型和属性。

数据备份和元数据一样重要，都是全面保护 Salesforce 业务连续性的关键。但为了有效，数据备份解决方案必须针对 Salesforce 独特的数据建模、大规模以及灵活的架构能力量身定制。该平台的独特性要求数据备份工具具备特定功能。

初看之下，你可能会认为备份组织中所有元素是最明智的做法。然而，事实并非总是如此，有时反而适得其反。有些对象虽然经常更新，但在备份中并不具有重要价值。例如，AuthSession、LoginGeo和LoginIp等对象，经常发生变化，但不包含关键信息数据。

类似地，如果你考虑备份一个自定义对象，比如Case，关联的CaseFeed、CaseHistory和CaseShare对象可能没有太大的备份价值，原因相同。省略这些对象可以生成更紧凑的备份，从而加快备份和恢复过程——在共享表的情况下，这些表会在相关记录恢复后动态重建。如果使用能够跟踪和评估数据修改的备份解决方案，那么排除高变动对象将更加有效。这样做可以简化监控过程，使识别对关键数据有影响的更改变得更加容易。

恢复过程

在危机发生时，当 Salesforce 数据遭到破坏或丢失时，备份的即时可用性就是生命线。然而，仅仅准备好备份并不能完全保证业务连续性。一个复杂的架构，包括恢复过程、验证以及数据的无缝恢复至关重要。

该过程的初步步骤是验证备份的可行性。一个常见的误区是，假设最新的备份没有错误并且可以使用。这种假设可能导致更多的复杂问题，突显出持续监控备份完整性的重要性。通过自动化并持续监控备份，组织可以迅速检测异常，确保随时能够获取到可靠且未受污染的备份。

然而，即使在进入恢复模式之前，组织也必须采取战略性的立场。分析数据丢失的性质和范围至关重要。深入分析备份数据可以揭示数据是被破坏还是完全删除。它有助于确定具体哪些记录和对象受到影响，以及异常发生的时间。这种深入的检查确保恢复过程能够集中于受影响的区域，防止未受影响的数据被意外覆盖。

一旦需要恢复的数据范围明确，恢复过程本身可以规划。对于元数据，建议按逻辑顺序逐步恢复组件，匹配依赖关系。应首先处理基础元素，如核心自定义对象和字段，为权限、业务逻辑和展示层提供基础。将恢复过程分为更小的部分可以避免错误级联并简化故障排除。

当存在大量元数据时，按阶段恢复优先级分类可以降低风险。推荐的顺序如下：

1. 数据层：定义组织数据结构基础的核心自定义对象、字段和模式。

2. 安全性：控制用户访问和数据隔离的权限集、配置文件和共享规则。

3. 可编程性：任何支持自定义业务逻辑的 Apex 类、触发器、组件和测试。

4. 展示：构成 UI 展示层的 Visualforce、Lightning 和布局元数据。

5. 其他：如电子邮件、报告和文档等附加元数据，用于自定义和配置组织。

此工作流程与平台固有的层次结构相匹配，从原始数据组件到复杂的叠加层。

同样，在恢复大量数据时，应优先处理核心对象，同时捕获相关数据依赖关系。Salesforce 推荐的优先顺序如下：

1. 用户

2. 账户

3. 活动

4. 联系人

5. 商机

6. 案件

7. 价格书籍

8. 产品

9. 潜在客户

10. 合同

这种对象数据的划分进一步得到了 Salesforce 平台的鼓励，具体取决于恢复机制。如果你在使用 Apex，架构师应当充分理解记录分块的行为——务必阅读并参考 Salesforce 文档中的创建多对象类型记录部分，链接：developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_dml_limitations.htm#:~:text=Creating%20Records%20for%20Multiple%20Object%20Types。

强大的备份解决方案可以恢复跨多个对象的互相关联数据，以维护关系完整性。通过所有者或时间框架对非常大的数据集进行分段有助于避免恢复时的平台限制。架构师还应注意查找偏斜、所有权偏斜的概念以及平台在设计恢复过程时的记录锁定行为。

Salesforce 中的查找偏斜指的是通过查找关系将许多记录（通常是成千上万条记录）与单一记录关联的情况。这可能导致性能问题，并且可能对数据库操作（如查询、报告和数据加载）产生负面影响。Salesforce 中的所有权偏斜是一个与查找偏斜不同但相关的概念。它发生在 Salesforce 组织中许多记录由单一用户或少数用户拥有时。这可能导致性能问题和操作上的挑战，类似于查找偏斜所带来的问题。

通过遵循一个结构化、分阶段的恢复工作流程，针对数据丢失的情况，组织可以简化恢复过程，尽早排查问题，并最小化因忽视处理相互依赖关系而导致的错误。

你可能会想知道如何完善这个恢复过程。答案就在于利用 Salesforce 沙盒。通过在这些环境中进行模拟演练，团队可以优化恢复程序。随着时间的推移，这些反复的实践可以培养出一种肌肉记忆，使团队能够迅速高效地应对实时危机。此外，详细的恢复蓝图文档具有双重目的：它既是宝贵的参考指南，又是为新团队成员提供培训的必要工具。

对于将 DevOps 集成到运营中的组织，恢复过程可以进一步简化。利用熟悉的工具和环境可以加快恢复工作。当团队能够使用他们每天都在使用的工具和界面时，可以减少由于不熟悉而产生的错误可能性。

虽然强大的备份的重要性不可低估，但组织在面对数据危机时的恢复能力不仅仅依赖于备份。它需要精心的规划、严格的测试、全面的文档和持续的培训相结合。只有这样，组织才能确信在数据故障时能够迅速且有效地做出响应。备战不仅仅是一种策略，它是 Salesforce 生态系统中数据安全的基石。

事件和灾难恢复规划

强大的备份解决方案是数据保护的重要基础，但组织还必须制定详细的应对和恢复计划。将事件响应和灾难恢复程序与备份工具一起准备，可以提供一种全面的方法来减少业务中断。

事件响应计划

事件响应计划概述了在危机（如数据泄露或系统故障）期间采取的立即行动。它们为调查、遏制、沟通和初步恢复步骤建立了明确的协议。以下是一些关键元素：

• 定义组建具有跨职能专长的事件响应团队的角色

• 收集证据、评估损害和进行事件根本原因分析的检查表

• 与受影响的利益相关者进行内部和外部沟通的计划

• 向监管机构报告事件的合规协议

• 从备份中安全恢复的初步恢复工作流程

• 事件后总结经验教训并改进计划的文档

拥有事件响应计划可以帮助你避免在危机期间做出仓促、紧张的决策，而是能够采取深思熟虑、优化的反应。

灾难恢复计划

灾难恢复计划侧重于在重大故障后恢复正常业务操作的长期过程。它们为韧性制定政策和技术战略，例如以下内容：

• 确定系统的最大可接受停机阈值

• 架构基础设施冗余和备用站点

• 定义备份计划频率以限制潜在的数据丢失

• 计算从备份恢复所需的时间

• 制定有序恢复程序并进行测试

• 培训人员并进行模拟演练以完善恢复能力

• 确保符合关于可用性的监管要求

• 文档化计划、系统图、依赖关系和程序

仔细的灾难恢复规划可以减少灾难性系统中断带来的运营、财务、法律和声誉后果。

通过制定协调一致的事件响应和灾难恢复计划以及数据备份，组织可以最大限度地减少业务中断、增强韧性并提高响应能力。

当然，我们都知道 Salesforce 有一些其他软件系统中可能不存在的考虑因素。例如，架构师应考虑如何处理比典型的新记录更早进入业务流程的数据，提前做好任何数据恢复的准备。想象一个规则，机会记录不能被创建为“已关闭并赢得”。然而，如果你在数据丢失的情况下恢复备份，可能非常希望这么做。

验证规则是另一个简单的例子，一些 DevOps 解决方案可以在恢复之前停用这些规则。然而，围绕流程和触发器已经形成了更复杂的框架——并且托管包可能有进一步的定制解决方案，因为托管的流程和触发器无法停用。因此，在设计处理数据验证的业务逻辑时，确保在数据恢复过程中能够插入任何状态的数据。

确保备份数据的安全

备份数据通常包含敏感信息，如客户详情、员工记录、知识产权和其他专有或受监管的数据类型。因此，正确地保护备份数据对于减轻合规性、合同和网络安全风险至关重要。

在存储方面，考虑到 Salesforce 的云平台特性，基于云的备份较为常见，但司法管辖区的数据主权政策可能要求使用本地备份。无论如何，备份应与实时数据分开存储，以减少单点故障的暴露风险。

管理备份访问至关重要。这可以通过基于角色的控制、最小权限和严格的身份管理来实现。这样可以确保只有授权人员才能查看或修改备份。使用行业标准如 AES-256 对传输中和静态数据进行加密保护是必须的。加密密钥还应具备强大的生命周期管理。

监控备份操作、访问、异常和变更，提供有价值的活动审计日志，以证明合规性并在需要时支持事件调查。

备份平台必须帮助应对与保留政策、数据驻留、被遗忘权和监管要求相关的合规需求的变化。服务提供商应拥有严格的网络安全程序，涵盖软件开发、事件响应、漏洞管理和业务连续性。

通过从一开始就全面解决备份安全和合规要求，组织可以适当地保护敏感数据，并在需要时实现高效恢复。

应对 GDPR 和 CCPA 数据备份法规

在数据保护和隐私意识日益增强的时代，跨欧洲和美国运营的企业受到两大主要监管框架的制约：GDPR 和 CCPA。这些法规直接影响组织如何管理和存储备份数据。

GDPR 概述

GDPR 赋予欧洲联盟（EU）和欧洲经济区（EEA）的个人对其数据的广泛权利。在许多条款中，考虑备份策略时，删除权尤其突出。根据 GDPR 第 17 条的规定，个人有权要求几乎所有公司——即使是位于欧盟和欧洲经济区之外的公司——在规定的 30 天内删除其档案中的数据。因此，服务于 EU 和 EEA 客户的企业必须具备识别并删除备份中特定记录的能力。

CCPA 的见解

自 2020 年起生效的加利福尼亚消费者隐私法案（CCPA）赋予加利福尼亚州居民类似的权利。尽管 CCPA 的适用范围相较于 GDPR 较窄，但它对公司在承担 CCPA 相关请求责任之前必须满足的具体标准进行了规定。值得注意的是，像欧洲的类似法规，CCPA 也赋予个人查询其持有数据的权利，并要求删除这些数据。随着这些法规逐渐成为标准，企业应预见到需要遵守 GDPR 和 CCPA 两者或其中之一。因此，评估备份策略是否符合这些数据保护规范至关重要。

数据保留考虑因素

架构备份解决方案时，一个重要的决策是建立数据保留政策，以规范备份数据在删除前的存储时长。组织根据业务需求、法律因素和预算约束采取不同的保留策略。

许多组织选择无限期保留数据，以最大化可用于恢复的历史快照。没有设定删除时间表，所有备份数据将永久可用。这确保了即使是非常旧的备份副本，也可以在需要时恢复丢失的生产数据或进行历史审计。然而，无限期保留会导致存储消耗和成本随着时间的推移不断增加，因为新备份不断积累。

其他公司选择实施有限的数据保留窗口，在设定的时间段后自动删除备份。保留期可能由行业法规要求，规定由于隐私法的要求，数据只能保留特定年限。与客户或合作伙伴的合同条款也可能规定最大保留期限。从预算的角度来看，定期删除备份有助于控制在无限期保留策略下，存储费用无限增长的问题。

一些组织将备份数据保留时间表与其消费者数据保留政策对齐，以限制个人信息的存储时间。这确保了备份反映出公司删除承诺。然而，如果有价值的历史业务数据与过期的消费者记录一起被过早删除，这可能会带来风险。一种更好的方法是无限期保留业务数据，同时根据数据类型仅删除备份中的消费者数据。

限制性保留政策的权衡在于，历史恢复快照的可用性会随着时间的推移而减少。虽然最近的备份数据会被保留，但较旧的备份最终会被永久删除。因此，保留时间表意味着在保留期过后，可能无法访问过时的记录。

在金融服务和医疗等受监管行业中，某些数据类型的最低保留期限可能是强制性的，允许在数据达到特定年龄后删除其他数据。在定义保留政策时，应纳入合规因素。

最终，组织需要根据其独特的业务需求、数据恢复要求、增长约束和法律义务来权衡不同的保留方法的利弊。然而，制定明确的正式数据保留政策以备份数据提供一致性、可预测性，并与公司数据治理标准保持一致。与所有数据政策一样，保留指南应定期审查。

Salesforce 备份选项

在设计备份策略时，组织有多种方法可供考虑。

没有备份

不采取行动本身可以是有意的行为，但在数据备份的情况下，这并不推荐。缺乏数据保护将使公司面临严重的业务中断、合规违规甚至在数据丢失后破产的风险。对本地 Salesforce 恢复或回收站服务的过度信任会留下不应忽视的漏洞。

手动导出

自助数据导出至少提供了最低限度的保护，但需要手动重复操作，恢复速度慢且有限，同时会带来存储和合规的额外开销。缺乏元数据备份来补充数据备份并提供上下文，只会阻碍完整恢复。

版本控制

版本控制系统（VCS）作为元数据和数据备份机制的集成，相较于手动方法，代表了一项显著的进步。在发生灾难性故障的情况下，VCS 可以作为可靠的灾难恢复来源，帮助团队将整个元数据重新部署到新的 Salesforce 组织中，从而确保业务连续性。此外，保持详细的变更历史对于审计追踪和合规要求至关重要，VCS 通过以结构化且可访问的方式跟踪变更来促进这一过程。

然而，在 Salesforce DevOps 中依赖 VCS 进行备份并非没有挑战和局限性。将 VCS 集成到 Salesforce 中的复杂性需要对 Salesforce 环境和版本控制实践有深入的理解，这对于不熟悉版本控制的基于点击的管理员来说可能会显得特别艰难。当多个开发人员在同一项目上工作时，即使 VCS 提供了防止覆盖的保护措施，覆盖现有代码或引入与主代码库冲突的更新的风险也会增加。

VCS 在捕捉 Salesforce 数据的细微差别方面的能力有限，这可能导致备份不完整并带来恢复挑战。依赖外部工具引入了备份和恢复过程中的额外失败点，使得备份过程既耗时又资源密集。VCS 可能不足以在系统完全故障或数据损坏的情况下进行全面的灾难恢复。

实现 VCS 的无缝高效集成，并使其对 Salesforce 管理员来说既易于访问又用户友好，仍然是一项巨大挑战。确保符合数据保护法和安全标准，为将 VCS 作为备份解决方案的使用增添了额外的复杂性。VCS 使用不当可能导致技术债务增加，尤其是在部署过程中经常出现错误和漏洞时，技术债务的潜在增长尤为严重。没有全面的 VCS 策略，可能会缺乏对变更历史和上下文的完整视图，从而阻碍调试、决策和了解特定变更在 Salesforce 环境中的影响。

本地 Salesforce 工具

Salesforce 的备份解决方案目前已全面推出，提供自动化备份、轻松的数据恢复和强大的加密功能，以增强数据安全性。然而，一个显著的限制是数据被局限在 Salesforce 基础设施内。它缺乏平台外备份选项，这可能会对寻求多样化数据备份策略的组织构成障碍。最初，Salesforce 曾有一个数据恢复服务，但该服务被停用，随后由于客户的强烈反馈，恢复了该服务，并因此创建了新的备份和恢复服务。

定制化备份解决方案

专门为 Salesforce 设计的强大第三方工具提供自动化、数据监控、快速完全恢复、安全集成和其他针对平台独特需求的高级功能。

在评估选项时，最高优先级是确保全面和快速的恢复，最小化事件中的干扰，以及保障安全和合规性。预算必须与停机高昂的成本进行权衡。集成的 DevOps 工具能最大化价值。

这些解决方案中的许多（如果不是所有）都提供免费试用，这将帮助你确保它们具有所需的覆盖范围和易用性——这两者是决策的关键因素。

准确恢复数据和元数据可能非常困难。在 Salesforce 中，某些元数据类型及其对应的数据无法恢复。这些考虑因素应当是备份和灾难恢复架构规划的一部分，以便企业理解能够恢复的内容的限制。例如，在大多数情况下，恢复记录后，你无法恢复原始的 Salesforce 记录 ID，因此其他系统不应依赖记录 ID。

考虑到任何限制因素，有助于选择备份工具。如果某些方面对企业来说既困难又重要，那么这应该是任何供应商评估中的优先事项。

总结

本章讨论了在 Salesforce 中全面备份数据和元数据的关键需求，以减少数据丢失事件对业务的干扰。

我们讨论了如果恢复不及时，数据丢失和系统停机可能导致的灾难性成本，包括生产力损失、收入损失、声誉损害和合规性问题。可行的备份通过支持快速恢复来减少损害。

强大的 Salesforce 备份解决方案需要具备外部存储、自动化、集成、智能恢复和企业级安全等关键能力。元数据必须与原始数据一起备份，以提供结构、访问控制和自动化。还讨论了大规模 Salesforce 数据备份的有效技术。

事件响应计划概述了危机期间的紧急措施，而灾难恢复计划则专注于长期的恢复程序。测试和文档记录是关键。谨慎保护敏感的备份数据也是至关重要的。

结合备份、规划、安全性、合规性和专为 Salesforce 设计的解决方案，全面的数据保护使组织能够最大限度地减少中断，保护信息资产，并保持业务连续性和客户信任。

归根结底，你的备份只能像你恢复它们的能力一样有效。同样，如果你没有备份，就不能恢复。因此，备份应该是全面的并定期进行。

在接下来的章节中，我们将处理 DevOps 更具操作性的另一个方面，即监控变更。在 Salesforce 中，变更可以来自多个来源，甚至包括生产环境。通过有效的监控保持对这些变更的严格控制，并确保所有环境都是最新且同步的，将是我们的下一个主题。

第十章：监控变化

在本章中，我们将探讨管理 Salesforce 环境的一些关键方面。保持一个稳定、顺畅运行的 Salesforce 环境的关键在于高效的变更管理和监控。然而，随着数据复杂度和体积的增加，手动的变更控制变得越来越不可行。因此，自动化和全面的环境监控需求应运而生。

本章将深入探讨监控 Salesforce 环境的重要性。我们将研究如何即便是出于良好意图进行的无控制变更，也可能导致环境不稳定，破坏 Salesforce 环境的顺畅运行。我们还将讨论监控工具如何帮助我们检测环境中的变化，使我们能够了解所有变化的发生者、内容、时间和地点，无论这些变化是有意的还是无意的。

除了元数据监控，我们还将探讨如何通过监控其他因素，如数据指标，帮助我们在问题影响用户之前发现潜在问题。我们将讨论如何通过监控变更为我们提供关于环境健康的关键信息，以及这如何增强我们对环境与真相来源一致性的信心。

我们还将了解不同类型的监控，例如元数据监控、数据监控、姿态监控以及运营监控与可观察性。每一种监控类型在维持稳定的 Salesforce 环境中都有其独特的重要性和作用。

本章将涵盖以下主题：

• 如何通过不同种类的监控来管理你的环境

• 元数据监控如何工作

• 如何以及为何监控环境中的相关数据变化

本章结束时，你将全面理解 Salesforce 环境监控的重要性，以及它如何帮助你保持一个稳定、高效的 Salesforce 环境。你将从本章中获得的知识，将帮助你避免 Salesforce 环境中的不稳定性和中断。

如何管理你的 Salesforce 环境

管理你的 Salesforce 环境对于你组织运营的稳定性和效率至关重要。这个任务的重要性不容小觑——一个管理良好的 Salesforce 环境能确保工作流的顺畅、数据的完整性以及最佳的性能。忽视这一方面的后果可能是严重的。从轻微的数据差异开始，问题可能逐渐升级，最终导致重大工作流中断。这些问题最终可能导致客户信任的显著流失和收入的明显下降。

这强调了，如果没有警惕的管理，运营中断、数据安全受损，最终可能导致财务和声誉损害的风险会显著增加。在接下来的部分中，我们将深入探讨维护 Salesforce 环境健康和一致性所必需的不同类型的监控，说明为什么主动和全面的管理不仅有益，而且对任何利用 Salesforce 的企业都是至关重要的。

监控的必要性

我们力求保持 Salesforce 环境的稳定性和完整性。然而，不受控制的变更，无论出于何种良好意图，都可能破坏我们的努力。开发人员直接在生产环境中调整验证规则。管理员在沙盒中删除一些看似过时的字段。变更发生在管道之外，导致环境不同步。没过多久，我们就开始与不稳定作斗争，而不是进行创新。

变更管理对企业 Salesforce 开发来说是不可妥协的。然而，手动变更控制有其局限性。随着环境和团队规模的增长，我们需要自动化来跟踪变更。全面的环境监控为我们提供了这一优势。

在 DevOps 和系统监控的背景下，强调强大部署流程的重要性作为防范意外系统更改的首要防线至关重要。高效且简洁的部署流程可以最大程度地减少绕过源代码控制的可能性，从而降低意外变更的风险。尽管监控仍然是一个重要环节，但完善部署流程可以显著降低监控过程中发现的异常的频率和严重性。这种方法强调了部署策略与监控效果之间的相互依赖，说明优化部署流程可以带来更稳定、可预测的系统行为。

强大的监控不仅限于生产环境，还要检查我们环境中的所有变更。沙盒，尤其是开发者沙盒，是实验的温床。这里的变更可能一开始有意地不在管道内。但我们依然需要可视性。暂存和测试沙盒也需要监督，以防未经验证的变更扩散。

通过自动化监控，我们可以检测所有环境中的变更，而不仅仅是生产环境。最先进的工具能够捕捉元数据的即时快照，并与之前的快照进行对比，以识别修改。这使我们能够看到所有变更的具体信息——谁做了什么、何时做的、在哪里做的，无论是有意的还是无意的。

元数据监控专注于组件的变更，如自定义对象、字段、Apex 类和 Lightning 页面。但关注其他环境因素同样重要。数据指标能够帮助我们在问题影响用户之前发现许多潜在问题。

监控更改为我们提供了关于环境健康的关键洞察。我们可以确信环境与真实数据源保持一致。我们可以验证预期的更改是否正确地通过管道传播。我们还可以在问题引发稳定性问题之前，快速响应未预期的更改。

通过将主动监控与简化的补救措施结合起来，我们可以掌控 Salesforce 中的更改。我们的开发团队可以在不危及稳定性的情况下自由创新。架构师能够安然入睡，知道环境与设计保持一致，而我们的用户则享有最大程度的正常运行时间和生产力。在接下来的章节中，我们将更详细地讨论这些主题。

探索不同种类的监控

有效的监控是维护和提高系统性能、安全性和可靠性的基石。不同种类的监控针对 Salesforce 环境的不同方面，每种都具有独特的目的，并提供不同的洞察。了解这些种类不仅仅是收集数据，而是要战略性地利用这些信息来做出明智决策，并主动管理系统。

在本节中，我们将深入探讨不同形式的监控——从元数据和数据模式监控到姿态监控和操作可观察性。每种类型在理解和优化 Salesforce 环境中都发挥着至关重要的作用。

元数据监控

元数据监控是指跟踪对 Salesforce 元数据组件（如自定义对象、字段、工作流和 Apex 代码）所做的更改的实践。通过监控元数据，管理员可以保持对其组织内配置更改的较低延迟的意识。这提供了谁在何时做了什么更改的可视性，这对于故障排除、合规性和变更管理非常有用。元数据监控的目标是保持对自定义设置的控制和透明度，随着团队扩展 Salesforce 开发工作。与手动检查不同，自动化工具可以全天候监控元数据，并在发生重要更新时提醒相关人员。

监控 Salesforce 数据的变化和模式

除了监控元数据之外，监控 Salesforce 数据本身的变化和模式同样重要。配置数据，如 CPQ 配置，应该像监控元数据一样进行跟踪。数据异常，如激增、下降或异常值，应当进行监控，以识别潜在的数据质量问题或业务变更。持续的数据行为，如增长趋势、使用模式和数据流，应进行分析，以指导容量规划和优化。自动化工具可以应用逻辑实时从生产数据中提取洞察。目标是获取对数据稳定性和变化的可视性，主动识别和解决潜在问题。

姿态监控

态势监控指的是评估 Salesforce 组织的整体安全健康状况。这包括跟踪配置设置，如用户权限、凭证策略和共享规则，以检测可能导致访问泄露或违规的风险设置。态势监控还意味着分析使用模式，识别异常的终端用户或集成行为，这些行为可能表明凭证被泄露或遭到攻击。工具可以自动将配置与安全基准进行比较，并在潜在漏洞被引入时发出警报。其目标是实现对 Salesforce 组织安全状况的持续可见性，并及时通知可能引发风险的变更。态势监控使管理员能够主动修复问题，防止其被利用，并保持实例的安全态势。

操作监控和可观测性

操作监控指的是跟踪生产环境中应用程序和基础设施的性能、可用性和整体健康状况。这包括监控响应时间、错误率和资源利用率等指标，以检测问题并优化配置。可观测性基于操作监控，通过引入日志、跟踪和自定义遥测等额外信号，深入了解系统行为并获取更多的上下文信息。

操作监控和可观测性共同提供了保持应用程序和服务平稳运行所需的实时可见性。然而，重点是在监控当前状态，而非随时间变化的内容。虽然它们各自都是重要的学科，但操作监控和可观测性与我们所讨论的变更监控有所不同。例如，变更监控可能侧重于定制内容随时间的演变，而操作监控则可能专注于已部署的定制内容是否在其性能参数范围内正常运行，并继续满足接受标准。

变更监控的目标是通过警报和审计追踪，主动跟踪配置、数据和安全性的变动，以识别风险、问题和改进机会。相对而言，操作监控和可观测性旨在在生产环境中发生性能问题或故障时，快速应对和优化。由于我们关注的是变更监控，而非当前状态的可见性，因此本书不会涉及操作监控或可观测性实践的具体内容。然而，这些实践是互补的，属于全面监控策略的一部分。

在本节中，我们介绍了广泛的主题，从元数据和数据模式监控的必要性，到姿态监控和操作可观察性等关键方面。我们了解到，每种形式的监控在不仅保护我们的 Salesforce 组织的完整性和安全性方面扮演着至关重要的角色，同时也在提升其性能和可靠性方面具有重要作用。接下来我们将讨论如何监控我们组织的元数据变更。

监控元数据

在本节中，我们将深入探讨元数据监控在 Salesforce 平台中的关键作用，这是环境控制和管理的基石。元数据是定义 Salesforce 组织中每个组件的基础结构，随着组织的自定义和扩展，它不断演变。

通过提供全面的概述，说明为何应监控元数据，我们旨在强调实施健全的元数据监控策略的必要性，从而确保一个更可控、更透明、更高效的 Salesforce 环境。

为什么要监控元数据？

监控元数据的变更是一个至关重要的任务。当你自定义和扩展你的组织时，相关的元数据也会随之演变。这是因为 Salesforce 平台中的一切都以元数据的形式存在，所以你所做的任何更改都会导致元数据的变化。这也意味着随着自定义程度的增加，元数据会变得更加复杂。

跟踪这些元数据变更带来了以下多方面的好处：

• 促进协作：通过可见的元数据变更，开发人员可以避免在进行中的并行工作中覆盖已有的成果。开发人员和管理员对连接的组织中的当前状态有共同的理解，减少了不一致性。

• 加速开发：及早识别不一致性可以防止级联重工。如果在沙盒中新增了一个字段，但没有在生产环境中添加，及早发现这一点可以避免在不一致的元数据基础上浪费精力。

• 支持合规性：详细的元数据变更历史满足治理流程中对修改审计记录的要求。按需报告可以验证是否遵循了正确的协议。

如果没有全面的监控，元数据变更可能会在阴影中积累并无人检查。也许一个开发人员在沙盒中添加了一个字段，但忘记将其部署到生产环境中。管理员直接在生产环境中调整了验证规则以修复一个 bug。这些小的未被检测到的不一致性会逐渐积累成重大问题。

手动跟踪和松散的版本控制工作流有盲点。元数据更改往往会不经意间被遗漏。自动化解决方案可以通过定期记录所有连接组织的元数据状态，甚至最细粒度的组件，从而填补这些空白，但它们是有成本的。对比可以揭示精确的差异，突出显示任何环境中的每个元数据添加、删除或修改。

通过更全面的视角，架构师可以更好地了解 Salesforce 环境的形态和稳定性。开发人员可以更有信心地进行工作，确保并行操作不会被覆盖。产品和管理员从共享的真实信息源中进行协作。合规团队则拥有修改的审计追踪。

作为架构师，我们通常是所管理环境长期健康的守护者，认真跟踪元数据的变化是其中一个重要部分。幸运的是，已经有解决方案可以将强大的元数据监管无缝地融入现代开发实践中。我们将在接下来的部分中探讨这一点。

生产环境中的元数据监控

在生产环境中监控元数据的变化对于在环境扩展和演变过程中保持透明性和控制力至关重要。主要目标是实时了解各个团队和个人在组织中进行的自定义操作。即使这些组件是通过 CI/CD 流水线部署的，我们仍然需要确保生产环境中的元数据符合预期。通过跟踪所有元数据组件的添加、编辑、删除和部署，管理员可以实时了解新特性和配置进入组织，而无需在事后手动拼凑变更活动。

通过元数据变更可视化，管理员可以识别谁做了什么更改、何时进行的更改，以支持审计、故障排查和变更管理流程。监控元数据有助于识别后果，并追溯到引发问题的特定配置更改。它还通过提供所有自定义操作的文档支持合规性。此外，监控元数据的变化还有助于发现应该合并的不必要重复项，以及可以删除的孤立组件。总体目标是随着时间推移，通过持续的可视化管理一个良好管理、透明的组织结构，以应对日益复杂的环境。

此外，一些小规模的元数据自定义，比如报告和文档，可以安全地在生产环境中直接更改，但监控这些元数据仍然是保持对跨环境变更的可视性和控制的必要手段。即使是允许的生产变更，追踪谁在何时做了什么更改，对于审计、故障排查和治理来说都是至关重要的。

为了保持对 Salesforce 生产组织中的自定义内容的完全可见性，应监控广泛的元数据组件。从高层次来看，任何在 Salesforce 平台上构建的、用于扩展功能或根据业务需求定制系统的可配置项目都应当进行跟踪。这包括管理员可以访问的声明性工具以及工程师开发的编程组件。

具体的示例包括自定义对象、字段、页面布局、验证和工作流规则、Visualforce 页面、Lightning 组件、Apex 触发器和类、权限集、配置文件、共享规则等等。监控还应包括点击即代码的配置，如审批流程、分配规则、电子邮件模板和流程。通过 Lightning 应用构建器、体验构建器和社区构建器进行的整体应用结构的高级更改也非常重要，需要加以捕捉。全面的元数据监控不仅仅限于业务逻辑和最终用户组件，还应包括身份验证、集成和安全配置等操作设置。其目标是跟踪所有自定义定义的元数据，以便能够检测到任何变更，从而保持对生产组织发展变化的透明度。

你可以使用手动或半自动化的过程来监控生产环境中的元数据，这在典型环境中，由于生产组织数量通常较少，因此是可行的。这个过程可能涉及多个工具，你可以根据自己的具体需求将它们结合使用：

• 监控部署：在 设置 中，你可以跟踪所有的变更集和元数据 API 部署到你的组织。

• 设置审核跟踪：在这里，你可以看到对组织所做的所有 设置 更改。如果你坚持手动过程，这通常是一个很好的起点。

• 针对元数据对象的 SOQL 查询：有一些系统对象代表了不同类型的元数据，管理员可以通过开发者控制台使用这些对象。

• 事件监控：如果你拥有 Shield，事件监控模块将为你提供非常详细的日志，这些日志可以导出并在分析工具中进行分析。

如果手动监控过程看起来让人感到困难或不切实际，那么有许多供应商提供现成的解决方案，包括 Gearset、Panaya、Salto 和 Elements.cloud。

在介绍了如何监控生产中的元数据后，让我们来看一下如何在沙盒环境中监控元数据。

沙盒中的元数据监控

沙盒在 Salesforce 的开发和测试工作流程中发挥着关键作用。沙盒中监控的元数据取决于其预定用途。

完全复制沙盒包含了生产环境元数据和数据的副本。生产环境中监控的所有相同的元数据组件也应在这里进行跟踪。完全复制沙盒允许准确模拟生产环境，以进行严格的测试。只有在验证后，这里的更改才应部署到生产环境中。

开发者和开发者专业版沙盒仅包含少量数据的元数据。监控应重点关注诸如 Apex、Lightning 和关键配置组件等代码组件，以便在不影响生产数据的情况下进行开发。当新的功能构建完成时，生产环境与沙盒之间的元数据和行为差异会显现出来，并在发布之前需要进行对齐。

沙盒刷新和删除可能会清除环境之间的配置差异。持续的元数据监控可以在这些事件中提供连续性，保持对变化的可视性。监控的覆盖范围应与每个沙盒的角色相匹配。不过，在生产环境和沙盒中全面的可视性是无缝管理整个组织的元数据的关键。

虽然对于小型组织和部署而言，手动方法似乎足够，但随着 Salesforce 足迹的扩大，单靠临时监控和脚本很快就变得不切实际。沙盒和生产环境中元数据和配置的多样性使得手动跟踪变得繁琐。开发者浪费时间拼凑变更，而不是进行构建，而管理员则无法清晰地看到测试和发布过程。

手动监控元数据在每个步骤中都会面临限制。从多个沙盒和生产环境中收集元数据需要反复执行检索调用或下载。将这些结果整合以便跨环境进行比较涉及繁琐的解析和分析。跟踪变化的过程需要手动进行版本控制和变更管理。即便是严格的管理，也不可避免地会出现捕捉元数据快照的空白。通过 SFDX 进行源代码跟踪，其中源代码变更会被自动标记，这可以帮助完成此任务，并且是 DevOps 工具包中受欢迎的补充，但当规模扩大时，这未必足够。

构建自定义脚本和工具可以自动化部分元数据收集和比较。各种 Salesforce API 提供了访问元数据以进行检索的功能。然而，全面监控所有元数据类型涉及在 Metadata、Tooling 和 REST API 之间精心协调 API 调用。不过，某些对象和组件可能需要专门的逻辑。维护脚本还需要持续开发，尤其是在 API 发生变化时。

随着复杂性的增加，管理员或开发者的带宽迅速超负荷。学习曲线和额外的开销分散了对关键任务的关注。即使定制的解决方案成功了，它也只自动化了元数据的捕获，而不是复杂的监控和分析。边缘案例将导致元数据配置追踪的盲点。因此，依赖现有的、经过验证的第三方解决方案是一个明智的投资。

为元数据管理量身定制的工具在全面监控方面要远远优于通用工具。它们为所有 Salesforce API 中的元数据类型提供开箱即用的支持。自动化快照收集和比较能够为跨环境的变更跟踪提供支持。使用分析可以识别趋势和热点，从而指导优化。与集成开发环境（IDEs）和发布管理系统的集成，使得从开发到部署的端到端可视化成为可能。

关于 scratch org 的说明

**Scratch orgs（临时组织）**比沙盒更具短暂性和一次性。它们按需创建，用于开发或测试，工作完成后被删除。由于这种短暂的生命周期，在 scratch org 中进行全面的元数据监控的长期价值较小。重点应放在追踪在给定 scratch org 实例短期使用期间所做的更改，而不是通过刷新或删除来保持历史记录。轻量级的变更意识有助于协调开发团队成员之间在 scratch org 中的工作。然而，对于 scratch org 的精细监控和治理实践可能会妨碍敏捷性。虽然配置和自定义 scratch org 不应完全不受控制，但监控的目标是实际的变更可见性，而不是详尽的审计轨迹。与生产环境和沙盒环境相比，scratch org 的短暂性使得优先级更多地偏向于敏捷性而非治理。

监控数据行为

在 Salesforce 环境中监控数据行为不仅是最佳实践，而是保持系统健康和确保业务连续性的必要条件。因此，了解为什么这一方面需要与元数据监控一样多的关注是至关重要的。Salesforce 中的数据不仅仅是数字和文本的集合；它代表了用户和系统内过程的实时交互。通过密切监控这些数据的变化和趋势，我们可以获得宝贵的洞察力，了解操作的有效性以及潜在的风险。

本节将探讨在 Salesforce 中监控数据的重要性多方面性。我们将讨论监控数据行为的关键原因，包括以下几点：

• 防止配置漂移

• 随着用户需求的变化，保持可见性

• 识别优化机会

• 为合规性启用审计跟踪

• 预测容量需求

这些元素中的每一个在全面的环境管理中都扮演着关键角色，确保您的 Salesforce 实施保持强大、合规，并与您的业务目标保持一致。

为什么要监控您的数据？

紧密关注 Salesforce 数据的变化和趋势与监控元数据同样重要，这对于全面的环境管理至关重要。元数据代表了您实施的结构和组件，而数据则提供了关于用户和流程实际使用 Salesforce 的重要可见性。

监控数据和元数据一起提供了一个更完整的环境状态图景。如果仅有元数据而没有监控数据，就会存在盲点，可能导致问题逐渐在时间中浮现。

有几个关键原因说明数据变更监控应该是优先事项：

• 捕捉配置漂移：像 CPQ 这样的 Salesforce 配置数据需要监督。数据监控确保配置保持准确对齐。

• 随着使用变化保持可视化：定期的数据加载、持续的使用和变化的需求使得 Salesforce 数据持续变化。监控有助于确保随着数据的变化保持对齐。通常，数据异常揭示了应用程序中潜在的问题。

• 识别优化机会：使用指标揭示数据访问模式，以优化索引、存储等。监控指导战略优化，例如归档。

• 启用审计轨迹：变更监控提供了审计轨迹，证明符合数据治理政策和监控链的要求。

• 预测容量需求：历史增长趋势有助于根据数据随时间的使用方式准确预测未来的存储需求。

如果不进行监控，配置数据中的小偏差可能会随着时间的推移慢慢累积。设置可能会在不同的组织之间不同步，甚至与治理政策不合规。主动监督可以通过在配置更改时保持连续性和控制来防止这一点。

数据的体量和多样性使得手动检查随着时间推移变得不切实际。自动化的持续监控为管理员和架构师提供了对元数据和数据的完整可追溯性。如同往常一样，这可能会带来一定的成本。

然而，通过全面的可视化，能够实现早期优化、规划和问题解决，环境可以在支持日益增长的复杂性的同时，提供更成功的商业成果。监控数据与元数据一起提供了对环境状态的整体视图，这是大规模管理 Salesforce 实施的关键。

监控配置数据

除了标准的业务数据外，Salesforce 组织还包含需要与元数据同样重视的配置数据，以便进行环境管理。

配置数据 包括自定义设置、规则和记录，它们控制 Salesforce 中的行为，而不仅仅是捕捉业务事务。以下是一些示例：

• CPQ 报价、产品、价格书和折扣计划

• 账单费用、订阅和支付方式

• 社区会员类型、管理规则和主题

• 爱因斯坦推荐设置和使用指标

这些配置数据对于环境稳定性与标准元数据同样重要。但与元数据不同，配置记录的更改不会默认记录在部署日志中或进行监控。

没有监督的情况下，配置数据可能会偏离业务规则的合规要求。可能会修改影响系统行为或合同条款的关键设置。如果不保持同步，值可能会变得不准确或过时。

因此，监控配置数据至关重要，原因如下：

• 随着配置数据的变化，保持各环境之间的一致性

• 提供对关键设置修改的透明性

• 为合规要求启用审计跟踪

• 防止不希望发生的配置漂移

• 对风险或不当调整发出警报

对配置数据变化的完全可视性使架构师能够确保稳定性和完整性。

某些类型的配置数据可能需要遵守严格的治理政策。例如，审计员可能要求审查对 CPQ 定价和折扣规则的所有更改，这些规则可能会影响收入确认。

监控配置数据满足合规需求，通过提供全面的审计跟踪。查询可以即时验证配置记录修改是否遵循了正确的协议。

没有监控的情况下，配置数据的缺失可能导致难以察觉的错误或无法控制的漂移。这些影响通常随着时间的推移缓慢出现，因为小的偏差不断累积。主动监督通过在配置数据变化时提供连续性和控制，预防了这些问题。

虽然原生的 Salesforce 工具如字段历史记录跟踪提供了有限的洞察力，但全面的监控需要专门构建的解决方案。配置数据的多样性要求自动化以高效地收集、比较和报警。

通过能够追踪配置记录和标准元数据，架构师能够更全面地了解环境的状态。监控配置数据填补了盲点，否则这些盲点可能导致关键设置逐渐失去合规性。保持配置和业务规则在整个 Salesforce 环境中的一致性是稳定性的关键。

监控数据异常

除了标准业务数据和配置数据外，监控不规则性和异常对于尽早发现潜在问题至关重要。异常数据行为可能意味着出现了需要干预的新问题。

以下是一些常见的数据异常，需要触发警报：

• 记录量的突然激增或骤降

• 数据分布偏斜或不可能的异常值

• 批量删除或更新记录

• 特定记录或用户的瓶颈

• 某些字段中缺失或无效的值

• 特定数据类型的处理速度慢

监控统计上不太可能的异常值有助于揭示潜在的数据错误，例如无效条目或完整性问题，防止其扩散。数据分布的不一致可能表明质量问题，需要修正。

记录数量或存储的突然下降可能表示批量删除脚本无意中删除了重要数据。事务性激增可能是集成错误的信号，导致记录重复。

在加载特定记录类型时的性能滞后可能表明数据模型存在缺陷，需要优化。更新特定记录时的瓶颈可能揭示出影响订单处理的产品目录错误。

主动监控有助于在异常行为影响流程和决策之前提前暴露。设定期望的基准值有助于检测显著的偏离。

自动标记与历史规范不符的工具，如 DynaTrace 或 Odaseva，能够快速进行分类处理，确定合适的响应措施。警报使管理员能够快速识别根本原因并解决潜在的数据问题。

数据的数量和多样性使得手动检查异常变得不切实际。自动化解决方案对于基准期望范围并可靠地检测异常值是必不可少的。

例如，监控数据异常可能会发出以下警报：

• 案件数量超过 7 天平均值的 40%

• 超过 10%的联系人记录缺少电话或电子邮件

• 每晚的批量处理时间比平时长超过 50%

通过将变更监控与自动化异常检测相结合，管理员可以在问题影响最终用户之前发现问题。难以发现的数据问题可以通过监控在导致操作中断之前被揭示出来。

在 Salesforce 中，使用标准报告进行一定程度的异常检测通常是相当容易的。事件监控也内建了一些异常检测功能。这意味着，与元数据监控相关的数据监控实施挑战，在某些情况下可能较少。

一般来说，监控生产环境和完整复制沙箱中的数据至关重要。其他环境可能不需要同样程度的审查，尽管在某些情况下，即便是在较低环境中，进行更全面的数据监控也是有意义的。

通过异常警报揭示的事件处理可能需要跨团队的协作。然而，及早识别和解决问题有助于保持数据完整性和健康。

观察异常数据行为提供了独特的可见性，这是仅通过元数据监控无法获得的。结合变更追踪，异常检测能够提供更全面的 Salesforce 环境状态视图。

监控数据质量

除了跟踪变更和异常情况，监控Salesforce 数据质量对保持环境的准确性和完整性至关重要。数据质量是一个大话题，其中很多内容与监控变更并不直接相关。因此，我们这里只讨论其中的一部分。

让数据质量问题在没有监督的情况下积累，会威胁到环境的稳定性。一些常见的数据质量维度包括：

• 完整性：必填字段中的缺失值

• 有效性：不正确的数据格式或无效的条目

• 准确性：不正确或过时的值

• 一致性：相关记录之间的矛盾

低质量数据可能导致若干积重难返的问题，包括以下几点：

• 由于无效数据导致的处理失败，可能直接影响部署

• 难以报告不完整的记录

• 由于信息不准确而做出的错误决策

• 业务用户对数据的信任下降

• 报告或查询的性能差

专门的监控确保数据质量保证是持续运营的一部分。数据问题可以在它们出现时迅速被发现并解决，而不是事后才处理。

例如，监控可以提醒如果一个对象中超过 5% 的记录缺少必要字段，如电话、地址或正确的所有者。未能满足完整性要求将触发纠正过程。

持续跟踪关键质量指标可以突出需要改进的领域。数据管理员可以自动收到通知，实施修复并优化输入工作流。

Salesforce Labs 数据质量仪表盘提供了一个免费的起点，用于监控标准和自定义对象的关键质量指标。架构师还可以根据具体需求构建适合的自定义质量仪表盘。

监控数据量

跟踪存储消耗、记录计数和交易量提供了对数据增长趋势的关键洞察。历史指标使得在数据扩展时能够准确预测基础设施需求和许可成本。注意到数据量激增还可以揭示潜在的处理问题，值得进一步调查。虽然简单，但监控关键的量度指标提供了重要的可见性，指导优化和规划。

Salesforce 提供了原生功能，可以查看您组织当前的存储使用情况，甚至到每个用户和每种记录类型的级别。从设置中，管理员可以访问存储使用报告，显示可用和已用的数据空间、按使用量排序的用户以及最大文件。点击用户可以查看他们按记录类型划分的存储数据。

存储总量是异步计算的，因此在进行大规模导入或文件上传后，使用情况可能不会立即更新。个人用户还可以在其账户信息中查看个人存储利用详情。

在本节中，我们深入探讨了关键领域，如防止配置漂移、随着用户需求的变化保持可见性、识别优化机会、为合规性启用审计追踪以及预测容量需求。这些见解不仅对确保 Salesforce 系统的运营效果至关重要，而且在将其与业务目标对齐方面也起着关键作用。现在，让我们总结一下我们所学到的内容。

总结

管理 Salesforce 环境（包括元数据和数据）是 Salesforce DevOps 的一个关键方面。本章强调了监控环境的重要性，不仅是为了维持稳定性和完整性，还为了理解和监督 Salesforce 组织中各个方面的变更。

我们首先讨论了监控的必要性，详细说明了如何控制变化可以防止不稳定，并探讨了自动化变更控制如何帮助维持秩序。接着，我们探讨了不同类型的监控，包括元数据监控、数据监控、姿态监控和操作监控。

我们深入讨论了元数据监控的具体内容，讲解了在生产环境和沙箱环境中监控元数据的重要性，以及可以使用的各种工具和方法。我们还提到了监控数据行为的必要性，包括配置数据、数据异常、数据质量和数据量。

本章内容强调了在 Salesforce 中的监控不仅仅是一个工具，更是确保系统稳定性、数据完整性以及遵守治理政策的必要实践。它提供了关于变更的“谁、什么、何时、何地”的详细可见性，从而实现更好的控制和问题预防。

在实际场景中，这些监控策略至关重要。它们能够防止小问题升级为严重的工作流中断，通过提供实时的变更可见性，增强协作与合规性，并为容量规划、优化及识别业务趋势提供战略决策支持。

在下一章，我们将转变方向，开始探索具体的 DevOps 工具。

第十一章：数据种植在您的开发环境中

在本章中，我们将深入探讨填充开发环境以实现真实数据的重要性和过程，这对准确的开发和测试至关重要。我们还将探讨数据掩码作为确保敏感数据在整个过程中保持保护的基本技术。

我们将涵盖以下主要主题：

• 准确数据对开发和测试的好处：我们将查看开发环境中的数据如何带来真实感、改善错误检测、提供性能调优的机会，并帮助满足合规性和验证需求。

• 在您的环境中种植数据：在这一部分，我们将探讨将测试数据导入 Salesforce 组织的实际步骤——从数据生成到导入——并讨论如何在注意复杂数据关系的同时自动化这些过程。

• 通过数据掩码保护敏感数据：最后，我们将确保理解数据掩码的重要性，并讨论如何实施它。我们还将讨论合规最佳实践以及一些帮助实现这些实践的工具。

到本章结束时，您将全面了解如何在开发环境中种植真实数据，同时通过数据掩码确保敏感信息的保护。

技术要求

有多种方式可以将 Salesforce 开发环境种植为真实数据用于测试，每种方式都有其要求。如果您没有使用包括此功能的专用 Salesforce DevOps 解决方案，则可以使用 Salesforce 提供的工具和 API。

虽然数据导入向导内置于 Salesforce 中，数据加载器是一个独立的下载工具，但它有自己的依赖项。您可以在developer.salesforce.com/tools/data-loader了解更多信息，包括下载链接。

要使用 Bulk API，您需要用您选择的编程语言编写脚本，从而使编程语言本身成为一种要求。本章后面会给出 Python 的示例，但也可以使用其他能够进行 REST 调用的语言。我们将在本章中统一使用 Bulk API V2。

准确数据对开发和测试的好处

创建一个现实的开发环境是有效系统开发的基石，特别是在像 Salesforce 这样复杂且数据驱动的平台上。建立这种现实感的最关键方面之一是确保用于开发和测试的数据的准确性和完整性。高质量、真实的数据为理解系统在部署到实际生产环境后如何运行奠定了必要的基础。这对于帮助开发人员做出明智的设计决策，并在开发生命周期早期预见潜在的陷阱或问题至关重要。

精确的高保真数据的主要好处在于它为开发环境带来了极高的现实感。当开发人员和质量保证（QA）测试人员能够访问与真实世界数据相似的数据时，他们能够从中获得关于系统在实际操作条件下如何运行的宝贵视角。这种现实感渗透到开发过程的各个方面，包括用户界面（UI）和用户体验设计、核心功能测试、集成测试、性能测试等。利用准确的数据可以确保系统在生产部署的复杂性和需求面前得到全面评估和准备。

精准的测试数据还在有效的错误检测和调试中扮演着不可或缺的角色。当系统在真实数据条件和使用模式下运行时，缺陷、缺点和行为不一致的问题往往会显现出来。与合成数据集或占位符数据不同，高保真测试数据包含了实际数据的全部复杂性、多样性和细微差别。这意味着，使用伪造数据或样本数据可能无法发现的问题，将在使用准确的数据集时被揭示出来。早期发现缺陷能够使问题得到及时处理，从而避免它们发展成更大的问题。

性能调优和优化是另一个精准测试数据能带来巨大价值的领域。在真实数据负载下，性能剖面和系统行为可能与使用合成数据集时观察到的有显著偏差。通过利用准确的负载测试数据，开发人员可以模拟现实世界中的使用模式和数据量，识别任何瓶颈、缓慢或容量限制。这使得精确的性能调优成为可能，从而确保系统上线时能够达到最佳的吞吐量和响应性。

此外，真实的测试数据在合规性测试中也起着至关重要的作用，确保符合监管要求。在那些要求标准合规的高度监管行业中，使用精准的真实数据进行全面测试至关重要。这能够确认系统在运行实际工作负载时，始终满足必要的合规性需求。若使用不准确的数据进行合规性测试，可能会错过生产环境中出现的违规问题。

高度准确的测试数据在开发和测试中的许多好处不容小觑。它为整个开发生命周期带来了现实感，能够主动发现缺陷，进行性能优化，并确保合规验证。在开发团队中，它还可以帮助减少新开发人员和/或新开发环境的适应时间，因为与其花时间逐步构建现实数据，不如相对快速地设置一个一致的、已知良好的数据集。花时间精心整理准确的测试数据有助于构建在生产环境中平稳运行的高度可靠的系统。这使其成为有效的 Salesforce 开发和持续交付（CD）工作流的基础支柱。

在你的环境中种植数据

向开发和测试环境中种植大量高保真、现实的数据，对于模拟 Salesforce 数据中心平台上实时生产系统的行为是不可或缺的。彻底地向沙盒环境种植具有代表性的数据，使得在现实条件下能够进行全面的验证。然而，在规模上高效完成这一任务需要精心实施强大的工具、自动化和数据建模最佳实践。

提供数据给你的环境有多种方法，我们将逐一介绍每一种方法。我们将从决定是镜像生产数据还是生成虚拟数据开始，然后查看加载这些数据的可选方案。通过本节的学习，你应该能够为你的环境准备好数据。

使用生产数据

向开发环境种植数据是一个至关重要的任务，确保在这些环境中进行的测试和开发能够反映真实的场景。在 Salesforce 中，这通常涉及将生产环境中的示例数据填充到沙盒等环境中——这是 Salesforce 默认不做的，因此需要开发人员、架构师和管理员来完成。这个过程不仅为环境提供了现实数据，还促进了对系统在类似生产环境中的行为的更好理解。

这个种植过程的初步步骤是从生产环境中提取数据。Salesforce 提供了多种工具和功能来帮助完成这一任务。提取的数据可以是生产数据的副本或其中的一个子集，具体取决于开发或测试场景的需要以及目标沙盒环境的容量。必须选择一个能够涵盖可能在生产环境中遇到的不同数据场景的代表性数据样本。

一旦数据被提取，下一步是将这些数据导入到开发环境中，如沙盒（Sandbox）。此时，Salesforce 数据加载器（Data Loader）、导入向导（Import Wizard）和批量 API（Bulk API）等工具发挥作用。它们支持不同规模的数据导入，确保开发环境中的数据能够高效且顺利地填充。我们将在本章后续部分介绍这些工具。

在这一数据种植过程中，一个关键考虑因素是敏感数据的潜在存在，特别是个人身份信息（PII）。当将数据从生产环境转移到开发环境时，确保敏感信息的安全处理至关重要。这通常需要对敏感数据进行掩码处理，以防止未经授权的访问或泄露。由于这一话题的重要性，我们将在后续章节深入探讨数据掩码技术，目前我们将集中讨论数据种植过程。

从生产环境到开发环境的数据种植是一个细致的过程，需要深入理解所涉及的工具和方法。通过在开发环境中准确复制生产数据场景，开发人员和测试人员能够更好地理解、测试和优化系统，从而在构建健壮且可靠的变更中起到重要作用。

加载生产数据时的挑战与约束

生产数据并非没有挑战和问题。Salesforce 组织通常会有各种验证规则和自动化流程（例如工作流、流程构建器或触发器），以维护数据完整性并自动化业务流程。在进行数据种植时，这些自动化流程可能会成为障碍。例如，一个组织可能会有一个验证规则，防止在“已关闭赢单”阶段插入商机，因为真实数据预计会经过整个销售过程。这在需要插入绕过这些通常阶段的测试数据时，构成了一个重要挑战。

克服这一挑战的一种方法是创建复杂的脚本，模拟记录的实际生命周期。这意味着在初始阶段插入商机，然后通过编程方式将其推进到所需阶段，最终到达“已关闭赢单”阶段。这种方法尊重现有的验证和自动化，但实施起来可能既耗时又复杂。

另一种策略是暂时禁用数据种植过程中某些验证规则和自动化。这种做法具有一定风险，因为它涉及修改生产环境的配置，必须谨慎进行。确保这些更改已被充分记录，并在数据种植后恢复至原始状态至关重要。

Salesforce 提供了一些工具和功能，允许在数据加载过程中绕过某些自动化。例如，使用数据加载器（Data Loader）并选择“插入空值（Insert Null Values）”选项，或使用特定的 API 头信息，可以帮助绕过一些自动化过程。

重要的是要理解，绕过标准的数据种子流程可能会对测试产生影响。如果种子数据没有经过通常的业务流程，它可能无法准确地代表现实世界的场景。因此，尽管绕过验证和自动化可以让数据种子过程变得更容易，但仍然需要在此过程中平衡真实测试环境的需求。

生成测试数据

如果你无法使用生产数据的副本，无论是由于政策原因还是访问限制，另一种选择是生成真实的模拟数据。起点是生成足够大且多样的合成数据集，以模仿实际业务数据的变异性。高质量的数据合成工具和库能够生成合理的对象、关系和数据量，反映出运营数据。这远远超过了有限的手动数据输入，能够更好地测试系统功能。

对于 Salesforce 环境，开发人员和测试人员可以使用多种工具和库来生成真实的数据。以下是一些值得注意的工具：

• Mockaroo：Mockaroo 是一个在线工具，允许你生成自定义数据集。它提供了一个用户友好的界面，用于设计你的数据架构，并且可以生成成千上万行真实的测试数据，这些数据可以导入 Salesforce。

• GenerateData.com：与 Mockaroo 类似， GenerateData.com 是一个在线工具，用于创建自定义测试数据的大型数据集。它还提供了定义数据结构的灵活性，这些结构可以在 Salesforce 中使用。

• Snowfakery：Snowfakery 是 Salesforce.org 设计的一个工具，用于生成真实、复杂且相关的数据，以供测试使用。它允许用户创建“食谱”，即生成数据的指令。

• 数据生成工具包：此工具可以帮助在 Salesforce 中生成复杂数据，根据预定义的架构提供真实的测试数据。

导入测试数据

将合成数据安全地导入目标 Salesforce 组织是为开发和测试准备环境的关键步骤。Salesforce 提供了多种工具来简化这个过程，每种工具适用于不同规模和复杂度的数据加载。

导入向导

Salesforce 导入向导提供了一个直观的界面，用于将较小的数据集导入 Salesforce。例如，要导入一个包含 200 个新线索的 CSV 文件，你可以导航到 Salesforce 中的线索对象，点击导入线索，然后按照步骤将 CSV 列与 Salesforce 中的相应字段进行映射。

导入向导允许您轻松地映射字段并通过几次点击启动导入，使其非常适合较为简单的数据导入或较小的数据量。一旦将 CSV 列映射到 Salesforce 字段，您只需点击导入数据。导入向导通过几次点击提供了一种用户友好的方式将 CSV 数据导入到 Salesforce。然而，这种方法也有一些限制——您一次只能导入一个对象，并且任何查找字段需要通过其底层 ID 值进行映射，因为该过程没有按名称查找的逻辑。

Bulk API

Salesforce Bulk API 旨在用于编程方式导入大量数据。例如，要导入包含 200 万个帐户记录的 CSV 文件，您可以编写一个 Python 或 Java 脚本，利用 Bulk API。该脚本将读取 CSV 文件，将数据映射到相应的 Salesforce 对象字段，然后使用 Bulk API 加载记录。

Bulk API V2 处理大规模数据加载的复杂性，如记录分批和错误恢复。因此，对于大型或复杂的数据集，推荐使用 Bulk API 而不是导入向导。通过脚本映射字段和管理导入过程，Bulk API 能够高效地将数百万条记录加载到 Salesforce 中。

Bulk API V2 还可以在一次操作中导入不同对象的记录。这个功能使 Bulk API V2 与 Salesforce 提供的更具声明性、直接的工具有所区别，但它要求架构师为数据集的成功导入做准备。

为了准备数据集进行 Bulk API V2 操作的最关键步骤是彻底了解您打算导入的不同对象之间的关系。Salesforce 数据模型通常涉及复杂的关系，例如查找关系和主从关系。确保这些关系在数据集中正确表示至关重要。这意味着需要仔细映射父子记录并理解它们之间的联系，这将显著影响导入顺序和数据的完整性。

一旦对象关系清晰，下一步是为 Bulk API V2 准备和序列化数据。此过程涉及将数据格式化为兼容的格式（通常为 CSV 或 JSON）。在这一步骤中，必须特别注意如何在数据中表示关系。例如，可以使用外部 ID 来链接相关记录，而不是 Salesforce ID，因为在导入之前，Salesforce ID 可能不可用。这一步通常涉及数据清洗和转换，以确保其符合 Salesforce 的数据标准和约束。

使用 Bulk API V2 进行多个对象导入时，或许最关键的方面是确定操作顺序。由于 Salesforce 强制执行引用完整性，父记录必须在子记录之前导入。因此，制定一个战略性的导入顺序至关重要。这可能涉及创建一个依赖关系树或层级结构，清晰地列出不同对象应导入的顺序。

虽然 Bulk API V2 能够高效处理大量数据，但在处理大数据集时，始终存在因数据质量问题或 Salesforce 限制（如治理限制）而导致错误或部分成功的风险。为这些情况做好准备，包括设置适当的错误处理和重试机制。这可能包括解析 Bulk API 的错误响应，并根据需要调整数据集或导入过程。

使用 Salesforce 的 Bulk API V2 成功导入不同对象的记录是一项复杂但可实现的任务。它需要对数据模型有深入理解，精心准备数据集，合理规划导入顺序，强大的错误处理能力以及全面的测试和验证。

下面是一个示例 Python 脚本，它将记录导入到账户对象中。该脚本使用salesforce-bulk库，你可以通过pip install salesforce-bulk将其添加到你的 Python 项目中：

from salesforce_bulk import SalesforceBulk
import csv
# Salesforce credentials
username = 'your_username'
password = 'your_password'
security_token = 'your_security_token'
# Create a new bulk API connection
bulk = SalesforceBulk(username=username, password=password, security_token=security_token)
# Define the CSV file and the object in Salesforce
csv_file = 'accounts.csv'
sf_object = 'Account'
# Create a new job for the data import
job = bulk.create_insert_job(sf_object, contentType='CSV')
# Open the CSV file and read its contents
with open(csv_file, 'r') as f:
    reader = csv.reader(f)
    csv_data = [row for row in reader]
# Split the CSV data into batches (Salesforce Bulk API has a batch size limit)
batch_size = 10000  # adjust this based on your needs
batches = [csv_data[i:i + batch_size] for i in range(0, len(csv_data), batch_size)]
# Add each batch of data to the job
for batch in batches:
    csv_batch = '\n'.join([','.join(row) for row in batch])
    bulk.post_batch(job, csv_batch)
# Close the job
bulk.close_job(job)
# Check the results of the job
job_results = bulk.get_batch_results(job)
for result in job_results:
    print(result)

数据加载器

Salesforce 数据加载器提供了一个平衡，介于易用的导入向导和完全程序化的 Bulk API 之间。数据加载器不仅支持图形用户界面（GUI），还有支持脚本集成的命令行选项，可以高效地导入从数千到数百万条记录的数据集。

例如，要从 CSV 文件中导入 75,000 条联系人记录及其相关账户数据，你需要启动数据加载器，验证你的 Salesforce 组织，选择联系人对象，将 CSV 列映射到 Salesforce 字段，并开始导入过程。

数据加载器处理批量操作并映射复杂的数据关系。因此，对于中等规模的数据集或需要一定自定义的导入，数据加载器在导入向导的简单性和 Bulk API 脚本化之间找到一个有用的平衡点。

数据加载自动化

通过脚本或软件自动化端到端的数据种植工作流程，对于提高开发环境的效率、一致性和可靠性至关重要，从而为现实测试和开发做好准备。人工过程通常较慢、重复且容易出错，因此不适合需要精度和速度的任务。相比之下，自动化通过脚本化数据生成、转换、验证和加载过程，消除了这些问题，确保每个沙盒或临时组织中的数据集完全相同，无需人工干预，从而节省时间并减少错误的可能性。

这种自动化的实际方法可能涉及编写数据生成过程的脚本，以创建一个相当大且多样化的数据集，尽可能接近实际业务数据。这个脚本可以安排在指定的时间间隔运行，或者根据特定事件触发，确保为开发和测试活动提供持续的最新数据。

数据生成后，可以实施自动化的数据转换过程，确保数据与它将要加载的 Salesforce 环境的架构和业务逻辑保持一致。这可能包括字段映射、数据类型转换和数据清理等任务，所有这些都为数据加载做好准备。同时，也要考虑数据截断——如果数据生成来自生产环境，并且数据量超出了目标沙箱的容量，当然需要特别处理。

验证是自动化工作流中的关键步骤，确保数据在加载到开发环境之前的准确性和相关性。可以开发自动化验证脚本来检查数据的一致性、完整性和是否遵循业务规则，从而确保数据具有高质量，并能代表实际场景。

数据加载过程是最后一步，在这一过程中，我们之前讨论过的一些工具，例如 Salesforce 数据加载器或 Bulk API，可以通过脚本自动化数据加载过程。例如，可以编写一个脚本，使用数据加载器导入数据，处理导入过程中出现的任何错误，并记录导入结果以供审核。这将确保数据高效且可靠地加载到 Salesforce 环境中。

这种自动化的总体好处是确保不同开发环境之间的一致性。通过脚本化整个数据播种工作流，可以确保每个环境中的数据集几乎相同，从而为测试和开发提供统一的环境。这在敏捷或持续集成/持续部署（CI/CD）设置中尤为重要，因为一致性和速度至关重要。我们说是“接近”相同，因为从生产环境提取源数据（并进行转换/屏蔽）时，根据请求的时间间隔不同，可能会导致不同的结果。

可以建立持续的数据播种设置，使开发环境始终保持更新的最新数据，这对于持续的测试和开发非常有利，尤其是在需求频繁变化的动态项目中。

处理关系

在将数据提取并导入开发环境时，您应捕捉并重建不同对象和记录之间的关系链接和依赖。Salesforce 数据具有复杂的、相互关联的关系，涉及诸如账户、联系人、机会等多个实体。如果在导入数据时不保持这些关系，可能会迅速破坏数据完整性，并导致种子数据集中的级联问题。

为了维护数据完整性，您应研究对象元数据和数据模型，以清晰地了解对象之间的关键关系和依赖。例如，联系人通过AccountId字段与账户相关联。机会与账户和联系人之间存在关系。

当您开始提取这些数据时，应该小心地一起提取相关的父记录和子记录。例如，账户应该与其子记录（如联系人和机会）一起提取。相关的ContactId和OpportunityId字段需要正确填充，以链接记录。

同样，在将数据集导入目标环境时，需要适当处理这些相同的依赖关系。这包括按正确顺序导入数据，以便提前建立依赖关系。必须先插入父记录（如账户），然后再插入子记录（如联系人和机会），并且任何用于关系的外部 ID 字段都应映射到目标环境中的字段值。

对于如连接对象和多对多关系等高级关系，映射关系字段并按正确顺序插入记录同样重要。建议测试插入的数据集以验证关系。

测试数据管理的注意事项

在这些场景中，确保数据完整性得到维护，并且在导入过程中安全地处理敏感信息至关重要。负责任地使用这些工具，并根据要导入的数据规模进行操作，将简化数据注入过程，使 Salesforce 组织为开发和测试活动做好准备。

同样重要的是对生成的数据实施严格的安全协议。以下是实现这一目标的一些步骤：

• 数据清洗：敏感信息应在用于沙盒环境之前进行匿名化或屏蔽。

• 数据保护：应通过加密、令牌化、屏蔽和类似技术来定义并实施数据安全政策。

• 数据访问：数据加载工具的访问控制应配置正确。

数据播种创建了代表性的 Salesforce 环境，以便进行真实的验证。现实的数据集、大量加载工具、自动化、建模关系和严格的安全措施是确保数据播种顺利高效的最佳实践。投资这些技术将带来更好的测试、更少的缺陷和更平滑的生产部署。

通过数据掩码保护敏感数据

在管理大量信息时，保护敏感数据是首要任务，尤其是在 Salesforce 环境中。数据掩码已经成为解决隐私、合规、安全和保密问题的关键技术，尤其是在处理测试和开发环境中的敏感数据时。

了解数据掩码

数据掩码，也称为数据混淆或匿名化，通过替换、加密或更改原始数据，使用修改过的虚构版本来保护敏感信息。这保留了数据在测试中的效用，同时消除了暴露敏感信息的风险。

常见的数据掩码方法包括以下几种：

• 静态数据掩码（SDM）：在将数据转移到测试环境之前对数据进行静态掩码

• 动态数据掩码（DDM）：在数据访问时进行实时掩码

• 格式保留加密（FPE）：加密数据同时保持原始数据格式

隐私问题

数据掩码通过确保在安全性较低的测试环境中仍然保护个人身份信息和机密数据，来维护隐私。个人和组织期望他们的数据能够得到安全处理，而掩码有助于保护这种保密性。在需要第三方承包商为客户的项目工作时，这一点尤其重要。全职员工可能有权限访问生产环境及其数据，但承包商不太可能拥有这些权限。

合规性和监管要求

数据掩码还通过遵守规定的数据保护法规来满足合规需求，例如通用数据保护条例（GDPR）和健康保险流通与问责法案（HIPAA）。这有助于与客户和利益相关者建立信任。合规不仅仅是为了避免处罚——它保持着至关重要的信任。

安全性与保密性

此外，数据掩码通过将敏感信息转换为真实但虚构的数据，减少了未经授权的数据访问和泄露威胁，从而显著降低了风险，增强了安全性。

实施数据掩码

在 Salesforce 中实施数据掩码对确保敏感信息的隐私和安全至关重要，特别是在将数据从生产环境转移到较不安全的开发或测试环境时。有几种方法可以在 Salesforce 中启用数据掩码，接下来我们将依次介绍其中的几种：

• 编程掩码：你可以编写自定义代码来实现数据掩码编程。这可以完全控制数据掩码的方式，以满足特定需求。然而，它需要对数据结构和 Salesforce 平台有深入了解，并且可能需要投入大量时间来开发和维护。

• Salesforce 数据掩码：这是 Salesforce 自有的托管数据掩码解决方案。它通过掩码敏感字段和对象（包括标准和自定义字段）来帮助遵守数据法规。可以根据数据敏感性配置不同的掩码级别，掩码后的数据无法恢复或在其他环境中以可读形式复制。数据掩码安装并配置在生产组织中，然后在从该生产组织创建的沙盒中执行掩码。这有助于保护沙盒中与生产环境相同的受管数据，如 PII，从而加快测试速度。

• 带有数据掩码的 DevOps 工具：如 Gearset 和 DataMasker 等工具具有内置的数据掩码功能。例如，Gearset 可以启动数据部署，然后根据配置的设置在加载到目标组织之前掩码选定的数据。DataMasker 可以快速掩码大型数据集，防止电子邮件和自动化事故，并帮助遵守 GDPR 和 HIPAA 等法规。它与 DevOps 工具如 Copado 集成，并提供真实的掩码格式。

这些方法提供了适应不同技术技能、资源和需求的选项。它们确保敏感信息得到保护，同时仍能在 Salesforce 环境中进行有意义的开发和测试工作——这是一个需要平衡的关键。正确的数据掩码方法是保护隐私并推动进展的关键。

合规性和最佳实践

管理测试数据以满足数据保护法并遵循最佳实践，需要细致的方法。与敏感数据相关的一些主要法规包括 GDPR、儿童在线隐私保护法（COPPA）、个人信息保护法（PIPL）、HIPAA 和加利福尼亚消费者隐私法案（CCPA），但这并不是一个详尽无遗的列表。以下是上述法规的概述：

• GDPR 对处理欧盟公民数据提出了严格要求，要求你负责任地处理数据并明确声明用途。

• COPPA 保护儿童的在线隐私，对面向儿童的网站或服务提出了具体要求。

• 中国的 PIPL 类似于 GDPR，重点保护中国公民的个人信息。

• HIPAA 与医疗保健数据相关，主要在该行业中引起注意，因为它要求安全处理患者的健康数据，概述了对机密性、完整性和可用性的保护措施。

• CCPA 强调保护加利福尼亚居民的个人信息。

除了这些规定外，还有一些最佳实践是必须遵循的。建议使用数据屏蔽来隐匿敏感细节的同时保持数据的测试效用——有些人可能会选择实施自定义方法，以在特定范围内随机化数据，从而保持一定的相关性。例如，以AnnualRevenue字段为例——虽然它是一个数字，但他们不会期望看到 1 或某个非常低的值，而是希望保持一个类似的随机数据范围。

加密在存储和传输敏感数据过程中增加了安全性。应用强大的访问控制确保只有授权用户才能查看您的数据，而基于角色的访问控制（RBAC）则实现了分层访问。将敏感数据排除在源代码管理库之外，防止未经授权的访问和泄漏，即使是无意间的。

使用屏蔽或虚拟数据时，保持数据关系和格式的完整性对于现实且有意义的测试至关重要。这包括保持引用完整性并与应用逻辑对齐，以确保测试数据不会引起任何问题或错误，从而避免在测试过程中出现假阴性。

遵守规定并遵循数据管理的最佳实践，对于安全且高效的测试至关重要。使用虚拟数据或经过屏蔽的真实数据的目标是确保隐私和安全，同时支持高效的测试和开发。谨慎的数据管理对于可靠且顺利的 DevOps 流程有着重要贡献，促进了从开发到生产的过渡，同时保持数据完整性。一个很好的最佳实践是使用 Salesforce 提供的数据分类元数据字段，并确保它们准确无误，且对新字段进行正确填充。这里的准确信息将有助于审计、屏蔽和第三方工具的使用。

工具和资源

在进行 Salesforce 的数据种植和屏蔽时，拥有正确的工具和资源至关重要。组建一个强大的工具包并与资源网络连接，可以显著提高效率，并使得有效的数据管理实践得以实现，为安全且高效的测试环境提供支持。

Salesforce 提供了强大的本地工具，如 Data Mask，用于在沙箱环境中屏蔽敏感信息，这对于测试过程中遵循数据隐私合规性至关重要。像 Salesforce Data Loader 这样的数据加载工具以及第三方工具在自动化环境之间及外部系统间的数据导入导出中起着关键作用。

额外的数据屏蔽工具，如 DataMasker 和具有内置屏蔽功能的 DevOps 工具，提供了不同的技术来保护数据的同时保持其实用性。加密工具为静态和传输中的数据增加了额外的安全层，帮助确保数据在其生命周期中的安全性。

参与在线社区、论坛、文档、培训材料、会议和专家的互动，能够提供关于 Salesforce 数据管理、数据播种、数据掩码和合规性方面最新工具、趋势和最佳实践的宝贵见解。

拥有一套量身定制的工具包，并与资源网络连接，可以帮助你成功应对 Salesforce 数据管理的复杂性。这使得组织能够通过有效的数据实践，提高效率，确保合规性，并构建安全、富有成效的测试环境。

摘要

在本章中，我们讨论了为开发环境提供准确、真实的数据的重要性，以确保在 Salesforce 中进行强有力的测试和开发。

我们探讨了使用来自生产环境的示例数据，以及另一种通过各种工具生成和导入测试数据的替代方法。

我们讨论了数据掩码的重要性，以保护敏感信息并遵守全球数据保护法规（如 GDPR 和 HIPAA），并探讨了在非生产环境中管理数据的最佳实践。

这些技术和策略可以作为一种有效的数据管理方法，应用于你的开发和测试环境。这样，你将能够充分满足组织的安全性和合规性需求，同时拥有一套工作数据，加速开发生命周期。

在下一章中，我们将开始研究市场上专为 Salesforce DevOps 设计的产品，首先深入探索 Gearset。我们将考察其功能和特点，以及它如何融入 Salesforce DevOps 工具的广泛生态中。

第十二章：Salesforce DevOps 工具 – Gearset

在本章中，我们将通过查看Gearset来开始探索 Salesforce DevOps 解决方案的市场，它是一个在 Salesforce 生态系统中广泛使用的领先 DevOps 平台。

我们将覆盖以下主要主题：

• Gearset 概述 – Gearset 及其主要功能概览

• Gearset 的优势 – Gearset 平台的关键优势分析

• Gearset 的劣势 – 探讨 Gearset 在 DevOps 方法中的一些潜在劣势

到本章结束时，你应该对 Gearset 有足够的了解，以便能够决定它是否是适合你 Salesforce DevOps 需求的平台。

技术要求

本章的明显技术要求是，如果你希望跟着本章内容进行操作，你需要一个 Gearset 许可证。如果没有许可证，你可以通过gearset.com获得一个为期 30 天、功能齐全的免费试用版来试用。

Gearset 概述

Gearset 于 2015 年诞生，是一个专为 Salesforce 生态系统内的发布管理设计的工具。它由一支来自微软开发生态系统的团队创建，他们对 Salesforce 缺乏类似于微软世界中的 DevOps 工具感到惊讶。随着 Gearset 的成长和成熟，它提供了一整套全面的功能，涵盖了部署和数据管理的各个方面。

Gearset 的核心功能是它能够快速可靠地部署变更。通过简化部署过程，Gearset 使用户能够更多地专注于发布管理的战略层面，而不是陷入复杂的过程中。

该平台将多个关键功能整合在一个平台上，提供无缝和集成的体验。这种集成不仅简化了工作流程，还确保用户可以访问广泛的工具，这些工具对于有效的发布管理至关重要。从自动化发布流水线到提供先进的数据管理和备份能力，Gearset 提供了一个强大而多功能的解决方案，满足 Salesforce 专业人士的多样化需求。

Gearset 全面的功能集，加上直观的设计，使其成为希望优化 Salesforce 部署流程的专业人士不可或缺的工具。让我们现在来看看一些功能，这些功能按照它们最相关的 DevOps 领域进行分组：

功能类型	功能	描述
部署	实时元数据比较	允许用户查看即时的比较结果，并通过逐行差异查看，突出显示元数据、Apex、HTML 等方面的变化
	版本控制支持	支持部署到任何基于 Git 的版本控制仓库，包括本地选项
	部署回滚	使用户能够轻松回滚不需要的元数据更改
	完整的部署历史	用户可以注释部署并查看每次更改的详细报告
自动化	部署管道	提供完整的发布管道可视化和管理，具有强大的集成能力
	持续 集成 (CI)	促进在 Salesforce 上最可靠的 CI，简化交付过程
	监控	跟踪每日组织快照和变化，确保没有被覆盖
	单元测试	自动化 Apex 测试，跟踪代码覆盖率和测试状态，并提醒用户失败的测试
数据管理	数据种子	允许用户从 Salesforce 组织中选择特定数据并将其部署到其他环境，保持对象之间关系的完整性
	智能关系处理	自动检测和处理父子关系及循环引用
	数据迁移工具	允许在一次运行中部署多个对象的记录，查看数据部署历史，并共享部署模板
	支持 Salesforce 配置、定价、 报价 (CPQ)	部署复杂的 CPQ 配置数据和 CPQ 记录
	数据掩码	掩盖敏感数据以确保保密性和合规性
备份	自动备份	对数据和元数据的频繁备份，最小化数据丢失
	快速恢复	允许轻松恢复丢失的记录或整个组织
	分析和警报	提供浏览备份、跟踪趋势以及配置异常变化的警报功能
	安全性与控制	提供加密密钥管理和与Amazon Web Services (AWS)的安全数据存储

表 12.1 – Gearset 在 Salesforce DevOps 各关键领域的能力

如您所见，Gearset 是一个全面的 Salesforce DevOps 平台，涵盖了成熟解决方案的核心需求。接下来，我们将更详细地了解它的工作原理，识别其关键优势和任何不足之处。

Gearset 的优势

Gearset 技术的核心是其元数据比较引擎，它可以快速识别源和目标元数据集之间的变化，无论是在源控制中还是在 Salesforce 组织中，双向都能处理。这使得 Salesforce 从业人员能够快速查看发生了什么变化，并将其构建成部署内容或提交到源控制的一组更改，界面直观易懂。在下图中，我们可以看到 XML 元数据的逐行对比：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_12_1.jpg

图 12.1 – Gearset 的 XML 元数据比较。此截图的目的是展示页面布局；文本的可读性并不是重点。

相比之下，下一张截图展示了一个更丰富的用户界面，用于管理选项列表值元数据：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_12_2.jpg

图 12.2 – Gearset 的选择列表值比较，使用自定义用户界面代替 XML

Gearset 吸引力的核心在于其对 Salesforce 元数据的深刻理解，使用户能够以极为详细和深入的方式管理和部署变更，这在 DevOps 工具领域是罕见的。这一能力在处理复杂部署时尤为重要，因为这类部署常常伴随挑战和风险。

因此，Gearset 的元数据处理能力不仅仅是一个功能；它代表了 Salesforce 部署管理方式的根本变化，使部署变得更加易于访问，且减少了错误的发生。Gearset 对减少错误的承诺最直接的体现就是其问题分析器，它会检查每个部署中的工件，找出可能阻碍部署成功的问题。通过将静态代码分析与对元数据依赖关系和常见问题的理解相结合，许多问题不仅能得到预防，还能在实际部署之前自动解决。下一张截图展示了 Gearset 如何识别出一些问题：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_12_3.jpg

图 12.3 – 问题分析器检测问题

点击查看所有按钮可以查看具体问题并解决它们，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_12_4.jpg

图 12.4 – 问题详情及在 Gearset 中自动解决问题的选项

除了基本的部署功能，Gearset 在持续集成（CI）和测试方面表现出色。在软件开发中，保持高质量的代码标准至关重要，而 Gearset 在这一领域的工具确保这些标准不仅得到满足，而且始终如一地保持。通过自动化测试和集成过程中的关键环节，Gearset 帮助团队专注于开发，而不是被测试和集成的繁琐机制所困扰。这一自动化功能是一个改变游戏规则的工具，尤其对那些在大型或复杂 Salesforce 项目上工作的团队而言，错误发生的风险较大。

Gearset 的旗舰自动化功能被称为管道（Pipelines），它是一个可视化的表示，展示了构成你持续集成和持续部署（CI/CD）管道的各种环境和代码库（因此得名），使团队能够更高效地管理整个发布管道。它与版本控制工具和 Jira 等工具无缝集成，并提供先进的分支管理功能，可以同时处理多个分支：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_12_5.jpg

图 12.5 – 一个示例的 Gearset 管道视图，显示 Git 提交等待在不同环境之间移动。此截图的目的是展示页面布局；文本可读性并不重要。

Gearset 的数据备份和恢复功能解决了 Salesforce DevOps 中的另一个关键需求——数据安全。在数据不仅具有价值而且容易受损的时代，拥有强大的备份和恢复机制是不可妥协的。Gearset 对数据备份的方法全面，确保数据不仅安全备份，而且在丢失或损坏时易于恢复。这种数据安全和管理水平是一个重要的优势，为 Salesforce 团队提供了安心和运营稳定性：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_12_6.jpg

图 12.6 – Gearset 数据备份作业

作为 Salesforce DevOps 平台，Gearset 的优势根植于其对 Salesforce 管理的全面性方法。它不仅仅是一个工具；它是一个全面解决 Salesforce DevOps 多方面挑战的解决方案。从部署到测试，从数据管理到恢复，Gearset 作为一个理解并有效应对 Salesforce DevOps 社区需求的平台脱颖而出。

Gearset 的弱点

有人看到优势，有人看到弱点，而 Gearset 在这方面并不免疫，特别是与其他 Salesforce DevOps 解决方案相比较时——这在组织开始他们的 DevOps 之旅并确定最适合其需求的解决方案时经常发生。

可灵活选择您希望如何管理 DevOps 流程的方法，这在需要更多指导和协助的团队看来往往被视为弱点。同样，虽然有些人认为 Gearset 作为一个独立于 Salesforce 平台并通过 API 集成进入的应用程序具有优势，但其他人则认为它不是 Salesforce 原生应用程序是一个弱点。

Gearset 专为 Salesforce 核心平台量身定制，同时支持诸如CPQ和 Salesforce Industries（之前称为Vlocity）的功能。对于寻求覆盖不仅其他 Salesforce 产品（或“云”），而且其他非 Salesforce 平台的全能 DevOps 解决方案的团队来说，Gearset 可能并不是最佳选择。一些技术领袖更倾向于投资于整体 IT 资产的全能解决方案。

对于更高级的 DevOps 从业者来说，缺乏直接的代码编辑能力和 API 访问限制了与其他工具的集成以及在更脚本化的方式上自动化某些流程，这在其他解决方案中是可能的。

以下是这些观点的总结，以帮助您的决策过程：

弱点	描述
DevOps 管理的灵活性	Gearset 在 DevOps 管理方面的灵活性被认为是一个劣势，尤其是对于那些需要更具指导性和特定方法论的团队。
非 Salesforce 原生	作为一个外部应用而非 Salesforce 原生应用被认为是一个缺点，因为它通过 API 集成，而不是直接集成在 Salesforce 平台内。
功能范围有限	Gearset 针对 Salesforce 核心平台量身定制，支持 CPQ 和 Salesforce Industries 等功能，但它并不是一个覆盖更广泛 Salesforce 产品或非 Salesforce 平台的全能型解决方案。
限制的高级 DevOps 功能	缺乏直接的代码编辑功能和受限的 API 访问被视为对需要更深入集成和自动化能力的高级 DevOps 用户的一种限制。

表 12.2 - Gearset 弱点总结

总结

Gearset 已成为专门为 Salesforce 生态系统量身定制的领先 DevOps 解决方案。其全面的功能集使其能够满足与部署、测试、数据管理以及备份/恢复相关的广泛需求。Gearset 简化并优化了诸如元数据部署和持续集成（CI）等流程，减少了手动操作并最小化了错误。这种高效性不仅来自于自动化常规任务，还得益于 Gearset 对 Salesforce 元数据的深入洞察。

虽然有些人可能会认为 Gearset 相较于更广泛的、全能型 DevOps 平台，其灵活性和专注于 Salesforce 的方法是劣势，但 Gearset 无疑在管理核心 Salesforce 开发和发布流程方面表现出色。对于那些希望优化 Salesforce DevOps 工作流的团队来说，很少有工具能与 Gearset 在强大功能与直观可用性上的结合相匹敌。随着 Salesforce 项目的规模越来越大，复杂性也在增加，Gearset 提供了可靠性和精确度，使得团队可以自信地发布更新。对于大多数 Salesforce 团队来说，Gearset 应该是一个值得考虑的 DevOps 解决方案。

在接下来的章节中，我们将探讨 Salesforce DevOps 领域的另一个主要参与者：Copado。我们将以类似的方式，分析它作为一个即用型解决方案在 Salesforce DevOps 中的关键优势和劣势。

第十三章：Copado

本章将深入探讨 Copado 的关键功能和能力，涵盖其底层数据模型和管理。我们将研究 Copado 如何通过自动化和简化任务，如版本控制、构建自动化、测试和部署，来解决 Salesforce 开发中的挑战。我们还将探讨 Copado 如何与 Salesforce 本地对象集成，以实现集中式报告和过程监控。

除了探索 Copado 的技术能力外，我们还将讨论平台的优势和不足；理解这些对考虑实施 Copado 的组织至关重要，因为它有助于他们对齐预期并有效规划资源。

本章将涵盖以下主题：

• Copado 概述

• 了解 Copado 的优势

• 探索 Copado 的不足之处

到本章结束时，你将全面了解 Copado 及其在 Salesforce DevOps 中的角色。你将获得的见解将帮助你做出有关如何在自己的 Salesforce 环境中利用 Copado 的明智决策，并帮助你更轻松、高效地应对 Salesforce 开发中的复杂性。

Copado 概述

Copado 提供一个端到端平台，用于在Salesforce中应用DevOps原则和实践进行开发。作为一个建立在 Salesforce 平台上的原生应用，Copado 旨在解决 Salesforce 核心产品中的一些缺口，这些缺口妨碍了持续集成和交付（CI/CD）的有效实施。本概述将详细介绍 Copado 的底层数据模型、关键技术能力以及基于公开文档的管理。

Copado 允许团队完全在 Salesforce 内部实现 DevOps 工作流，而无需广泛使用外部工具。它集成了版本控制、构建自动化、测试和部署，同时保留了本地报告和过程可视性。平台围绕一个核心抽象层展开，自动处理许多复杂任务，如分支管理。

平台

Copado 利用以用户故事为中心的数据模型，即以用户故事为中心的部署模型，将任何需求与特定的元数据变更关联。用户故事实体将代码与其业务目的和工作范围相关联，以实现增量交付。故事通过预定义的管道流动，从低级开发环境一直延伸到生产环境，类似于其他配置管理数据库。以下截图展示了一个示例管道：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_13_01.jpg

图 13.1 – Copado 管道示例

Copado 平台通过使用语义冲突解决引擎，在复杂的Git分支和合并操作之上进行抽象。这避免了开发者需要手动处理合并冲突和 Git 命令。相反，平台通过使用从低环境到高环境流动的流水线以声明性方式处理分支。

Copado 中的所有用户操作都与本地 Salesforce 对象集成，以便集中报告和流程监控。这保留了审计性和可见性，用户可以在管理员已经熟悉的 Salesforce 界面内进行操作。不需要外部仪表板或报告来监控 DevOps 流程。

Copado 的功能涵盖了整个 DevOps 生命周期，从初始需求到生产部署：

• 用户故事的需求管理

• 自动化版本控制

• 持续集成，触发质量门控

• 协调的环境间提升

• 部署流水线配置

• 通过回传促进组织同步

• 内置可见性和报告

这些功能共同为开发团队提供一个全面的系统，帮助团队在 Salesforce 中实现敏捷、迭代的 DevOps 模式。

版本控制

Copado 通过自动为每个用户故事提交的元数据组件创建功能分支，来集成 Git 版本控制。精确的分支结构反映了用户故事在不同 Salesforce 沙箱和环境之间流动的进程，这些环境在流水线中有定义。

以下截图展示了与版本控制的集成：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_13_02.jpg

图 13.2 – Copado Git 集成

双向部署和分支合并确保所有环境和沙箱在变化通过测试和生产过程中上下游流动时保持同步。开发者和管理员无需进行手动的 Git 操作。

Copado 的冲突检测利用语义分析来处理元数据，而不仅仅是语法代码对比。这使得它能够检测组件之间的逻辑冲突，这些冲突可能无法合并，比如冲突的字段级安全规则。平台会提前警告用户这些冲突，以避免部署失败。

管理员可以通过 Copado 中的流水线定义组织的分支策略和环境拓扑，而无需了解 Git 的内部机制。复杂性被隐藏在抽象层下。

构建集成

持续集成是 Copado 的关键功能。在每次代码提交或提交操作时，平台可以自动触发配置的测试、验证和其他质量门控。这些可以包括 Apex 测试、代码检查、静态分析或任何其他自定义步骤。

测试和验证的输出直接记录到 Salesforce 中相关的用户故事中，以便追踪。开发人员可以立即看到结果，无需单独的 CI 服务器。您可以通过原生报告保持代码质量的合规性。

第三方工具，如Jira和Azure DevOps，可以通过内置的 Webhooks 或自定义的Apex适配器与 Copado 的 CI 管道集成。自定义插件允许管理员修改和定制 Copado 的标准 CI/CD 流程，以插入自定义质量门。例如，您可以配置一个 Webhook，在代码部署到 UAT 或生产环境之前，通过其 API 调用您首选的安全扫描工具。

Copado 旨在通过将左移测试和质量保证自动嵌入提交过程中来推动左移测试。强制性门确保所有提交的代码通过一致的自动执行保持在最低质量标准上。

部署

在部署过程中，Copado 引入了“推广”概念，用于在管道中移动用户故事之间的环境。推广通过声明性的 Copado 界面定义的管道向下拉取元数据更改。

以下截图展示了一个示例用户故事：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_13_03.jpg

图 13.3 – 一个示例的 Copado 用户故事

权限方案授予在管道阶段之间推进所需的批准。强制性的手动审批门可以确保任何更改都已获得授权。Copado 的选择性回滚功能还可以重新部署以前的元数据提交（根据需要），以快速恢复生产环境。

重要说明

“阶段”被分类为具有相似业务角色的环境集合，如开发、测试、生产等。它们为发布经理提供了以视觉和系统化的方式组织其管道和环境的能力。此外，阶段还便于在执行时配置和操作各种功能。例如，在涉及质量门规则、自动化规则或使用 Copado 的持续交付和部署步骤的场景中，可以选择在特定阶段应用这些流程。

连接行为配置了额外的操作，例如在管道的每个阶段执行的自动电子邮件通知。例如，您可能希望所有生产部署都向安全审核员发送电子邮件。行为标准化了这些过程。

推广将代码移动与审批和通知政策结合起来，以避免影子 IT（非 IT 员工执行 IT 任务），并实现合规性。回滚通过允许在发现问题时自动将不安全的更改从环境中移除，从而降低风险。

环境

Copado 保持 Salesforce 沙盒在严格的事务同步状态中，无需重复的手动刷新操作。在低环境之间刷新会在开发工作流中造成显著的摩擦。

重要提示

回退推广是一个旨在将用户故事从高环境传输到低环境的过程，具有三个主要目的：它通过保持一致的更改确保跨环境的同步，促进将生产环境中的热修复传播到下游环境，并通过推荐回退推广来减少合并冲突，从而简化集成。

相反，回退推广（见提示）会根据需要自动将上游代码更改合并到下游环境。平台持续监控每个组织的部署准备状态，然后执行下游分发。

有限的金丝雀发布将新元数据的子集引入沙盒，以便在完全分发之前进行增量发布。这限制了风险，并允许对较小的更改批次进行测试。

这些功能的结合使开发人员能够在无需刷新页面的情况下访问最新的共享更改，即使更新持续流向生产环境。它提供了一个紧密的内部开发循环。

变更管理

在此语境中，变更管理指的是控制用户权限和访问权限的能力；这在 Salesforce 中构成挑战，因为权限和访问控制分布在各个互联的元数据实体中，如配置文件、权限集和字段级安全规则。

Copado 中的完整配置文件部署将所有相关元数据封装为一个原子单元，作为一个整体来部署配置文件。这避免了随着更改传播，权限不同步的情况。类似地，权限集在各环境间保持一致的字段级访问。

该平台跟踪所有修改，将它们归因于特定的开发人员、用户故事和承诺，以便进行完全的审计。您可以生成关于敏感配置或属性（如记录所有者）的详细修改报告。

总结来说，变更跟踪在变化双向流动的过程中保持安全合规性和配置完整性，避免了多次部署可能带来的碎片化。相关的元数据作为一个整体包部署。

管理

Copado 的一个关键目标是实现无需 extensive 培训或专业化的实施。所有配置都利用类似于 Salesforce 核心界面的声明式、点选式自定义。已经熟悉 Salesforce 的用户会发现该工具直观易用。

报告与 Salesforce 核心对象（如用户故事和推广）集成，生成流程指标和仪表盘，以便于可视化。预构建模板开箱即用。

管理员通过使用与 Salesforce 核心相同的工具来监督访问控制、使用策略和其他平台治理。变更集可以在环境之间推送策略，个人资料控制访问权限。

最终，Copado 管理的声明性特点保持了较低的学习曲线。随着实践的成熟，组织可以在不打断的情况下逐步优化角色和权限。

Copado 提供了一个可扩展的平台，用于通过不可变基础设施和基础设施即代码等实践实施 Salesforce 应用程序的持续部署。它的核心价值来源于 Salesforce 平台固有的部署复杂性的本地集成和自动化处理。

总体而言，Copado 旨在消除在 Salesforce 开发中实施现代 DevOps 实践时的许多重复性任务和障碍。通过提供版本控制、CI/CD 和环境管理，它使团队能够扩展敏捷和迭代开发。Salesforce UI 中的整合简化了采用过程。

机器人测试

旨在显著减少开发和部署测试用例所需的时间和精力，Copado 机器人测试（CRT）提供了测试用例的详细分析，增强了测试过程的有效性。作为一个主要的云解决方案，它可以通过 www.robotic.copado.com 访问，同时也具有作为本地服务的灵活性。为了满足多样化的用户群体，CRT 提供了一个有限的免费版本，非常适合用来学习和理解该框架。

CRT 的突出特点之一是它在为广泛应用编写测试用例方面的多功能性。这包括基于 Web 的应用程序、移动应用程序、Salesforce 应用、ServiceNow 应用、SAP 系统、简单网站和 REST API。它作为低代码和专业代码平台的双重特性使其特别易于使用；即使用户没有广泛的测试脚本语言或框架知识，也能凭借其基于关键词的开发功能高效开发测试用例。

CRT 通过其实时测试和视频流测试用例执行的功能，进一步简化了测试过程。此功能显著加速了调试过程，允许实时识别和解决问题。此外，该框架还提供了根据组织政策安排测试用例执行的灵活性。

总结来说，Copado 机器人测试作为一个全面、灵活且高效的自动化测试框架，在适应广泛应用和不同用户专业水平方面表现突出。其结合了实时测试能力、集成选项和对测试基础设施的结构化方法，使其成为软件开发和质量保证领域的宝贵工具。

理解 Copado 的优势

Copado 成立于 2013 年，已经发展成为一个领先的端到端 DevOps 平台，专为 Salesforce 开发和发布管理量身定制。凭借来自 Salesforce Ventures 和其他投资者的可观增长资本，Copado 提供了一整套全面的功能，支持并加速 Salesforce 部署。

Copado 的一个关键优势是它与 Salesforce 平台的深度原生集成。Copado 最初是为了应对当前市场中的一个巨大需求而构建的：帮助支撑 Salesforce DevOps 生命周期。

通过原生构建在 Salesforce 上，Copado 继承了该平台的安全性、认证以及其他优势，同时保持开发与运维之间的紧密集成。这与其他在 Salesforce 外部运行的工具形成对比，后者可能会导致集成问题。

与此相关，Copado 的元数据智能让它在理解依赖关系、检测冲突和合并 Salesforce 环境中的更改方面具有优势。Copado 的“秘密武器”在于它能够（代表你）通过转换用户故事之间的一对一关系，在特定功能的分支上构建分支。

重要提示

合并冲突发生在两个更改分别在不同环境中对相同的元数据组件进行修改，且无法自动和解时。

Copado 并非在文件层面工作，而是在元数据 API 层面操作，这使它在合并和部署更改时具有优势。这有助于解决用户在处理 Salesforce 元数据时常遇到的合并冲突问题。

Copado 在提供端到端应用生命周期管理方面同样表现出色，不仅仅是部署。它的缺陷追踪、用户故事、流水线和工作流支持开发团队从构想到发布的规划、协调和跟踪工作。例如，Jira 工单会转化为 Copado 用户故事，将开发工作与下游发布流程连接起来。这可以通过将业务需求与开发者的努力相连接，来加速开发。

对于较大的开发团队来说，Copado 在功能和集成方面难以匹敌。它结合了 Salesforce 平台的优势与 Heroku 可扩展的基础设施，用于计算密集型任务，如元数据处理。Heroku 架构在提供必要性能的同时简化了安全审计。这使得 Copado 能够提供 应用生命周期管理 (ALM)、测试、合规性和其他大多数部署工具无法提供的功能。

探索 Copado 的弱点

Copado 已经成为一个强大的解决方案，提供一整套支持 Salesforce 开发生命周期各个方面的功能。然而，和任何工具一样，它也有其局限性和挑战。本节将探讨这些潜在的弱点，提供平台能力与局限性的平衡视角。

与 Copado 相关的一个关键挑战是其复杂性。该工具提供了广泛的功能和能力，这对于新用户来说可能会感到不知所措。有效利用所有功能所需的学习曲线可能很陡峭，这可能会减慢实施和采纳的速度。

一个相关问题是，将 Copado 集成到现有的 Salesforce 和 CI/CD 生态系统中，尤其是那些具有复杂技术堆栈的系统，可能会有一定的困难。与各种工具的兼容性和无缝集成可能需要额外的配置和努力，对于资源有限的团队来说，这可能是一个挑战。

此外，Copado 需要持续的维护，以使其与 Salesforce、您的 CI/CD 管道以及组织不断变化的需求保持一致。管理这些持续的变化可能会耗时，并且可能会加剧资源压力，尤其是对于较小的团队来说。

Copado 的另一个潜在弱点是其处理后端处理的方式。尽管使用 Heroku 进行后端处理使 Copado 能够利用 Heroku 在元数据检索、处理和部署方面的强大功能和速度，但它也有启动成本。如果 Heroku 用于从代码库部署元数据，首先必须克隆该元数据，这就为每个作业带来了一定的性能成本。

然而，值得注意的是，Copado 声称已优化此过程，仅获取最小的历史记录来启用合并。但即便如此，启动成本仍可能成为潜在的瓶颈，尤其是在更大规模的部署中。

此外，虽然 Copado 使用 Salesforce 作为其用户界面和数据存储提供了一些好处，但它也带来了一些挑战。例如，所有日志和其他文件都作为附件存储在 Salesforce 包中，这可能使得它们难以阅读。此外，由于 UI 是基于 Salesforce 构建的，一些用户可能觉得它看起来略显笨拙，并且可能并不总是提供最直观的用户体验。

此外，Copado 关于作业结果的通知并不总是显而易见，这可能导致混淆或错过通知。特别是在 DevOps 环境中，关于部署、测试和其他过程的及时通知至关重要。举例来说，下面是一个未正确更新的通知截图，因此，它被标记为完成，但既未完成也未成功：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_13_04.jpg

图 13.4 – 一个停滞的 Copado 通知

最终，虽然 Copado 无疑是一个强大而全面的 Salesforce DevOps 工具，但它并非没有挑战。了解这些潜在的弱点对于考虑实施 Copado 的组织至关重要，因为这使得他们能够为这些挑战做好计划，并确保他们具备必要的资源和策略来克服这些挑战。

总结

总之，Copado 提供了一套强大且全面的 DevOps 工具，专门为 Salesforce 设计。通过深度的原生 Salesforce 集成，它有效地填补了平台中的空白，自动化了版本控制、CI/CD 和环境管理等复杂任务。

它以用户故事为中心的数据模型和与第三方工具的无缝集成，使其成为敏捷和迭代开发的宝贵资产。然而，像任何工具一样，它也有其局限性。复杂性和陡峭的学习曲线可能对新用户构成挑战。此外，通过 Heroku 进行的后台处理，虽然强大，但可能会为较大规模的部署带来性能成本。

尽管存在这些潜在的障碍，但通过适当的规划和资源，Copado 可以显著简化 Salesforce 开发和发布管理，成为组织在提升 Salesforce DevOps 生命周期方面的一个值得关注的选择。

为了解决 Copado 的复杂性和学习曲线带来的挑战，采取一种战略性的方法，包括彻底的培训和资源分配是至关重要的。组织可以为团队投资全面的培训项目，重点培养实际操作经验和现实场景中的技能，以提高熟练度。利用 Copado 丰富的文档和社区资源也能帮助这一学习过程。此外，逐步实施的策略有助于团队逐步适应工具的复杂性，从基本功能开始，逐步过渡到更高级的特性。

关于通过 Heroku 进行后台处理时与较大规模部署相关的性能成本，优化 Heroku 内的配置和扩展策略可以缓解这些问题。这可能包括利用更高效的资源分配，优化工作流以提高性能，并确保 Heroku 环境针对部署的特定需求进行定制。此外，定期监控和审查性能指标有助于及时识别并解决任何低效问题。通过解决这些方面，组织能够充分发挥 Copado 的潜力，使其成为 Salesforce DevOps 工具包中的强大资产。

通过这些措施，Copado 的优势能够得到充分体现，克服其初期的障碍，为 Salesforce 开发和发布管理提供一个简化且高效的解决方案。在接下来的章节中，将介绍 Flosum，这是 Salesforce DevOps 领域中的另一款工具，并探索其特点和功能。

第十四章：Salesforce DevOps 工具 – Flosum

Flosum 是 Salesforce DevOps 生态系统中的重要参与者之一，提供了一套旨在增强和简化开发过程的工具。本章深入探讨了 Flosum 的多面性，探索其模块、集成功能以及在 Salesforce 生态中的独特地位。

我们的旅程将揭示，Flosum 的原生 Salesforce 平台构建不仅有助于无缝集成，还允许显著的定制和扩展性。

我们将涵盖以下主要内容：

• Flosum 概述 – Flosum 及其关键功能概览

• Flosum 的优势 – Flosum 平台的关键优势分析

• Flosum 的弱点 – 观察 Flosum 在 DevOps 方法中的一些潜在弱点

本章结束时，您应已充分了解 Flosum，以便决定是否将其作为您的 Salesforce DevOps 需求的合适平台。

技术要求

如果您希望进一步探索 Flosum，并通过其网站 flosum.com 提供的产品演示，您可以通过开始 Flosum 专家认证，在 success.flosum.com 获取试用 Flosum 实例。

Flosum 概述

正如您所期望的，Flosum 作为一款现代化的 Salesforce 特定 DevOps 解决方案，提供了涵盖 Salesforce DevOps 主要方面的广泛功能。在本节中，我们将探讨这些核心元素，并看看 Flosum 如何应对它们。

部署

Flosum 提供的核心是其 DevOps 模块，这是一个全面的套件，旨在促进整个开发生命周期。它提供了一个集成的环境，用于管理代码、配置和持续集成，从而简化了交付过程。

Flosum 在部署和变更管理方面的方法既创新又实用。它有效地处理部署前后的变更，将修改视为增量分支。这种粒度确保只有相关变更被部署，从而最大限度地减少错误风险并提高部署效率。

Flosum 中的“域”功能彻底改变了多生产组织的管理，提供了结构化和统一的方式。与此并行，部署经理作为关键工具，协调不同 Salesforce 组织之间的部署，简化了本来复杂的任务。

Flosum 的高级功能，如预部署修复能力和覆盖保护，展示了其复杂性。这些工具能够主动识别并解决常见问题，如 API 版本不匹配，从而提供更简化的部署过程。类似 Git 的拉取请求的同行评审过程，进一步强调了 Flosum 在促进协作和无错误开发方面的承诺。

Flosum 独特的地方在于它管理配置文件和权限集的方式。它支持部分检索和部署，只关注当前分支相关的组件。这种特定性不仅节省时间，还减少了部署的复杂性。

Flosum 的 DevOps 工作流以多功能性为特点，提供两种主要的操作方法 —— 通过 Salesforce Tooling API 进行源代码跟踪 和 基于快照的差异跟踪。源代码跟踪功能利用了 Salesforce 自身的源代码跟踪功能，该功能是为 Salesforce DX 引入的，并且在 Flosum 中以相同的方式工作，而快照功能不仅有助于识别变化，还能促进高效的回滚，增强了开发过程的整体稳定性。下面是 Flosum 中的一个示例快照：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_14_01.jpg

图 14.1 – Flosum 组织快照

注

上图中的文本细节最小化，并且与图形展示无直接关系。请参考免费下载的电子书以访问图形中的详细信息。

Flosum 中的部署验证过程非常细致，生成了全面的元数据日志。这个日志作为一个关键记录，提供了每次部署历史的洞察，帮助未来的审核和分析。下图展示了与部署相关的广泛元数据日志示例。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_14_02.jpg

图 14.2 – 最近的部署，显示自动生成的元数据日志

注

上图中的文本细节最小化，并且与图形展示无直接关系。请参考免费下载的电子书以访问图形中的详细信息。

Flosum 对管道和自动化的处理方式既灵活又强大。用户可以创建单独的自动化流程，并根据需要对它们进行编排，而不必受限于固定的顺序。这种灵活性使得团队能够根据特定项目需求调整他们的 DevOps 流程。下图展示了一个示例管道，完整地呈现了自动化流程的可视化表示。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_14_03.jpg

图 14.3 – 示例自动化管道

注

上图中的文本细节最小化，并且与图形展示无直接关系。请参考免费下载的电子书以访问图形中的详细信息。

部署管理器是 Flosum 对 CI/CD 编排的回答。它允许自动化管道的堆叠，提供了一种集中高效的方式来管理跨多个项目和环境的持续集成和交付。

信任中心

信任中心作为 Flosum 安全性的基石，提供了强大的工具来监控和确保合规性。该模块定期扫描 Salesforce 组织，生成任何检测到的安全漏洞或政策违规的警报，是 Flosum 对安全和合规承诺的体现。它不仅监控 Salesforce 组织的潜在安全漏洞，还自动生成违规警报和修复变更。Flosum 采取这种积极的安全策略，确保组织始终保持合规和安全。

备份和数据迁移

认识到数据完整性的重要性，Flosum 的备份和数据迁移模块为全量和增量备份提供了强大的解决方案。该模块支持大对象和二进制数据，确保全面的数据保护。

集成和自定义

Flosum 的集成功能证明了它的灵活性。虽然它提供了内置的源代码控制和票务追踪工作流，但它还可以与外部应用程序（如 Jira 和 Azure DevOps）连接，增加了灵活性，而 Flosum Scan 和 AccelQ 涵盖了代码扫描和回归测试的全方位功能。分支管理功能如权限设置、同行评审和合并跟踪，进一步证明了 Flosum 对简化和安全 DevOps 流程的承诺。这种互操作性使团队能够在现有工作流中利用 Flosum，从而提高生产力，而不会打乱已建立的流程。

Flosum 原生构建在 Salesforce 平台上，提供了前所未有的可扩展性。用户可以根据特定需求定制报告、仪表盘和布局，确保高度个性化和高效的 DevOps 体验。这种自定义不仅限于外观，还允许团队根据其独特的工作流需求调整工具。

通过使用 Salesforce 的全面报告和仪表盘功能，Flosum 提供了有关部署指标的重要见解。这些工具对于跟踪进展、识别瓶颈以及做出数据驱动的决策至关重要。

现在让我们总结一下这些功能，按照每个功能最相关的 DevOps 领域进行分类。

功能类型	功能	描述
源代码控制 管理	内置源代码控制	提供集成的源代码控制系统，允许在 Salesforce 环境中有效管理代码变更、版本控制和协作。
	与外部工具的集成	支持与外部源代码控制工具（如 GitHub）集成，使团队能够在保持现有工作流的同时，利用 Flosum 的能力。
部署 管理	部署管理器	一个关键工具，用于跨多个 Salesforce 组织编排复杂的部署，简化部署过程。
	基于快照的差异跟踪	使用 Salesforce Org 的定期快照跟踪变更，帮助识别差异并在需要时进行回滚。
安全和合规性	信任中心	监控 Salesforce Org 的安全违规和策略违规，提供警报和自动化修复更改，确保合规性。
	覆盖保护	包括带有内置合并编辑器/差异查看器的合并冲突管理，增强代码集成的安全性和准确性。
备份和恢复	备份和数据迁移工具	提供完整和增量备份 Salesforce 数据的解决方案，确保数据完整性和可用性，用于灾难恢复。
代码质量和测试	Flosum 扫描	内置的代码扫描器，有助于在开发过程早期保持高代码质量并识别潜在问题。
	与 AccelQ 的集成	支持与 AccelQ 的集成，进行全面的回归测试，确保 Salesforce 应用程序的可靠性和稳定性。
协作和审阅	同行审阅框架	促进协作的代码审阅流程，类似于 Git 的拉取请求，允许逐行评论和彻底审查。
	分支权限和合并跟踪	有效管理分支权限并跟踪合并，确保受控和安全的开发实践。
自动化和效率	自定义流水线和自动化	允许创建和编排自定义流水线和自动化，为特定项目需求量身定制 DevOps 过程。
	部分检索配置文件和权限集	允许选择性检索和部署与分支组件相关的配置文件和权限集，提升效率。
报告和见解	部署指标的报告和仪表板	提供全面的报告和仪表板，提供关键的部署指标见解，支持数据驱动的决策制定。

表 14.1 – Flosum 的 DevOps 能力摘要

现在我们已经看到 Flosum 提供的各种 DevOps 功能范围，让我们深入了解产品的优势和劣势所在。

Flosum 的优势

Flosum 在许多领域都表现出色，肯定能满足大多数 Salesforce 团队的需求。以下是此平台的一些关键优势：

• 与 Salesforce 的原生集成：为习惯于 Salesforce 的用户提供无缝兼容性和直观的用户体验，简化操作并增强用户体验。

• 全面的工具集：包括源代码控制管理、部署自动化、备份和恢复以及安全和合规性监控功能，涵盖广泛的 DevOps 流程。

• 定制化和可扩展性：它允许广泛定制报告、仪表板和布局，以满足特定的工作流需求，适应多样化的团队需求。

• 高级部署管理：部署管理器能够处理复杂场景，包括管理多个 Salesforce Org，简化部署生命周期。

• 安全性和合规性：它具备一个信任中心模块和其他安全功能，提供强大的安全监控和合规性，保持数据完整性并遵守监管标准。

• 与外部工具的集成：它兼容 GitHub 和 Jira 等工具，提供灵活性，可以使用内置的或偏好的外部源代码控制和问题追踪工作流。

• 质量保证：它包含内置的代码扫描功能，并支持外部代码质量工具，专注于高代码质量和早期问题识别。

• 备份和数据迁移：它提供强大的数据完整性和可用性解决方案，对于灾难恢复和业务连续性至关重要。

• 分支和合并管理：它提供如分支权限和同行评审框架等功能，促进协作和高效的开发工作流。

• 用户友好的界面：它拥有直观且易于访问的用户界面，适合广泛的用户群体，降低了学习曲线。

• 管道和自动化灵活性：它使团队能够创建和编排自定义管道，自动化流程以提高效率并满足动态 DevOps 需求。

Flosum 的弱点

Flosum 虽然是一个强大的 Salesforce DevOps 解决方案，但也存在一些可能影响其适用性的局限性。主要的限制之一是它的特定平台聚焦。Flosum 专为 Salesforce 设计，在这一环境中表现出色，但对于寻求更多平台无关的 DevOps 工具的公司来说，它可能不是理想的解决方案。这种专业化虽然对以 Salesforce 为中心的操作有益，但在多平台使用的技术环境中，它的实用性有限。

对于那些没有深入融入 Salesforce 生态系统的团队来说，Flosum 呈现出明显的学习曲线。其功能和操作紧密结合 Salesforce 平台，这对于不熟悉 Salesforce 细节的人来说可能会具有挑战性。这一方面可能会减缓 Flosum 在非 Salesforce 熟练环境中的采用和高效使用。

成本是另一个不能忽视的因素。Flosum 的专业性质和丰富功能伴随而来的高价可能对预算有限的小型组织或初创企业构成压力。这使得 Flosum 对于寻求经济高效 DevOps 解决方案的小型团队来说不够可及，但值得注意的是，所有付费供应商提供的解决方案都存在这一问题，而不仅仅是 Flosum。

与非 Salesforce 工具的集成，尽管支持大量解决方案，但并非总是无缝的，需要额外的插件或手动设置和安装。这一限制对于依赖于多种外部工具和系统的团队来说可能是一个重大缺点。特别是在 Salesforce 仅是多个平台之一的环境中，对更广泛集成能力的需求可能更加突出。

Flosum 对 Salesforce 平台的依赖意味着其性能和功能受到 Salesforce 自身性能水平和治理限制的制约。这种依赖可能导致瓶颈，正如在测试中观察到的某些页面加载速度缓慢的情况。对 Salesforce 基础设施和限制的依赖可能会影响 Flosum 的效率和可扩展性，特别是在复杂或大规模的操作中。

Flosum 的综合性质虽然是一种优势，但也带来了过度复杂化的风险。一些团队可能会被其广泛的功能所压倒，许多功能在简单的部署场景中可能并未被使用。这种复杂性可能导致效率低下，特别是对于那些更倾向于使用简化工具集的团队。

根据前几章对主要 Salesforce DevOps 平台的介绍，下面是一个简要的总结表格，帮助您做出决策。

弱点	描述
平台特定的聚焦	专为 Salesforce 设计，限制了其在多平台环境中的实用性。对于寻求平台无关 DevOps 解决方案的公司来说并不理想。
对非 Salesforce 用户的学习曲线	对于不熟悉 Salesforce 的团队来说，由于其深度集成，可能会导致采用和效率降低。
成本考虑	对于较小的组织或初创公司来说可能过于昂贵，影响预算有限的团队的可及性。
非 Salesforce 集成	尽管支持一些外部工具，但与非 Salesforce 工具的集成可能不易配置，这会影响依赖多样化外部系统的团队。
依赖 Salesforce 生态系统	性能和功能紧密依赖于 Salesforce，包括其性能水平和治理限制。Salesforce 中的问题直接影响 Flosum 的有效性，在某些情况下观察到页面加载速度慢。
过度复杂化的潜力	广泛的功能可能导致复杂性，这可能让人感到不知所措，并且在简单的部署场景中未被充分利用。

表 14.2 – Flosum 弱点概览

总结

Flosum 通过其灵活性和复杂性在市场中脱颖而出。它挑战了传统的 DevOps 方法，特别是与“Git 正统派”保持距离。这种立场，再加上其在 Salesforce 平台基础上对安全性和合规性的高度重视，使 Flosum 成为 Salesforce DevOps 领域中一个独特且有吸引力的选择。

从先进的部署选项到强大的安全措施，它的众多功能使其成为任何希望简化 DevOps 流程的 Salesforce 架构师必不可少的工具。正如我们在本章中探讨的，Flosum 的集成功能、可定制性和复杂的工具集使其在 Salesforce DevOps 领域中脱颖而出。

在下一章，我们将继续探讨另一个流行的 Salesforce DevOps 工具选择——AutoRABIT。

第十五章：AutoRABIT

在本章中，我们将深入探讨 AutoRABIT 平台，研究其核心模块如何在 Salesforce 生态系统中提供针对发布管理、数据保护和代码质量的端到端协调。我们将探索关键能力，如元数据处理、测试自动化、合规性控制、持续集成/持续交付（CI/CD）管道等。

本节旨在为读者提供 AutoRABIT 的概览，并解释它如何解决 Salesforce 团队在采用 DevOps 实践时常遇到的痛点。你将根据实际使用情况清晰地了解 AutoRABIT 的优缺点，帮助你判断它是否是适合你项目的 DevOps 解决方案。

本章将涵盖以下主题：

• AutoRABIT 概述

• 了解 AutoRABIT 的优势

• 探索 AutoRABIT 的弱点

本章结束时，您将充分理解 AutoRABIT 针对企业级 Salesforce DevOps 量身定制的解决方案。

AutoRABIT 概述

在动态变化的 Salesforce 开发世界中，组织常常面临碎片化流程、测试瓶颈和严格合规控制等挑战。AutoRABIT 凭借其全面的 DevOps 工具套件，成为解决这些挑战的关键方案。本节将深入探讨 AutoRABIT 平台，阐明其集成组件——自动化发布管理（ARM）、数据保护（AutoRABIT Vault）和代码质量（AutoRABIT CodeScan）——如何共同提升 Salesforce DevOps 流程。

我们不仅会探索这些解决方案的技术方面，还会展示它们如何产生实际影响；例如，缩短部署时间，同时增强合规性遵循，或简化 Salesforce 开发，确保数据完整性和安全性，符合复杂的法规。这些实际的见解突显了 AutoRABIT 在不同组织环境中的变革性影响，为读者提供对其能力和实际应用的全面理解。

AutoRABIT 平台概述

AutoRABIT 平台包含三个支柱：

• ARM：AutoRABIT ARM 为开发团队提供端到端的发布过程协调。它无缝集成了版本控制、CI 测试、合规控制和部署管道。

• 数据保护：AutoRABIT Vault 提供 Salesforce 数据和元数据的备份和恢复功能。它使团队能够保护信息的完整性，并满足数据隐私法规要求。

• 代码质量：AutoRABIT CodeScan 执行 Apex 和 Lightning 代码的静态分析，以识别漏洞并强制执行安全编码标准。

这些解决方案共同提供对整个 软件开发生命周期（SDLC）的统一可见性和控制。让我们更详细地探讨每一个。

ARM

AutoRABIT 的 ARM 平台解决了在扩展 Salesforce 上的开发和配置时，由于缺乏强有力的流程而带来的沮丧，例如冲突的更改或缺乏可视性。

对于遭遇部署困难的团队，ARM 通过提供一个强大的工具集来管理和监控发布，帮助将混乱整理成秩序。通过自动化测试，集成测试瓶颈消失，在部署过程中自动执行测试。代码进程从提交到生产遵循一致、可预测的路径，这意味着你可以清楚地看到各个环节的进度。全面的控制和度量标准提供了进一步的防护措施和可见性，持续检查代码的状态。下图展示了用户 界面（UI）：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_15_01.jpg

图 15.1 – AutoRABIT ARM 用户界面

注意

上图中的文本细节最小化，且与图形的显示无关。请参考免费下载的电子书，查看图形中的详细内容。

使用 ARM，发布变成了一个无关紧要的事件。代码快速从开发流向部署，没有意外。让我们来看看关键功能。

AutoRABIT 提供先进的版本控制、合并和依赖关系管理，适用于复杂的 Salesforce 元数据关系。具体来说，它执行以下操作：

• 它检测跨分支的元数据和组件之间的细微差异。AutoRABIT 仅检索部署所需的更改元素。这种增量部署方法避免了对无关文件的重复处理。

• 合并引擎整合了来自多个流的并发更改。可定制的规则解决冲突而不会影响无关组件。

这些功能消除了在功能分支中跟踪元数据更改的头疼问题。AutoRABIT 能够清晰地合并代码而不修改无关元素。部署仅包含相关更改。

另一个导致部署延迟的原因是测试不足。AutoRABIT 通过以下方式将强大的测试自动化融入到管道中：

• 它在验证、提交和部署过程中运行 Apex 测试，并具有可配置的通过率规则。将测试作为强制步骤可以防止意外回归。

• AutoRABIT 根据变更包中的组件即时解决测试类依赖关系。仅执行相关测试以提高速度。

• 它与 Selenium 等自动化测试框架集成，用于 UI 测试。

通过将测试前移，问题会在到达生产之前尽早显现。测试变成了一项日常活动，而不再是发布瓶颈。AutoRABIT 在交付的各个阶段提供可靠的自动化支持。

在医疗保健和金融等受监管行业中，发布需要严格的合规控制，以确保安全性和访问控制。AutoRABIT 自动化以下功能：

• 预部署时审查访问权限更改。添加字段时需要检查权限。

• 所有部署事件的不可变审计日志提供了后续证明。

• 静态代码分析集成能在部署前暴露潜在漏洞。

• 备份和恢复保护数据完整性

这些功能确保部署能够遵循诸如系统和组织控制 2（SOC 2）、国际标准化组织（ISO）27001、通用数据保护条例（GDPR）以及健康保险携带与责任法案（HIPAA）等标准。

AutoRABIT 开箱即用地支持 CI/CD 流水线，具有以下优势：

• 提交后对目标环境进行验证，能及早发现问题，防止合并前的错误。

• 自动化工作流在通过检查后推动代码通过流水线。

• 链式作业连接部署事件以进行发布编排

• 部署可以触发进一步的步骤，例如测试

• 回滚控制台有助于在失败时恢复到部署前的状态

使用 AutoRABIT，团队可以设置结构化的流水线，确保每个阶段无缝过渡到下一个阶段，避免不必要的延迟。

参数化

在 DevOps 环境中，参数化通常是指将配置和部署变得更加可重用、可维护和标准化，通过将可配置值外部化为参数，而不是硬编码。

AutoRABIT 的一个主要优势是能够灵活建模复杂的发布过程。对于那些犹豫采用高度结构化流水线的团队，AutoRABIT 允许他们按照自己的节奏推进：

• 它支持复杂的 Git 工作流，如 GitFlow，并具备广泛的分支功能。

• 参数化使得只需配置一次部署步骤，便可在各处重复使用。流水线阶段变得即插即用（PnP）。

• AutoRABIT 允许创建自定义角色，如开发人员、管理员和包管理器。通过集中的身份和基于上下文的策略，权限可根据需要进行自定义，按每个用户/组的基础限制数据和功能。

• 脚本扩展内置功能，而无需触及核心代码。快速定制增强了平台功能。

AutoRABIT 允许从简单开始，并根据需要通过扩展流水线功能演化发布自动化。

AutoRABIT 优化核心部署过程的性能，采用增量部署机制，仅推送环境之间的组件差异。这避免了全量重新部署的重复开销。还可以选择忽略非关键元数据组件，防止无价值的更改。这些优化即使对于大型复杂包也能最大化部署吞吐量和可靠性。

AutoRABIT 提供了针对 Salesforce 独特平台方法的广泛功能；例如，全面的元数据类型支持，包括 Lightning 组件，管理包命名空间的处理，以及对 CloudSense 和 Conga 等产品的 ISV 合作伙伴解决方案支持。

AutoRABIT ARM 旨在为整个 DevOps 工具链提供一个控制塔。接下来，我们将探讨它如何管理和保护 Salesforce 数据。

AutoRABIT Vault 数据保护

AutoRABIT Vault 提供了一种强大的 Salesforce 环境备份和恢复解决方案，能够有效服务于开发人员、管理员和发布经理。该工具使得这些专业人员能够自信地保护他们的信息资产，提供便捷的自助服务模式。对于关心数据完整性的组织，Vault 提供了所需的保护。它允许团队根据需求或预定的计划进行备份，有效地为潜在的数据丢失提供了保障。它还提供了比较和恢复选项，使用户能够比较他们在 Vault 中的数据状态与实时系统中的数据，确保用户信息的安全。以下截图展示了 Vault UI 的示例：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_15_02.jpg

图 15.2 – AutoRABIT Vault 用户界面

注意

上述图中的文本细节已简化，并且与图形的显示无直接关系。请参考免费的电子书下载，以查看图形中的详细内容。

该工具的主要特点包括定期备份，确保 Salesforce 数据和元数据的定期自动保存。这些备份可以根据不同的需求进行定制，包括每日、每周或增量备份，并且由于其批处理过程，能够很好地应对大量数据，减少部分故障的风险。组织不仅限于完整备份，还可以选择增量备份，增量备份只捕捉自上次备份以来的变化，使得备份过程更加高效。为了进一步保证安全，用户可以通过简单点击随时发起按需备份。

高效的存储是另一个优点，因为 Vault 提供了在不同位置存储备份的灵活性，包括Amazon Web Services 简单存储服务（AWS S3）、Azure Blob、Google Cloud Storage（GCS）等主流云服务，以及本地解决方案，如存储区域网络（SAN）或网络附加存储（NAS）。它支持自带密钥（BYOK）加密方法，允许制定一个安全的备份策略，满足组织在预算、安全性和数据管辖方面的特定需求。

在恢复方面，Vault 提供了良好的细粒度控制来满足特定的恢复需求。例如，用户可以深入备份进行法医分析，从而简化审计流程。他们可以选择恢复单个记录、记录组或整个对象。此外，在某些字段受影响的情况下，Vault 提供了仅恢复受影响字段的能力，从而避免了更广泛的恢复操作。这种精确度确保了数据的完整性，同时保留元数据和关系，帮助避免后续的技术问题。

沙箱填充是另一个重要功能，通过用具有代表性的数据子集填充沙箱和临时组织，能够加快测试周期。Vault 允许用户在较小的环境中复制生产数据，同时提供过滤记录、屏蔽敏感字段以及保持参照完整性的选项，这些都对于有效的测试至关重要。

合规性也是一个关键考虑因素，Vault 包含了一些有助于遵守隐私法律和标准的功能。这些功能包括对数据进行静态加密和传输加密、对备份访问的 IP 限制、数据生命周期管理的自动保留策略以及支持 GDPR 和加利福尼亚消费者隐私法案（CCPA）等法规的匿名化工具。这些集成的合规性措施为组织提供了维护高标准数据安全和隐私所需的工具。

现在我们来讨论一下 AutoRABIT 的静态代码分析解决方案。

AutoRABIT 静态分析的 CodeScan

AutoRABIT CodeScan 提供了一款全面的静态分析工具，旨在评估 Salesforce 代码，提前发现潜在的缺陷和安全问题，从而可以以更具成本效益的方式进行解决。该工具提倡持续检查的方法，允许采取主动而非被动的方式解决问题，这有助于提升代码的健壮性和完整性。

对于面临技术债务和安全漏洞挑战的组织来说，CodeScan，和其他静态代码分析工具一样，作为一个宝贵的资产，有助于在各个项目和团队之间强制执行一致的标准。它坚决采用客观的方法来评估代码质量，从而有助于开发出更具韧性的应用程序。以下截图展示了 CodeScan 用户界面的示例：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_15_03.jpg

图 15.3 – CodeScan 用户界面示例

注意

上图中的文字细节已被最小化，并且与图形的展示无直接关系。请参考免费下载的电子书以获取图形中的详细信息。

深入了解 CodeScan 的主要功能，该工具广泛支持 Salesforce 中多种编程元素，包括 Apex、Visualforce、Lightning 组件和 Flow。它配备了超过 600 条预定义规则，涵盖了安全性、性能和风格的最佳实践，同时还遵循行业标准，如 全球应用安全项目（OWASP）十大风险和 常见弱点枚举（CWE）前 25 名。

此外，CodeScan 能够与 CI/CD 管道无缝集成，帮助在开发过程中更早地推动安全性，也就是 shift-left 安全性。扫描提交并分析拉取请求可以防止不合格代码的合并。构建可以配置为在政策违规时失败，从而防止未经验证的部署，开发人员通过对最近修改的组件进行增量分析，快速获得反馈。

另一个特点是团队可以创建反映其独特组织政策的自定义规则。团队可以在利用如 OWASP 十大风险等核心规则集的同时，封装其特定的编码指南，并为规则违规设置严重性等级，从而区分关键问题与警告。

AutoRABIT 的 CodeScan 一致地执行安全标准，为开发人员提供即时反馈，旨在培养安全和韧性的代码库。

在介绍了产品的基础功能后，我们将讨论 AutoRABIT 的优缺点。

了解 AutoRABIT 的优势

AutoRABIT 是一个为大型 Salesforce 客户设计的先进解决方案，提供了一整套旨在提高操作效率和效果的工具。其平台超越了通常在单一解决方案中看到的局限，提供了一个统一的端到端 DevOps 环境。AutoRABIT 的每个工具，包括用于部署的 ARM、用于数据安全的 Vault 和用于质量分析的 CodeScan，都经过精确调校，能够协同工作。这种一致性为用户提供了全面的可视性和治理，消除了操作盲点，避免了需要整合不同工具的情况，从而使 AutoRABIT 成为专为 Salesforce 生态系统量身定制的 DevOps 工作流的核心。

AutoRABIT 在测试方面的 approach 非常全面。测试贯穿整个开发过程，成为一个持续的活动，从代码提交到部署阶段，每个环节都会进行测试。通过提前并频繁地标记问题，AutoRABIT 确保代码在推进之前满足严格的质量标准。频繁且系统化的测试可以避免技术债务的积累，防止缺陷进一步扩展，这种一致性在所做的修改中建立了深厚的保障感。

对于在严格监管框架下运营的组织，尤其是在医疗、金融和保险等行业，AutoRABIT 提供了一套强大的合规性和安全措施。它所提供的工具，如静态代码分析、全面的访问审查、防篡改审计日志和安全的数据加密，强化了公司应对风险的能力。AutoRABIT 的全面解决方案在发布管理中引入了一种纪律，这是手动方法难以实现的，确保通过基于角色的访问控制（RBAC）和严格的代码扫描和备份执行来遵守最小权限原则（PoLP）。

通过在多个数据中心之间引入冗余，并保持全面的灾难恢复（DR）协议，该平台让用户对高可用性（HA）和业务连续性（BC）充满信心。这种可靠性还得到了严格服务级别协议（SLA）的支持。

AutoRABIT 在自动化方面也表现突出，避免了不必要的手动操作。通过智能地辨别上下文，例如在元数据比较时忽略无关的组件，AutoRABIT 精简了操作。自动化是有选择性的，只在必要时鼓励人工干预，从而让团队可以将更多时间投入到创新而非单调重复的工作中。

在讨论了 AutoRABIT 相对较强的领域之后，我们将继续探讨一些相对较弱的地方。

探索 AutoRABIT 的弱点

AutoRABIT 已经确立了自己作为一个强大的 DevOps 解决方案提供商的地位，但客户反馈强调了某些领域仍有改进空间。对用户评论和反馈的深入分析揭示了一系列问题，特别是关注于性能、系统固有复杂性、客户支持水平以及可能影响用户体验的各种限制。

关于性能，用户报告中曾出现 AutoRABIT 在处理大量复杂元数据时的延迟问题。当提交大量包或执行重大部署变更时，系统似乎偶尔会出现卡顿。性能下降通常归因于元数据中复杂的依赖关系，平台必须在其中进行导航。随着复杂性水平的提高，这些慢速反应变得越来越明显，暗示着性能调优和优化是亟待发展的方面。

除了性能问题外，AutoRABIT 的深度定制性虽然强大，但也带来了一定的复杂性，可能让人感到望而却步。对于经验较少的人群，如新开发人员，众多的管理设置和选项可能会让人不知所措。界面呈现了大量的参数和调整选项，虽然赋予了相当的控制权，但也可能导致混淆。即便是经验丰富的管理员，也需要面对陡峭的学习曲线，才能掌握 AutoRABIT 的全部功能。以下截图展示了一个复杂的 UI 示例：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_15_04.jpg

图 15.4 – 配置插件 – 选择项众多

注意

上图中的文字细节已最小化，并且与图形展示无直接关联。请参考免费下载的电子书，查看图形中的详细内容。

除了这些可用性问题外，用户对于 AutoRABIT 支持材料的质量存在一定的负面情绪。文档，通常是排除故障和学习的第一资源，被描述为缺乏必要的细节，导致了冗长的问题解决过程。

客户支持响应速度是用户强调的另一个关键问题。寻求帮助时长时间等待的报告表明，需要一个更及时和更广泛的支持网络。此外，关于可能的延迟的透明沟通有助于设定合理的期望，并缓解用户的不满情绪。

该平台的 Salesforce DX 集成主要针对 GUI 方式进行定制，虽然界面优雅，但并未完全满足那些偏好使用 命令行界面 (CLIs) 进行自动化和工具需求的用户。对于依赖 CLI 的团队而言，目前对 GUI 的重视显得不足，表明更强大的基于 CLI 的 DX 集成将会是一个有益的改进。

最后，一些客户表示，预测与 AutoRABIT 基于消费的定价模型相关的长期成本存在困难。预测扩展团队和增加使用量所需资源的挑战增加了复杂性。更透明的定价结构以及帮助预算预测的工具，将极大地帮助团队管理财务，并可能防止因意外成本上涨而导致的客户关系紧张。

尽管存在这些限制，为了成功地使用 AutoRABIT，客户应当注意遵循平台文档中的限制，避免性能问题。此外，尽管 AutoRABIT 提供了高度可定制的环境，但客户应当避免在尚未熟悉标准工作流程之前过度配置。学习基础知识后再调优高级参数将获得更好的结果。建议通过利用现有培训并逐步增加配置更改，而不是一开始就尝试掌握完整的平台复杂性。

尽管 AutoRABIT 在某些方面存在不足，客户仍然可以采取积极措施，确保顺利采用。通过审慎使用平台，并利用现有的文档和支持渠道，客户可以在基础功能随着后续版本的发布逐步完善的同时，实现他们的目标。

总结

最后，AutoRABIT 提供了广泛的功能，专为 Salesforce DevOps 定制，具有处理复杂元数据、嵌入式测试、合规控制和跨模块集成等方面的优势。然而，像任何复杂的平台一样，基于客户反馈，仍然有一些领域需要改进，尤其是在性能、可用性、文档和支持响应方面。

总体而言，AutoRABIT 在发布自动化、数据保护和代码分析方面，作为 Salesforce 团队寻求集成 DevOps 解决方案的领导者，具有良好的市场定位。尽管并不适合每个组织，但 AutoRABIT 为那些需要高级监督和治理的用户提供了强大的选择。

接下来，我们将稍微转换一下话题，讨论下一章节与 Salesforce DevOps 相关的其他工具。

第十六章：其他 Salesforce DevOps 工具

在本章中，我们将探讨一系列工具，这些工具补充并增强了 Salesforce DevOps 生态系统。这些工具提供不同的功能，涵盖 DevOps 生命周期的各个方面，从规划、开发到部署和监控。了解这些工具的功能和应用将帮助您为 Salesforce 实施选择最合适的工具。

本章将涵盖以下主题：

• Salesforce DevOps Center

• 其他商业工具

• 开源工具

本章结束时，您将全面了解 Salesforce DevOps 生态系统，包括每个工具如何融入您的 DevOps 策略的见解。您还将具备做出明智决策的能力，以选择哪些工具最能满足您的 Salesforce 项目的特定需求。

Salesforce DevOps Center

Salesforce DevOps 生态系统庞大且持续发展，许多工具应运而生，以满足开发生命周期中不同需求。在这一部分，我们将探讨一些与 Salesforce 集成的主要工具和平台概述，提供更高效的开发、协作和自动化体验。首先，我们将介绍一个新的重要角色——Salesforce 自家的 DevOps 解决方案：DevOps Center。

DevOps Center 是一个 Salesforce 解决方案，旨在通过将 DevOps 最佳实践融入 Salesforce 开发团队的变更和发布管理流程，无论他们位于低代码到专业代码的哪个位置，来增强这一过程。该平台是在 Salesforce 社区反馈的基础上开发的，用户寻求替代变更集的方案。虽然变更集仍然可用，但 DevOps Center 被认为是一个更先进、更高效的工具，用于管理 Salesforce 环境中的变更。

DevOps Center 具有以下关键功能：

• 自动化变更跟踪：DevOps Center 消除了手动跟踪变更的需求，如使用电子表格或便利贴，通过自动跟踪开发环境中的更改。

• 源代码控制集成：它使用源代码控制库，如 GitHub，作为项目更改的唯一真实来源（SSOT），确保团队成员之间的工作保持一致。

• 分支管理：该平台简化了分支的创建和管理，通过一个简单的点击界面，促进了变更通过发布管道的进程。

• 工具灵活性：开发人员可以使用他们在 DevOps Center 外偏好的工具，并且仍能通过集中源代码控制系统保持团队间的变更可见性。

• Salesforce DX 兼容性：在后台，DevOps Center 利用 Salesforce DX，包括与 Salesforce CLI、Metadata API 和源代码控制的兼容性，而无需用户熟悉这些工具。

• 用户界面 (UI)：基于点击的 UI 使用户能够与 DevOps 流程互动，而无需直接接触底层技术，如 Salesforce CLI 或 GitHub。

使用 DevOps Center，不同类型的开发者可以更有效地协作。例如，声明式开发者可以创建工作项、拉取更改并提交到源代码管理库，而程序开发者可以在推广之前审查这些更改。发布经理可以通过 DevOps Center 内的发布管道或使用 Salesforce CLI 来部署更改，从而改善发布管理过程。请参见下图，了解支持的不同工作流程：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/slfc-dop-arch/img/B19436_16_01.jpg

图 16.1 – DevOps Center 的开发流程

该平台还包括识别工作项之间冲突的功能，并提供帮助解决冲突的信息，这对于多并行开发的团队尤为有用。DevOps Center 可以检测开发环境与 SOT（目标状态）不同步的情况，并提供同步环境的工具，从而减少在部署过程中发生冲突或错误的机会。

该平台提供了对变更和发布过程的增强可见性，包括活动历史记录，便于审计和错误跟踪。工作项、冲突管理和仅验证部署等功能有助于提高生产力和优化工作流程。

初始版本的 DevOps Center 仅支持 GitHub 作为源代码管理系统。其他系统用户，如 Bitbucket，可能需要切换到 GitHub 或等待未来的更新。DevOps Center 目前还只支持基于组织的开发，而非基于包的开发（2GP），这可能与所有开发团队的工作流程不完全一致。最后，尽管计划推出多个外部集成功能，但目前它能连接的外部系统数量有限。

总的来说，DevOps Center 为 Salesforce 开发团队提供了一个简单的平台，以更有效地管理变更和发布过程。

其他商业工具

商业工具提供一系列针对 Salesforce 开发和操作的功能。这些平台通常提供一些专门的功能，如部署管理、影响分析和自动化能力。它们对于那些寻求简化开发流程并增强团队成员之间协作的组织尤其有益。在本节中，我们将探讨一些在 Salesforce DevOps 生态系统中做出重大贡献的商业工具。

Salto

Salto 是一个 DevOps 平台，旨在简化和增强 Salesforce 环境的开发和操作流程。作为一个 SaaS 产品，Salto 管理 Salesforce 配置和元数据，旨在提供更高效的方式来处理不同 Salesforce 实例之间的部署、版本控制和依赖关系跟踪。

Salto 的核心功能包括以下内容：

• 配置和元数据探索：Salto 提供了工具，帮助用户在变更之前检查和理解 Salesforce 配置的影响。通过一个用户友好的界面，Salto 将底层的 XML 数据抽象为更易读的格式，采用 Salto 的专有 非配置语言 (NaCI)。

• 部署管理：Salto 允许用户轻松地将变更从一个 Salesforce 环境迁移到另一个环境。该平台支持预部署验证过程，可以识别潜在的部署问题，例如缺失的依赖项，从而减少部署失败的频率。

• 自动化和持续集成/持续部署 (CI/CD)：Salto 引入了 CI/CD 自动化功能，使用户能够将平台集成到现有的 CI/CD 流水线中。这使得自动化测试、构建和部署过程成为可能，从而帮助团队实施 DevOps 最佳实践。

• 版本控制集成：Salto 与 版本控制系统 (VCS) 集成，如 Git，一般包含 NaCL 元数据，允许用户为部署到 Salesforce 环境的变更创建审计跟踪。此集成还支持通过保持变更记录来满足监管要求，以便进行审计。

Salto 适用于多种用例，例如简化跨多个 Salesforce 沙盒和生产环境的部署过程，或管理复杂的 Salesforce 环境，其中配置之间的相互依赖关系是常见的。

它提供了一个用户友好的界面，将复杂的 XML 数据抽象为更易访问的格式。这有助于主动识别配置依赖关系，从而帮助防止部署问题。然而，用户需要学习 Salto 的专有 NaCl 语言，这可能带来一定的学习曲线。

总结来说，Salto 将自己定位为一个强大的 Salesforce DevOps 工具，旨在简化部署流程、增强变更智能，并提高整体效率。

Panaya

Panaya ForeSight 是一个变更智能平台，旨在帮助组织管理、维护和调试他们的 Salesforce 组织。该平台提供了一整套工具，旨在提供对 Salesforce 环境复杂生态系统的可视化和控制。

ForeSight 使用户能够对其 Salesforce 组织的元数据进行深入分析，从而生成组织结构中依赖关系的详细映射。此映射对于理解各个组件之间的相互联系至关重要，这在规划对系统的更改或添加时非常重要。ForeSight 的一个关键功能是其 Discovery Chrome 扩展，它使用户能够直接从任何 Salesforce 页面获取洞察，帮助预测对相关组件（如 Apex 类、流程构建器、流程和字段）的影响。

ForeSight ExplAIn 是该平台的一个 AI 驱动扩展，通过以人类可读的格式提供关于 Salesforce 中自定义和自动化的解释，为平台增添了另一层智能。此功能有助于故障排除并自动生成文档，可以大大减少处理这些任务的时间。

ForeSight 可用于多种 Salesforce 管理任务，包括发布规划、减少技术债务、根本原因分析（RCA）和优化测试工作。它对于正在迁移到新 Salesforce 功能或管理从工作流规则到流程的过渡的组织尤其有用。该平台使组织能够清晰地理解变更的影响，自动化影响分析，并通过提供全面的组织洞察，帮助新团队成员高效入职。

Panaya ForeSight 的主要优势之一是该平台能够减少与理解和管理 Salesforce 组织相关的人工工作量，从而实现更准确、更快速的影响分析。AI 驱动的文档和人性化的解释增强了新员工的入职过程，并为组织功能提供了快速参考。通过实现主动管理，ForeSight 帮助组织从被动管理转变为战略性管理，可能会带来创新并优化工作流。

尽管该平台提供了全面的 Salesforce 组织管理工具集，但其效果的程度可能取决于组织的复杂性以及用户对平台的熟悉程度。此外，与任何 AI 驱动的工具一样，输出的质量取决于输入的数据，AI 的输出可能并不总是完全符合需求。

Prodly

Prodly 旨在简化开发和运营过程，特别是对于 Salesforce 管理员和低代码开发人员等业务用户。产品套件包括环境管理、工作管理集成、发布自动化以及合规性和安全控制工具。

Prodly 在 Salesforce 中提供了一个用户友好的界面来管理各种开发环境，包括无需命令行工具即可创建 scratch org 的功能。此功能利用了 Salesforce DX 的特性，但简化了非开发人员的操作流程。Prodly 的环境管理还包括沙箱种子功能，允许用户用示例数据或特定数据集填充环境。此功能支持环境之间的自动数据迁移，遵循依赖关系和插入顺序，防止重复数据，并节省手动配置的时间。

在工作管理方面，Prodly 与 Salesforce 的 Agile Accelerator 和 DevOps Center 集成，使用户能够创建和管理项目及工作项，并将其与 DevOps Center 检测到的元数据变更关联。此集成确保了管理应用生命周期和相关元数据的过程顺畅。

Prodly 中的发布自动化功能允许对源环境和目标环境之间的元数据进行比较，提供变更预览和引导部署过程。这可以通过在执行部署之前提供洞察，帮助防止部署错误。此外，Prodly 支持从一个组织到另一个组织或从组织到分支的元数据部署，支持不同的开发工作流，包括使用源代码控制系统的工作流。

Prodly 适用于需要为管理员和低代码开发人员提供 DevOps 功能的 Salesforce 用户组织。它对于管理复杂应用程序的企业尤其有用，例如 Salesforce CPQ 或 B2B Commerce，这些应用程序中配置数据与元数据同样重要。

Elements.cloud

Elements.cloud 是一个旨在提升 Salesforce 环境管理和文档编制的 DevOps 平台。其主要功能包括捕获反馈、管理需求、定义工作项（如发布和用户故事），并将其与 Salesforce 元数据关联进行影响分析。该平台与 Salesforce 集成，允许用户将流程图嵌入到 Salesforce 记录页面中，并提供上下文敏感的帮助。

Elements.cloud 的一个关键使用场景是简化 Salesforce 组织内变更的文档编制和分析过程。通过自动化元数据字典的创建，并与生产和沙箱环境同步更新，Elements.cloud 促进了更高效的影响分析过程。此功能帮助开发人员和管理员理解 Salesforce 元数据组件之间的关系和依赖关系，从而将影响分析所需的时间和精力减少多达 50%。

Elements.cloud 的优势在于其提供的可视化层级流程映射工具，该工具具有版本控制并可以直接嵌入 Salesforce。这增强了用户验证业务流程需求的能力，并且平台的风险评估功能有助于从合规性和技术角度跟踪变更的潜在影响。此外，该平台还自动化了元数据项的文档记录，通过识别低影响字段来支持清理，并提供多层级依赖关系分析以进行深入的影响评估。

该平台还通过绘制业务流程并识别优化领域，帮助用户推动流程改进节省。通过将流程步骤与用户故事或需求关联，并附加相关文档，Elements.cloud 促进了对为何做出某些变更的理解，从而促进了机构知识的积累和未来开发的前瞻性保障。

Opsera

Opsera 是一个持续编排平台，旨在解决 DevOps 领域的问题，特别是连接交付流水线中各种工具并为该流水线创建可视性的挑战。它旨在提供产品交付的速度、质量和安全漏洞的洞察。Opsera 将这些工具的管理整合在一个 单一视窗（SPOG）中，为不同的工具集和流程提供编排和可视性。

Opsera 提供工具链自动化、声明式管道和洞察模块。工具链自动化模块允许用户管理和部署应用程序交付所需的工具，支持 SaaS 和传统应用程序。它包括与 Jenkins、Argo CD、Artifactory 和 SonarQube 等多种工具的集成，并具有根据需要添加其他工具的灵活性。Opsera 基于 SaaS 平台运行，客户被配置为单租户 VPC 和个性化门户。

声明式管道模块提供了一个低代码环境，用户可以在其中创建应用程序的工作流，包括为 Kubernetes 设计的 Salesforce 和容器化应用程序。它通过提供任务驱动的操作，迎合低代码开发者和高代码开发者的需求，使用户能够直接从组织推送变更到 Git 分支，促进 GitOps，无需命令行 Git 知识。

Opsera 的洞察模块提供了包含 DevOps 研究与评估（DORA）、完成定义（DoD）和 国家标准与技术研究院（NIST）指标的 100 多个关键绩效指标（KPI）的全面仪表板。它提供了软件交付生命周期的可视性，包括成功的部署、管道状态和单元测试指标。这种可观察性扩展到 Salesforce 特定的指标，提供对备份、回滚、迁移和 Jira 交付时间的洞察。

Opsera 的使用案例包括 Salesforce 应用程序的部署，它可以同时处理代码和低代码元素，以及将容器化应用程序交付到 Kubernetes。它支持各种环境，并能够管理应用程序从沙盒到生产环境的迁移。此外，它通过直接集成、API 交互和命令行步骤提供对应用生命周期管理工具的可见性。

Opsera 的主要优势在于其能够将不同的工具和流程整合到一个编排平台中，提供统一的 DevOps 方法。其基于 SaaS 的单租户 VPC 架构确保了安全性和隔离性。该平台的低代码环境对各种技术水平的用户都能访问，促进了不同团队成员之间的协作。

开源工具

开源工具在 Salesforce DevOps 生态系统中扮演着至关重要的角色。它们为社区提供灵活、可定制且通常无成本的解决方案，能够根据特定需求进行调整。这些工具由用户和贡献者共同开发和维护，大家协作改善和更新这些工具。在本节中，我们将探讨几种因其在 Salesforce DevOps 实践中的实用性和影响力而广受关注的开源工具。

Happy Soup

Happy Soup 是一个开源项目，旨在对 Salesforce 环境中的影响和依赖关系进行分析。该工具基于 JavaScript 和 Node.js 构建，其源代码在 GitHub 上公开，便于透明和协作。它主要面向需要理解 Salesforce 组织中复杂依赖关系的 Salesforce 管理员和开发人员。

Happy Soup 的核心功能包括分析对 Salesforce 组织所做更改的影响，以及了解各个组件之间的依赖关系。当修改像自定义字段这样的元素时，这一功能尤其有用，它有助于识别此类更改可能在系统中引发的潜在问题。

例如，如果修改了一个自定义字段，Happy Soup 可以迅速识别组织中所有依赖该字段的组件。这包括报告过滤器中的依赖、Apex 类、Lightning Web Components（LWC）中的 JavaScript 控制器、工作流规则等。该工具提供了这些依赖的可视化表示，便于理解潜在影响的广度和深度。

Happy Soup 的使用案例包括以下几种：

• 影响分析：在更改自定义字段之前，可以使用 Happy Soup 来确定依赖关系和潜在风险，从而做出明智的决策。

• 依赖分析：该工具对于独立顾问或新加入的团队成员来说非常有用，可以帮助他们快速了解特定组件或对象在不熟悉的 Salesforce 组织中的使用情况。

• 页面布局优化：Happy Soup 可以将页面布局的字段导出到 Excel 表格中，方便与业务用户讨论每个字段的相关性和必要性。

Happy Soup 是一款对 Salesforce 专业人士非常有价值的工具，旨在帮助管理其组织的元数据依赖关系的复杂性，并最小化与 Salesforce 环境变更相关的风险。

SFDX-Hardis

SFDX-Hardis 是一款为 Salesforce 开发团队增强 DevOps 过程的 Salesforce DX 插件。它旨在提供一种模块化、可脚本化的 DevOps 方法，将 Salesforce DX 命令的标准执行序列或脚本封装为单一且更易于访问的命令。

SFDX-Hardis 既作为 Salesforce DX 插件，也作为 Visual Studio Code 扩展，提供了一个用户友好的界面来启动 DevOps 任务。它允许用户启动新任务、创建字段，并通过向导管理分支合并，将复杂的命令行操作抽象为简单的界面驱动操作。该插件支持如创建分支、初始化沙盒、检索元数据和准备提交等操作。它还包括一个 Visual Studio Code 扩展，为那些可能不熟悉命令行工具的用户提供了图形化界面来执行命令。

该插件特别适用于需要结构化且灵活的方式来管理 DevOps 流水线的 Salesforce 开发团队。它支持同时使用临时组织（scratch orgs）和沙盒（sandboxes），因此适用于各种开发工作流。它的功能扩展至自动化元数据检索、部署模拟和质量检查，包括 Apex 测试覆盖率验证。SFDX-Hardis 可以与 GitLab、GitHub Actions 和 Azure DevOps 等 CI 服务器集成，从而在成功合并请求后自动化部署过程。

SFDX-Hardis 与流行的 CI/CD 系统的集成以及其对用户体验的关注，使其成为希望采用或增强 DevOps 实践的 Salesforce 开发团队的宝贵工具。

DX@Scale

DX@Scale 是一个为 Salesforce 实施设计的 DevOps 解决方案。它旨在通过利用 Salesforce DX 原则和定制工具，解决管理大型 Salesforce 项目时所面临的复杂性和挑战。该解决方案围绕几个核心原则构建，包括模块化设计、自动化和 CI/CD 实践。

DX@Scale 允许创建多个工件，如解锁包和源包，这些工件可以独立开发、测试和部署。它利用 Scratch Org 池来减少配置开发环境所需的时间，使开发人员可以即时访问。该解决方案实现了简化的分支模型，主分支作为生产分支，功能分支用于开发工作。它还包括自定义库、SF PowerScripts 和 SF PowerKit，这些是开源工具，提供了额外的功能，如包版本控制、构建优化和配置文件对账。

DX@Scale 对于大型 Salesforce 项目，特别是涉及多个团队和复杂部署需求的项目尤为有用。它通过允许高效管理依赖关系并促进创建更小、更易管理的包，从而简化了开发过程。该解决方案还适用于需要快速配置环境的场景，以及需要快速反馈循环的场景，在这些场景中，代码更改与部署验证之间的时间尤为重要。

DX@Scale 的主要优势之一是能够快速交付部署，完整构建的时间不到 25 分钟，单元测试执行时间在 2 到 5 分钟之间。它使用 CI/CD 管道和工件仓库，确保部署过程的可追溯性和控制。

CumulusCI

CumulusCI 是 Salesforce.org 开发的一个工具链，旨在自动化 Salesforce 项目的应用生命周期。它通过提供一套协同工作的自动化工具，旨在促进 Salesforce 应用的开发、测试和部署，从而创建一个紧密结合的开发流程。

CumulusCI 与 VCS 集成，利用 Salesforce DX Scratch Org 作为所有开发工作的基础。它自动化创建这些 Scratch Org，处理依赖关系、包安装、元数据部署、组织配置和数据填充。CumulusCI 通过流程和任务来协调这些过程，流程和任务是项目仓库中定义的自动化模块。任务是在 Salesforce 组织中的单独操作，而流程则是这些任务的序列，能够实现特定的结果。它们可以在 YAML 中配置，并且可以通过 Python 扩展。

CumulusCI 用于构建适应应用生命周期中各种角色的复杂环境，从开发人员和管理员到最终用户。它支持即时和独立的环境创建，确保团队可以在没有基础设施限制的情况下工作。CumulusCI 的可移植性意味着自动化不仅限于 CI 服务器，还扩展到本地机器和像 MetaCI 和 MetaDeploy 这样的 Web 界面。

工具链通过允许每个团队成员在他们的组织中工作，显著提高了开发速度，并大幅减少了对共享环境的冲突和依赖。它将现代最佳实践，如源代码控制和 Salesforce DX，嵌入到开发工作流程中。CumulusCI 是开源的，符合 Salesforce 社区驱动的倡议，并鼓励贡献和协作。

总结

在我们结束本章时，显而易见，Salesforce DevOps 生态系统提供了多种工具，能够满足各种开发场景的需求。从 Salesforce 自己的 DevOps Center 到第三方工具以及社区驱动的开源项目，市场上有丰富的选择，可以根据任何组织的独特需求量身定制。

我们讨论的每个工具都有其独特的优势和专长领域。通过选择这些工具的正确组合，Salesforce 团队可以创建一个不仅简化开发和部署流程，而且促进持续改进和协作文化的 DevOps 环境。

例如，Salesforce DevOps Center 是一个强大的原生 Salesforce 解决方案，能够与平台无缝集成，提供自动化的变更跟踪和源代码控制集成。它是寻求与 Salesforce 自身最佳实践和未来发展紧密结合的团队的理想选择。

商业工具，如 Salto、Panaya、Prodly 和 Elements.cloud，提供了一系列功能，如影响分析、部署管理和流程文档化。这些工具通常非常适合需要强大支持、先进功能和指导式用户体验的组织。

开源工具，包括 Happy Soup、SFDX-Hardis、DX@Scale 和 CumulusCI，为团队提供了灵活性和定制 DevOps 过程的能力。开源项目的协作性质通常意味着这些工具处于创新的前沿，融入了社区的最新想法和技术。

在为你的 Salesforce DevOps 工具包选择工具时，要考虑你组织的复杂性、开发团队的规模以及你面临的具体挑战。例如，如果快速环境配置是优先事项，工具如 DX@Scale 和 CumulusCI 可能特别有用。如果影响分析和依赖管理至关重要，那么 Salto 和 Panaya 可能会提供必要的洞察。

还需要考虑你 DevOps 实践的未来方向。随着 Salesforce 的不断发展，支持它的工具也将不断演进。关注新兴技术和现有工具的更新，将帮助确保你的 DevOps 策略保持当前并有效。

最终，任何 DevOps 工具的目标都是支持团队高效、可靠地交付高质量的软件。通过仔细评估各种选择并了解每个工具在更广泛生态系统中的适配方式，你可以创建一个不仅能够满足今天需求，而且能够应对明天挑战的 DevOps 环境。

通过本章获得的知识，你已经做好了充分准备，可以在 Salesforce DevOps 生态系统中顺利导航，做出明智的选择，从而推动你所在组织的成功。随着 Salesforce 平台的持续发展和演变，围绕它的工具和实践也会不断变化，提供创新和卓越的新机会。在接下来的最后一章，我们将总结主要发现，并规划出你未来可以走的路径。

第十七章：结论

本章将总结我们关于 Salesforce DevOps 讨论的关键点和要点，概括我们走过的历程，并展望 Salesforce DevOps 实践的未来。

本章将涵盖以下主题：

• Salesforce DevOps 的总结

• 常见的陷阱和避免方法

• 实施 Salesforce DevOps 的步骤和最佳实践

到本章结束时，你将完成学习旅程，并准备进一步探索 Salesforce DevOps 的精彩世界。

Salesforce DevOps 的总结

在最后一章中，我们将花一点时间总结前几章的学习成果，提供 Salesforce DevOps 的全面概述。这一反思不仅重新确认了所讨论的原则和实践，而且为 Salesforce 这一动态领域的持续成长奠定了基础。

Salesforce DevOps 领域

Salesforce DevOps 作为对管理 Salesforce 平台开发和运维复杂性和需求不断增长的回应应运而生。它代表了软件开发（Dev）和信息技术运维（Ops）的交汇点，旨在缩短开发生命周期，同时按照业务目标交付特性、修复和更新。

这段旅程始于理解 Salesforce 环境的演变，从一个以 CRM 为中心的工具转变为一个综合性的开发平台。这一转变需要采用真正的开发最佳实践，并且需要一个有效的交付机制——于是 Salesforce DevOps 应运而生。DevOps 引入了一种协作、集成和自动化的文化，简化了流程，促进了对变更管理的更加主动的管理方式。

这一转变的关键在于认识到 DevOps 文化的重要性。这不仅仅是关于工具和技术；更重要的是心态。通过培养 DevOps 文化，团队可以打破壁垒，鼓励开放的沟通，并确保共同承担 Salesforce 生命周期的责任。这种文化转变在推动 DevOps 实践的成功采纳和实施中至关重要。

在本书中，我们探讨了 Salesforce DevOps 的各个方面，包括部署策略、版本控制、CI/CD 和测试的角色。有效地部署更改是 DevOps 的核心。我们研究了 Salesforce 平台的内置工具及其局限性，这些局限性促使了第三方工具的出现，旨在增强 Salesforce 的功能。

其中一个重点领域是版本控制的重要性——这是任何 DevOps 实践的基石。我们讨论了它如何使团队能够跟踪更改、协作编写代码，并维护一个单一的真实来源。这一过程得到了 CI/CD 管道的补充，CI/CD 自动化了集成更改并将其交付到生产环境的过程，从而简化了部署并最大限度地减少了错误的风险。

测试是 Salesforce DevOps 的另一个关键组成部分。通过将测试自动化并集成到 CI/CD 流水线中，团队不仅可以确保变更快速部署，还能保证其可靠性和符合质量标准。这种积极的错误检测和调试方法有助于维护 Salesforce 环境的稳定性和完整性。

我们还深入探讨了管理 Salesforce 环境的复杂性，强调了监控和控制变更的必要性。未经检查的变更，即使是出于最好的意图，也可能导致不稳定性并扰乱平台的顺畅运行。自动化监控工具提供对变更的可见性，使团队能够迅速响应任何偏离预期行为的情况。

数据管理，包括数据备份和安全性，是我们深入探讨的另一个领域。数据是 Salesforce 平台的命脉，确保其完整性和安全性至关重要。我们讨论了数据备份和恢复、数据遮罩以及符合数据保护法规的策略。这些实践不仅保护组织的数据资产，还确保开发和测试环境能够访问真实、高质量的数据以进行有效测试。

Salesforce DevOps 工具的关键学习

Salesforce DevOps 代表了一个充满各种工具的生态系统，每个工具都设计用于满足 Salesforce 平台开发和运维中的细微差异。在本书中，我们剖析了几个主流 DevOps 工具的功能，分析了它们的优势和劣势，以及它们对 Salesforce 开发和运维效率与成功的影响。在本节中，我们将汇总这些讨论所得的见解，提供关于 Salesforce DevOps 工具的关键学习综述。

Salesforce DevOps 工具涵盖了广泛的领域，从元数据管理解决方案到持续集成平台、发布自动化、版本控制和测试工具。每个工具都专为解决 Salesforce 开发中固有的特定挑战而设计。例如，Gearset 在元数据部署和比较方面表现突出，Copado 在管理复杂部署流水线方面表现卓越，AutoRABIT 则凭借其代码分析和数据备份能力脱颖而出。

通过我们的探索，我们了解到没有一种工具能够解决所有 DevOps 需求。相反，组织必须仔细评估每个工具在其特定需求中的优势。一个提供出色元数据管理的工具未必提供最佳的测试框架，反之亦然。这里的关键要点是工具选择的细致方法的重要性，确保所选择的工具集与组织的工作流程相辅相成，提升生产力。

我们在探索 Salesforce DevOps 工具过程中得到的一个关键启示是集成与自动化的重要性。能够与 Salesforce 及其他第三方应用程序无缝集成的工具，创造了一个连贯的开发环境，最大限度地减少了人工工作并降低了错误的可能性。自动化，作为 DevOps 的核心原则，一直是我们讨论的一个主题。能够自动化重复任务（如部署和测试）的工具，使团队能够将精力集中在创新和解决问题上，而不是陷入日常操作细节中。

例如，自动化元数据和代码在不同环境间的迁移能力，以及测试的执行，显著加速了开发周期。我们了解到，自动化不仅加快了流程，还为部署带来了一致性和可靠性。执行任务的一致性确保每次部署都遵循相同的质量标准，从而减少缺陷进入生产环境的可能性。

Salesforce DevOps 工具强调了在整个开发生命周期中协作与可视化的重要性。提供清晰管道视图的工具，从开发到生产，促进了一个协作的环境，让所有相关方都能看到项目的进展。这种透明度在 DevOps 文化中至关重要，因为它确保从开发人员到发布经理，每个人都能从共享的项目状态理解出发进行工作。

DevOps 管道的可视化也有助于识别瓶颈和需要改进的领域。例如，提供详细日志和分析的工具可以帮助定位管道中常出现延迟的阶段，从而指导团队进行有针对性的优化。此外，协作功能，如在工具中对变更进行评论和审查，提升了团队沟通，并促进了知识共享。

展望未来——Salesforce DevOps 的前景

在我们结束对 Salesforce DevOps 的全面探索时，至关重要的不仅是回顾至今的历程，还要展望未来，预测新兴趋势，并为该领域的持续发展做好准备。在本节中，我们将探讨 Salesforce DevOps 的未来发展趋势，获取未来发展洞见，并讨论 Salesforce 从业者如何在不断变化的环境中蓬勃发展。

Salesforce 平台始终展示了对创新的承诺，定期推出新功能和增强功能，使组织能够以更有意义的方式与客户进行连接。这种持续的演进自然也延伸到了 Salesforce DevOps 领域，在平台的进步过程中，新的工具、实践和挑战不断涌现。

Salesforce DevOps 中的一个关键未来趋势是对人工智能（AI）和机器学习（ML）的日益重视。这些技术有潜力彻底改变我们对开发和运维的思维方式，提供预测性洞察、自动化日常任务并优化工作流程。随着 AI 和 ML 在 Salesforce 生态系统中的逐步融入，DevOps 实践将需要适应，以有效地利用这些能力。

另一个显著的趋势是安全性和合规性在 DevOps 过程中的重要性日益增加。随着数据泄露和隐私问题的上升，组织正在更加重视保护其 Salesforce 环境的安全。这一安全重点可能会促使开发出更多先进的工具和方法，确保 DevOps 实践符合严格的安全标准。

Salesforce DevOps 社区预计将变得更加合作和互联。随着平台用户群的扩大，分享最佳实践、经验和创新将变得愈加重要。这种集体智慧将推动 DevOps 实践的发展，培育出更加动态和有韧性的生态系统。

为了在 Salesforce DevOps 领域保持领先，实践者必须接受持续学习和改进的思维方式。这意味着要保持对最新平台更新的了解，积极参与社区活动，并愿意尝试新的工具和技术。

Salesforce DevOps 社区是一个充满活力且合作的生态系统，分享知识和最佳实践在其中受到高度鼓励。随着该领域的发展，社区的作用变得愈发重要，对塑造 DevOps 实践的未来起着至关重要的作用。

社区参与的一个关键好处是它促进了集体问题解决。通过分享经验和解决方案，社区可以更高效、更有效地应对常见挑战。这种协作方式加速了学习和创新，造福了整个生态系统。

由社区驱动的倡议，如开源项目和协作工具开发，可以创造出强大的资源，增强 Salesforce DevOps 实践。这些倡议利用社区成员多样化的技能和视角，打造出稳健、灵活且广泛适用的工具和解决方案。社区在推广 Salesforce DevOps 最佳实践和标准方面发挥着至关重要的作用。通过讨论、论坛和思想领导力，社区帮助建立促进质量、安全性和效率的指南。

需要避免的常见陷阱

如果你正在寻找实施 DevOps 以改善 Salesforce 交付过程，或者提升现有的流程，有一些关键的错误需要避免。我们将尽力为你提供指导，帮助你推动 DevOps 的成功。

实施 Salesforce DevOps 的最大陷阱之一是自动化的不足。自动化如果做得对，可以简化流程，减少人为错误，提高生产力。然而，许多组织要么未充分利用自动化，要么在没有明确战略的情况下实施自动化。例如，自动化一个有缺陷的流程只会导致更快地生产出不良结果。在实施自动化之前，确保流程已经得到优化至关重要。这需要对现有工作流有透彻了解，识别瓶颈，然后再应用自动化来提升这些流程。

另一个关键错误是缺乏跨团队协作。Salesforce DevOps 不仅仅是一套工具和实践，它还代表了一种鼓励不同团队（包括开发、运维和业务部门）之间协作的文化。如果没有这种协作，就有可能陷入各自为战，导致目标不一致、重复努力和项目进度延误。有效的沟通渠道和定期的跨职能会议在促进协作环境中至关重要。这确保了每个人都在同一页面上，并朝着共同的目标努力。

许多组织在 Salesforce DevOps 之旅中未能足够早地建立度量标准和监控。度量和监控不仅仅是为了识别问题；它们还提供了对 DevOps 实践有效性的关键洞察。它们有助于理解变更的影响，发现改进的领域，并做出基于数据的决策。从一开始就实施这些措施可以帮助团队跟踪进展、与行业标准对标，并持续改进他们的 DevOps 实践。

低估培训和技能发展的重要性是一个常见的疏忽。Salesforce DevOps 涉及一系列不断发展的工具和技术。团队必须与时俱进，掌握最新的趋势和最佳实践。投资定期的培训和技能发展课程可以确保团队能够有效地运用 DevOps 方法论，且具备足够的能力和信心。

最后，忽视 DevOps 的文化因素可能会带来不利影响。DevOps 的成功不仅依赖于工具和流程，还依赖于参与者的心态。鼓励开放、实验和持续学习的文化，与任何技术实施同样重要。对变革的抵触是自然的，但创造一个支持性的环境，在这里风险是被鼓励的，失败被视为学习机会，可以显著增强 Salesforce DevOps 计划的成功。

实施成功的 Salesforce DevOps 策略

在我们结束对 Salesforce DevOps 的探索时，必须将我们的理解整合成可操作的策略。通过对 Salesforce DevOps 各个方面的探讨，我们已具备了在组织内实施稳健且成功策略的知识。本节致力于将我们收集的丰富信息整合成 Salesforce 专业人士的实际路线图。

任何成功的 Salesforce DevOps 策略的基础在于建立一种强大的文化，接受协作、持续改进和共同责任的原则。在本书中，我们强调了培养一个透明、沟通和学习受重视的环境的重要性。

成功的 Salesforce DevOps 策略由一种鼓励团队成员共同朝着共同目标努力的文化支撑。协作不应仅限于开发人员；它必须扩展到 Salesforce 生命周期中涉及的所有角色，包括管理员、QA 测试人员、发布经理和利益相关者。促进沟通与协作的工具，如共享代码库、集成聊天应用和协作规划软件，能显著增强团队的动态性。

持续改进应成为寻求优化和增强 Salesforce DevOps 实践的团队的指导原则。这涉及定期审查流程、工具和结果，以识别优化的领域。鼓励将每个挑战视为成长机会的思维方式，将导致一个更加有韧性和适应力的组织。

在 DevOps 文化中，Salesforce 平台的成功责任由所有团队成员共同承担。这种集体所有制不仅确保了问责制，而且赋予个人主动性，使他们能够为平台的整体健康和性能做出贡献。

Salesforce DevOps 的核心在于部署过程。高效且可靠的部署对交付满足业务需求的功能和更新至关重要。我们的探索突出了几个有助于成功部署管理的关键实践。

自动化是实现平稳且一致部署的关键。自动化部署管道可以减少人为错误，加快交付过程，并确保每个变更都经过相同严格的测试和验证程序。

有效的变更管理确保 Salesforce 环境中的每个修改都被跟踪、审查并批准。这不仅增强了安全性和合规性，还提供了所有变更的清晰审计追踪。

优化发布流程需要在速度需求与质量要求之间找到平衡。团队必须致力于建立与业务需求相匹配的发布节奏，同时确保每次发布都经过充分测试和验证。通过 DevOps，还会有一个额外的优势很快显现出来——如果你有了质量，你就能走得更快，尤其是在长期来看。

从 DevOps 实施中提取的最大价值在于它与业务成果的紧密连接。例如，企业可以通过响应不断变化的客户和市场需求来推动更大的成功，而这一切都得益于一个强大的 DevOps 流程，使得新功能可以快速发布。另一种成功的衡量标准可能是 DevOps 降低了停机时间，从而提高了产品质量和市场上的品牌认知度，减少了修复问题的时间，并增加了满足客户期望的时间。

DevOps 成功的关键在于每个人都与该流程的方法和目标保持一致。所谓每个人，我们鼓励你不仅仅局限于开发和运维团队，而是跨越整个软件交付生命周期，端到端地进行思考。这种思维方式应该成为规划阶段的一部分，业务分析师和项目经理在此阶段就应该开始考虑如何将需求拆分成可以逐步交付的小模块。在管道的另一端，QA 资源甚至最终用户也可以融入 DevOps 文化，并习惯于定期但渐进的交付。

在考虑这些想法和思路的基础上，让我们看看一个可能的检查表，帮助你启动 Salesforce DevOps 实施。

DevOps 实施检查表

启动 Salesforce DevOps 涉及几个关键步骤，以确保成功实施。在本书中，尽管我们强调没有一种统一的方法来实施 Salesforce，但一些共同的主题在各个场景中是适用的。以下是最佳实践的总结列表：

• 了解你的需求：在深入 DevOps 之前，评估你当前的流程。识别哪些方面运作良好，哪些地方需要改进。这一步有助于确定实现 DevOps 成功所需的资源和支持。

• 从小处开始，逐步提升：实施 Salesforce DevOps 并不意味着一次性彻底改革。首先要建立一个坚实的基础，专注于成功的部署和版本控制。逐步建立你的 DevOps 流程。这种方法比起同时引入所有内容要成功得多。

• 建立 DevOps 文化：DevOps 不仅仅是关于工具，更关乎文化。强大的 DevOps 文化强调协作、持续改进和团队的支持。让整个团队参与 DevOps 培训和发展对培养这种文化至关重要。

• 迭代和优化：持续学习并优化你的流程。鼓励团队成员提出改进现有系统的想法和建议。

• 衡量成功：定期审查你的 DevOps 采用情况，确保你朝着目标前进。利用像 Google 的 DORA 这样的指标来评估你的 DevOps 工作流的速度和弹性。

• 选择并设置合适的工具：选择适合 Salesforce DevOps 的工具应与组织的具体需求和现有系统相匹配。根据工具支持你的工作流程、与其他系统（如 JIRA 或你的 Git 提供商）的集成、以及易用性来评估工具。寻找那些提供自动化变更跟踪、易于管理开发管道并与源代码控制系统无缝集成的工具。考虑那些在 Salesforce 环境中以稳健性著称的工具，如 Gearset、Copado、Prodly 或 AutoRABIT。选择一个不仅适应当前工作方式，而且能够随你的增长和不断发展的 DevOps 实践进行扩展的工具是非常重要的。

• 创建项目并设置管道：一旦选择了工具，下一步就是创建和管理你的开发管道。这包括设置环境（如开发、测试和生产环境），并定义在这些环境之间移动变更的流程。该管道应支持持续集成/持续交付（CI/CD），使你能够自动化测试和部署过程。该工具应提供每个开发阶段的可视性，从代码提交到部署，并促进团队成员之间的协作。

• 工作项管理和版本控制：实施一个管理工作项和跟踪变更的系统。这一步骤对于保持清晰的变更历史、理解每个修改的影响，并在必要时进行回滚至关重要。你选择的工具应支持版本控制实践，允许你保留所有元数据变更的全面历史记录。这确保了可追溯性和问责制，使团队能够有效地协作，并保持开发过程中的高标准质量和一致性。

记住，Salesforce DevOps 是一个持续的过程，需要不断学习和适应。你采取的每个步骤都应致力于创建更高效、协作性更强的开发流程。有关更详细的指南和附加信息，请参考提供的资料。

最后的想法和建议

在我们结束对 Salesforce DevOps 的深入探索时，我们回顾了所经历的旅程，以及我们所获得的全面技能。Salesforce DevOps 的世界复杂且不断发展，但它也是一个充满巨大机会和成长的领域。在这一最后部分，我们将提炼出我们所学到的精髓，转化为可操作的见解，并为 Salesforce 专业人员提供在 DevOps 之旅中持续卓越的建议。

Salesforce DevOps 是一个交叉技术、流程和人员的领域。它包括许多实践，从 CI/CD 到监控、测试和协作。本书的旅程强调了理解 Salesforce 生态系统独特挑战的重要性，并利用专业的工具和技术有效应对这些挑战。

在本书的过程中，我们看到 DevOps 实践如何改变 Salesforce 开发团队的运作方式。通过自动化重复性任务、执行质量标准和培养持续改进的文化，团队可以更快速地交付更高质量的软件，并减少错误。此外，DevOps 强调的协作与沟通与 Salesforce 本身的协作性质高度契合，因为跨职能团队通常会一起合作，提供推动业务成功的解决方案。

随着 Salesforce 不断发展并引入新功能，保持对最新发展的了解变得越来越重要。对于希望在 DevOps 领域继续成长的 Salesforce 专业人士，以下建议可以作为持续职业发展的指南：

• 投资于持续学习：Salesforce 生态系统动态变化，定期推出新的版本和更新。为了保持与时俱进，专业人士应该通过 Salesforce Trailhead、网络研讨会、认证以及其他教育资源投入时间进行持续学习。

• 与社区互动：Salesforce 社区是一个丰富的知识和支持来源。通过论坛、用户组和活动与该社区互动，可以获得宝贵的见解以及建立网络和合作的机会。

• 拥抱新工具和技术：随着新工具和技术的出现，保持开放的态度去探索和采纳它们可以提供竞争优势。AI、ML 等领域的创新即将改变 Salesforce DevOps 的格局。

• 关注安全性和合规性：随着数据安全和隐私问题的日益关注，专业人士应该优先学习这些领域的技能。理解如何实施安全的 DevOps 实践变得越来越重要。

• 鼓励实验文化：鼓励团队尝试新的方法和技术。这种实验文化可以带来创新的解决方案和 DevOps 实践的改进。

• 培养软技能：技术技能至关重要，但软技能如沟通、领导力和解决问题的能力同样重要。发展这些技能可以提升团队协作和在 DevOps 环境中的效率。

当我们告别时，我们向 Salesforce DevOps 从业者提供以下建议：

• 保持敏捷：敏捷的原则——灵活性、对变化的响应以及增量交付——是 DevOps 的核心。在日常工作中要拥抱这些原则。

• 优先考虑质量：绝不妥协于工作的质量。质量是软件交付中信任的基石。

• 协作与分享：DevOps 不仅仅关乎流程和工具，同样关乎人与人之间的合作。分享你的知识，向他人学习，并合作实现共同的目标。

• 牢记最终用户：最终，你通过 DevOps 实践交付的软件是为了最终用户的利益。将他们的需求和体验放在决策的最前沿。

• 反思与改进：定期花时间反思你的实践、工具和结果。寻找改进和创新的机会。

Salesforce DevOps 是一个充满挑战与机遇的领域，要求具备技术专长、流程理解和协作技能的结合。作为从业者，我们的旅程是不断学习和适应的过程。通过拥抱本书中讨论的原则，并与 Salesforce 社区保持互动，我们可以继续成长，并为组织的成功做出贡献。Salesforce DevOps 不仅仅是部署软件；它关乎创造一种重视质量、效率和持续改进的文化。拥有正确的心态和工具，Salesforce DevOps 的创新与成功的可能性是无限的。