超级会员免费看
优化部署流程：从自动化到风险管控
1. 自动化部署
持续交付的核心在于使用自动化脚本或工具来执行部署。许多商业的发布管理工具都具备持续交付能力，可从版本控制进行持续的自动化部署。此外，也可以通过在传统 CI 工具中运行脚本来实现，这也是一种可行的方式。
2. 减小部署规模
自动化部署时，关键是要使部署规模小且速度快，同时能了解每个组织中元数据的状态。小部署规模能降低每次部署的风险和影响，还可避免未实际更改的 Salesforce 元数据的
lastModifiedDates
被修改。快速部署则有助于快速发布和测试修复及更新，在出现部署错误时，也能减少调试和解决问题的时间，因为解决所有错误所需的时间与单次部署时间成正比。
若要构建自己的 CI/CD 流程，可使用 Git 标签标记成功部署的时间点，再用
Git diff
确定自该时间点以来的更改内容。具体操作步骤如下：
1. 不同分支有不同规则。例如，在管理 UAT 环境的分支上提交代码时，使用以下命令确定上次成功部署到 UAT 环境的标签：
$ git describe --tags --match "uat-*" HEAD
-
找到标签后，将其作为
git diff命令的输入，以确定自该时间点以来哪些文件发生了更改：
$ git diff --name-only --ignore-all-space [name of the tag found above]
-
此命令会列出更改的文件，可将这些文件复制到新目录，作为“差异部署”的基础。如果使用 Metadata API 格式且不进行额外的 XML 处理，可能只能部署整个
.object文件，而使用“Source”格式则更便于部署较小的元数据子集，如特定字段而非完整对象。 -
如果更改文件子集部署成功，可使用
uat-[timestamp]标记仓库，将此提交标记为仓库的新状态。
3. 部署配置数据
存储配置数据时，应尽可能使用自定义元数据，而非自定义设置或自定义对象。因为自定义元数据可通过 Metadata API 与其他配置一起部署，无需特殊管理流程。
部署以数据形式存储的配置（如自定义设置或自定义对象中的数据）时，需将数据从一个组织提取并加载到另一个组织。应将这些配置和用于提取、加载数据的脚本存储在版本控制中。若数据包含特定于组织的 ID 或其他数据，可能需要进行转换。一些商业发布管理工具具备此功能，若要自行构建，可依靠 Salesforce 的 REST API（若配置数据量较大，可使用 Bulk API）。
部分 AppExchange 应用（如 CPQ 解决方案和 FinancialForce）涉及非常详细的配置数据，Vlocity 为此专门构建了工具，帮助客户在 CI/CD 流程中提取和加载数据包。
4. 持续交付的准则
“持续交付”不仅指自动化部署，还包括以下行为准则：
- 代码在单主干上开发，功能分支存在时间不超过一天。
- 每次向主干提交代码都会触发一组自动化测试。
- 若构建失败，团队的首要任务是在 10 分钟内修复（通过修复或回滚更改）。
团队成员应关注构建状态，将其视为团队运营的关键。例如，在构建失败时提交代码是不当行为，此时其他人应避免向主干推送提交，必要时应共同解决构建失败问题。
持续交付会在每次更改时自动将主干的更改部署或验证到一个或多个目标环境，从而增加额外的自动化测试层，如部署时的单元测试和部署后的 UI 测试。
以下是持续交付准则的流程图：
graph LR
A[代码开发在单主干] --> B[每次提交触发自动化测试]
B --> C{构建是否失败}
C -- 是 --> D[10分钟内修复]
C -- 否 --> E[自动部署或验证]
E --> F[单元测试和UI测试]
5. 跨多个生产组织部署
沙盒与生产组织相关，生产组织及其相关沙盒的元数据应保持相对相似，差异应为临时的。将更改从沙盒部署到单个生产组织，实际上是使这些组织更加一致，解决影响部署的元数据差异。
跨多个生产组织部署则面临不同挑战，因为这些组织的元数据通常不同。公司采用多个生产组织，通常是为了满足不同业务部门的独立和不兼容需求。
若多个生产组织需要共享某些功能，且该功能由第三方 ISV 创建的托管包提供，问题基本可解决。托管包可确保每次安装的元数据一致，只需确保在这些组织中一致配置和同时升级该包。
在解锁包出现之前，企业难以在多个生产组织之间同步元数据，容易出现“配置漂移”问题。因此，建议需要在多个生产组织之间维护相似功能的组织构建和维护解锁包（或寻找替代的托管包解决方案），这也有助于保持沙盒之间的一致性。
6. 管理组织差异
两个 Salesforce 组织之间的差异若不加以控制，会不断增加。组织间的显著元数据差异可分为有意和无意差异。治理的作用是消除组织间显著的无意差异，而有意差异又可分为临时和长期差异。
临时差异通常源于功能和修复的逐步推广和测试。使用包时，临时差异意味着不同组织安装了不同版本的包，测试组织通常包含最新版本，而生产组织可能在测试期间落后几个版本。使用基于组织的开发时，可通过 Git 分支管理临时差异，但这种分支模型与真正的持续集成或基于主干的开发存在矛盾，因此应逐步将元数据重构为包，每个包可在单主干上开发。
组织的长期差异与集成端点、组织范围的电子邮件地址等特定于组织的配置有关。版本控制的目标是了解这些相似性和差异，而 CI/CD 的目标是对组织进行控制。
即使在解锁包中，也可在一定程度上适应特定于组织的差异。可使用自定义元数据记录交叉引用组织 ID 来查找特定于组织的数据。例如，在 Apex 中可调用
UserInfo.getOrganizationId
，在公式字段（如工作流规则）中可引用
{!$Organization.Id}
，然后执行动态查找，如以下代码所示：
public static String getEndpoint(String serviceName) {
String orgId = UserInfo.getOrganizationId();
API_Endpoint__mdt endpoint = [
SELECT URL__c
FROM API_Endpoint__mdt
WHERE OrgId__c = :orgId
AND ServiceName__c = :serviceName
AND isActive__c=true
LIMIT 1];
return endpoint;
}
管理组织级元数据时，可使用相同的自定义元数据方法，并在部署过程中动态过滤和替换值。XSLT 是在 XML 文档中进行搜索和替换的常用语法，但语法较复杂，需处理 XML 命名空间。也可使用高级语言（如 Node、Java、Python 或 Perl）解析 XML，或使用标准 Unix 工具（如
sed
），但后者精度较低。
例如，以下是一个 Approval Process 的 XML 示例，引用了错误的用户：
<?xml version="1.0" encoding="UTF-8"?>
<ApprovalProcess xmlns="http://soap.sforce.com/2006/04/metadata">
<!-- ... -->
<approvalStep>
<allowDelegate>false</allowDelegate>
<assignedApprover>
<approver>
<name>wrongUser@yourOrg.com.sandbox</name>
<type>user</type>
</approver>
<whenMultipleApprovers>FirstResponse</whenMultipleApprovers>
</assignedApprover>
<label>Step 1</label>
<name>Step_1</name>
</approvalStep>
<!-- ... -->
</ApprovalProcess>
以下是一个 XSLT 转换示例，用于将错误用户替换为正确用户：
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="2.0"
xmlns:sf="http://soap.sforce.com/2006/04/metadata"
exclude-result-prefixes="sf">
<xsl:template match="sf:approvalStep/sf:assignedApprover/sf:approver/sf:name/text()">
<xsl:value-of select="replace(., '(wrongUser@yourOrg.com.sandbox)', 'correctUser@yourOrg.com')"/>
</xsl:template>
<!-- By default, leave everything else as it is -->
<xsl:output exclude-result-prefixes="#all" omit-xml-declaration="yes" indent="yes"/>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
虽然 Salesforce 对大多数元数据类型有内置逻辑，可将沙盒用户名转换为生产用户名，但在引用组织范围的电子邮件地址或特定元数据（如共享给特定用户的报告）时，可能会遇到问题。目前，Salesforce 正在研究通过允许元数据中的“别名”来解决此问题。
7. 依赖和风险分析
随着流程成熟，可考虑动态评估特定更改可能带来的风险。一些更改对组织的风险较大，在进行更改前需仔细审查。
一些工具提供商（如 Panaya 和 Strongpoint）为 Salesforce 发布了基于其他语言类似工具的工具，可评估元数据依赖关系，并根据对组织的潜在风险对提议的元数据更改进行评级。
研究表明，变更审批流程并不能提高组织稳定性，反而会降低部署速度，即使是仅适用于高风险变更的选择性变更审批流程也是如此。为降低部署风险，建议在版本控制中跟踪每个更改，频繁进行小部署，以最小化单次部署的影响，并通过与每次部署关联的自动化测试验证关键业务流程，确保其不受影响。
8. 总结
部署是创新交付的核心，虽然开发功能和解决 bug 所需的时间差异较大，但部署过程可变得快速且可预测。应通过自动化部署过程和建立稳定的节奏，减少部署所需的时间、精力和痛苦。
本文介绍了多种构建发布自动化的技术和相关工具，合理运用这些方法和工具，可优化部署流程，提高交付效率和质量。
优化部署流程：从自动化到风险管控
9. 自动化部署与小部署规模的优势总结
自动化部署和小部署规模在整个部署流程中具有显著优势，以下通过表格形式进行总结：
| 优势类型 | 具体优势 | 详细说明 |
| — | — | — |
| 自动化部署 | 提高效率 | 减少人工干预，持续进行自动化部署，节省时间和精力 |
| | 保证一致性 | 每次部署按照相同脚本或工具执行，确保部署结果一致 |
| 小部署规模 | 降低风险 | 减少每次部署的影响范围，降低出错概率 |
| | 便于调试 | 出现问题时，能快速定位和解决，减少调试时间 |
| | 避免元数据修改 | 防止未实际更改的元数据
lastModifiedDates
被修改 |
10. 配置数据部署的操作要点
在部署配置数据时，有以下操作要点需要注意：
1.
优先选择自定义元数据
：使用自定义元数据存储配置，可通过 Metadata API 与其他配置一起部署，无需特殊管理流程。
2.
数据提取与加载
：将配置数据从一个组织提取并加载到另一个组织，同时将配置和相关脚本存储在版本控制中。
3.
数据转换
：若数据包含特定于组织的 ID 或其他数据，需进行转换。可使用商业发布管理工具的内置功能，或依靠 Salesforce 的 REST API（数据量大时使用 Bulk API）。
以下是配置数据部署操作要点的流程图：
graph LR
A[选择自定义元数据] --> B[数据提取与加载]
B --> C{是否需数据转换}
C -- 是 --> D[进行数据转换]
C -- 否 --> E[完成部署]
D --> E
11. 持续交付准则的重要性及实践
持续交付准则对于确保部署流程的稳定和高效至关重要。以下是对持续交付准则重要性的详细分析及实践建议：
-
代码开发在单主干
：避免功能分支长期存在导致的代码冲突和集成问题，使代码始终保持可部署状态。
-
每次提交触发自动化测试
：及时发现代码中的问题，保证代码质量，减少部署后的错误。
-
快速修复构建失败
：在 10 分钟内修复构建失败问题，避免问题积累，确保团队的开发进度不受影响。
-
自动部署或验证
：实现部署过程的自动化，提高部署效率，减少人为错误。
-
单元测试和 UI 测试
：增加额外的测试层，确保部署的功能正常工作，提升用户体验。
在实践中，团队成员应养成关注构建状态的习惯，将持续交付准则内化为日常工作的一部分。当构建失败时，全体成员应共同协作，快速解决问题。
12. 跨组织部署的策略与挑战应对
跨多个生产组织部署时，需要根据不同情况采取相应的策略，并应对可能出现的挑战：
-
沙盒到单生产组织部署
：使生产组织及其相关沙盒的元数据保持一致，解决影响部署的元数据差异。操作步骤如下：
1. 分析沙盒和生产组织的元数据差异。
2. 确定需要同步的元数据内容。
3. 进行部署操作，确保元数据一致。
-
跨多个生产组织部署
：多个生产组织的元数据通常不同，若需共享功能，可使用第三方 ISV 创建的托管包。操作步骤如下：
1. 确定共享功能的需求。
2. 选择合适的托管包。
3. 在多个生产组织中一致配置和同时升级托管包。
13. 组织差异管理的方法总结
组织差异管理是部署过程中的重要环节，可分为临时差异和长期差异管理：
-
临时差异管理
：
-
使用包时
：不同组织安装不同版本的包，测试组织使用最新版本，生产组织在测试期间可落后几个版本。
-
基于组织的开发
：通过 Git 分支管理临时差异，但需逐步将元数据重构为包，以符合持续集成或主干开发的要求。
-
长期差异管理
：与集成端点、组织范围的电子邮件地址等特定于组织的配置有关。可使用自定义元数据记录交叉引用组织 ID 来查找特定于组织的数据，并在部署过程中动态过滤和替换值。
以下是组织差异管理方法的总结表格：
| 差异类型 | 管理方法 | 具体操作 |
| — | — | — |
| 临时差异 | 使用包 | 不同组织安装不同版本包，控制版本更新节奏 |
| | 基于组织开发 | 通过 Git 分支管理差异，逐步重构元数据为包 |
| 长期差异 | 自定义元数据 | 交叉引用组织 ID 查找特定数据 |
| | 动态过滤替换 | 在部署过程中对特定值进行过滤和替换 |
14. 依赖和风险分析的应用与建议
依赖和风险分析可帮助团队评估特定更改的风险，以下是其应用场景和相关建议：
-
应用场景
：当进行可能对组织产生较大影响的更改时，如添加验证规则到频繁使用的字段，使用工具评估元数据依赖关系和潜在风险。
-
建议
：
- 避免过度依赖变更审批流程，因为其不能提高组织稳定性，反而会降低部署速度。
- 在版本控制中跟踪每个更改，频繁进行小部署，以最小化单次部署的影响。
- 通过与每次部署关联的自动化测试验证关键业务流程，确保其不受影响。
15. 整体部署流程的优化建议
为了进一步优化部署流程，可从以下几个方面入手：
1.
加强自动化
：扩大自动化部署的范围，包括更多的配置数据和元数据，提高部署效率和一致性。
2.
持续监控
：建立监控机制，实时监测部署过程和系统状态，及时发现和解决问题。
3.
团队培训
：加强团队成员对部署流程和相关工具的培训，提高团队整体的技术水平和协作能力。
4.
定期评估
：定期评估部署流程的效果，根据评估结果进行调整和优化。
通过以上优化建议，可使部署流程更加稳定、高效，为创新交付提供有力支持。
扫一扫
983
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
