44、优化Salesforce管理与开发：从监控到DevOps实践

优化Salesforce管理与开发：从监控到DevOps实践

1. 应用性能监控

Apex允许使用 Limits Class 监控应用的限制。对于新发布的应用，如果担心特定指标，可以监控并记录堆大小和CPU执行时间等指标。将这些性能指标存储在自定义对象中，能以Salesforce原生方式监控应用性能，还可围绕这些指标构建报告和仪表盘。

当应用稳定且监控数据无值得分析的问题时，应关闭、禁用或删除监控系统。因为监控系统可能变得复杂，成为维护负担，所以设计时要注重简单性，移除很少使用的数据收集、聚合和警报配置。

2. Salesforce管理员的角色

Salesforce管理员常被称为“Awesome Admin”，他们是大量用户遇到问题时的主要升级点。与传统IT系统管理员不同，Salesforce管理员通常扮演双重角色：既是实际的管理员，负责监控生产系统的稳定性和可用性；又是应用构建者，通过点击式操作构建或改进Salesforce。

3. 点击式开发的管理

Salesforce的点击式（声明式）开发简单易用，吸引了很多人。但这种创新也存在风险，无管理的更改会导致混乱。因此，应像管理基于代码的开发一样管理点击式开发，通过开发和测试环境系统地推广更改，而非直接在生产环境中进行。

采用DevOps工作流能让管理员对更改有更多控制，确保更改传播到所有环境，并能轻松跟踪和回滚。DevOps平衡了创新与稳定性、安全性，对Salesforce应用构建者和编码者同样重要。

4. 管理员的DevOps指南

• 工具选择 ：如果公司使用Copado等对点击操作友好的发布管理工具，管理员可轻松成为DevOps专家；若采用传统方式，使用版本控制和Jenkins等通用CI工具，也能学习强大灵活的工具。
• DevOps流程
  1. 获取开发环境访问权限 ：可使用共享开发沙箱或克隆短期沙箱、临时组织。
  2. 进行更改并捕获 ：创建字段、使用应用构建器等，将更改捕获到版本控制中。
  3. 参与改进流程 ：参与交付管道，共同维护和改进，重点是改进自动化测试。

5. 应对挑战

在这个过程中，管理员会面临一些挑战：
- 部署错误 ：使用更改集也会遇到，需解决。
- Git合并冲突 ：大多数元数据类型的合并冲突较易解决，但配置文件和部分元数据类型的冲突较难处理，这也是Salesforce推广使用权限集的原因。

以下是管理员参与DevOps流程的步骤表格：
|步骤|描述|
| ---- | ---- |
|1|获取开发环境访问权限|
|2|在开发环境进行更改并捕获到版本控制|
|3|参与交付管道，共同维护和改进|
|4|解决部署错误和Git合并冲突|
|5|改进自动化测试|

下面是管理员参与DevOps流程的mermaid流程图：

graph LR
    A[获取开发环境访问权限] --> B[进行更改并捕获到版本控制]
    B --> C[参与交付管道]
    C --> D[解决部署和合并问题]
    D --> E[改进自动化测试]

优化Salesforce管理与开发：从监控到DevOps实践

6. 代码素养与DevOps

很多人对编程存在神秘感，但实际上，编写代码就像写作，代码编辑器大多是文本编辑器。非程序员与程序员的差距，就像不熟悉某种语言的人与熟悉者的差距。管理员培养基本的代码素养，能更好地参与DevOps流程。

管理员开始接触代码时，可能会对将配置表示为XML并在版本控制中跟踪和比较工作感到陌生，但这是非常有意义的。即使是经验丰富的程序员，学习新编程语言或技术时也会遇到困难。管理员通过使用Git和运行命令行脚本积累一些经验，能增强对代码的信心。

7. 参与交付管道的后续工作

当管理员能够在版本控制中跟踪配置更改后，就基本融入了交付管道。在这个阶段，管理员需要与团队共同维护和改进交付管道，主要是改进自动化测试。

团队使用的测试工具可能不同，从面向开发者到对管理员友好的都有。像Provar、Selenium和Tosca等UI测试工具，比基于代码的测试更易使用。如果有机会参与构建或指定这些测试，能确保所做的更改得到长期保护。

Salesforce对流程和流也开始实施代码覆盖率要求，这表明自动化测试的重要性。鼓励开发者以灵活的方式编写单元测试，采用行为驱动开发（BDD）风格的测试，使输入和输出易于阅读和调整。管理员可以复制和粘贴单个测试，调整输入和预期输出，来验证流程、流、工作流或验证规则的逻辑。参与单元测试是开始编码的低风险方式。

8. 锁定生产环境权限

在Salesforce的管理中，为了避免无管理的更改对生产环境造成影响，需要锁定部分用户对生产环境的权限。以下是具体的操作步骤：
1. 确定关注的权限 ：首先要确定哪些权限可能导致功能损坏或使生产环境与开发、测试环境不一致。至少应限制以下权限：
- Author Apex
- Customize Application
同时，要谨慎授予以下两个权限，并清楚谁被分配了这些权限：
- Modify All Data
- View All Data
2. 实施步骤
1. 明确并阐明实施权限限制的原因，最好提供业务和财务方面的理由。
2. 检查动机，确保是为了提高公司整体效率，而非对用户不信任。
3. 建立交付管道，并使用集成用户账户进行部署，确保账户使用安全的凭证。
4. 确保开发者和应用构建者管理员能在临时组织或开发沙箱中进行更改，并通过交付管道将更改部署到生产环境，且过程快速可靠。
5. 确定哪些配置文件和权限集赋予用户受限制的权限，以及哪些用户被分配了这些权限。
6. 考虑是否可以移除敏感权限或将其分离到新的权限集中，应用于较少的用户。
7. 确定少数可信赖的人员，保留真正的系统管理员访问权限，但要确保他们不会进行未经授权的更改。
8. 除集成用户和少数系统管理员外，锁定其他用户的权限。预计会有抱怨，确保获得高层支持，向受影响的用户解释，确定时间表并进行沟通。
9. 分阶段逐步推出权限更改，以减少业务影响，并确保能处理用户报告的问题。
10. 实施更改时，向高管团队说明情况和原因，应对抱怨并坚持立场。
11. 等待抱怨平息后，继续为团队管理强大而稳定的DevOps工作流。

以下是权限限制操作步骤的表格：
|步骤|操作内容|
| ---- | ---- |
|1|确定关注的权限|
|2|明确并阐明实施原因，提供业务和财务理由|
|3|检查动机，确保提高公司整体效率|
|4|建立交付管道，使用集成用户账户部署|
|5|确保人员能在沙箱操作并通过管道部署更改|
|6|确定赋予受限制权限的配置文件、权限集和用户|
|7|考虑移除或分离敏感权限|
|8|确定可信赖的系统管理员|
|9|锁定其他用户权限，沟通并确定时间表|
|10|分阶段推出更改，处理用户问题|
|11|向高管说明情况，应对抱怨|
|12|等待抱怨平息，管理DevOps工作流|

下面是权限限制操作步骤的mermaid流程图：

graph LR
    A[确定关注的权限] --> B[明确并阐明原因]
    B --> C[检查动机]
    C --> D[建立交付管道]
    D --> E[确保人员操作能力]
    E --> F[确定权限相关信息]
    F --> G[考虑权限处理方式]
    G --> H[确定可信赖人员]
    H --> I[锁定其他用户权限]
    I --> J[分阶段推出更改]
    J --> K[向高管说明情况]
    K --> L[等待抱怨平息，管理工作流]

通过以上对应用性能监控、管理员角色、DevOps实践以及权限管理等方面的操作和优化，能够更好地管理Salesforce环境，提高开发效率，保障系统的稳定性和安全性。