Salesforce-DevOps-全-

Salesforce DevOps（全）

原文：annas-archive.org/md5/ec167da03c90d6a18edd50835461d337

译者：飞龙

协议：CC BY-NC-SA 4.0

序言

Salesforce，凭借其强大的功能和特点，简化了企业在多个领域（如销售、营销和财务）的运作。部署 Salesforce 应用程序是一项复杂的工作，对于管理员和顾问来说，可能会非常繁琐。本书将帮助你为 Salesforce 实施 DevOps 并探索其功能。你将学习 Salesforce 企业运作中的 DevOps 原则和技术，并了解如何使用 Jenkins 和 Ant 脚本等工具实现持续集成和持续交付。你还将学习如何使用 Force.com 迁移工具和 Git 在 Salesforce 中实现版本控制。

本书适合谁阅读

如果你是一个 Salesforce 开发人员、顾问或经理，想要了解 DevOps 工具并为小型和大型 Salesforce 项目建立流水线，那么本书适合你。

本书涵盖的内容

第一章，Salesforce 开发与交付过程，概述了传统的 Salesforce 开发过程，包括使用的环境以及如何使用 Eclipse 和 Force.com IDE 设置环境。我们还将讨论沙箱和沙箱的类型。

第二章，将 DevOps 应用于 Salesforce 应用程序，讨论了 Salesforce 项目中 DevOps 的需求，以及在处理大型 Salesforce 项目的开发和部署时可能面临的挑战。

第三章，Salesforce 中的部署，展示了如何将 Salesforce 代码从一个沙箱部署到另一个沙箱，从一个沙箱部署到生产环境，及从一个组织部署到另一个组织。我们将了解不同类型的代码部署，并根据项目类型了解如何使用它们。

第四章，Force.com 迁移工具介绍，讨论了 Force.com 迁移工具以及如何在你的环境中设置该工具。我们还将看到如何使用 Ant 迁移工具将元数据部署到开发或测试沙箱。

第五章，版本控制，帮助你理解源代码版本控制系统及其类型。我们将主要关注分布式 Git 版本控制。我们还将学习如何在 Salesforce 项目中使用 Git，并将 Salesforce 元数据保存到 Git 中。

第六章，持续集成，展示了如何自动备份 Salesforce 元数据并使用 Jenkins 将代码推送到 Git 仓库。我们还将学习如何设置自己的 Jenkins 服务器，并配置它从 Salesforce 沙箱中检索元数据。

第七章，持续测试，讲述了代码质量和持续测试。我们将讨论自动化测试中使用的工具，如 Selenium 和 Qualitia。我们还会展示如何在一个示例 Salesforce 应用中使用 Selenium 进行记录和回放的测试用例。

第八章，跟踪应用程序变化及将 DevOps 应用到 Salesforce 的投资回报率，讨论了 Bugzilla 的基础知识以及如何在测试人员或用户报告问题时进行跟踪。我们还将学习如何提高生产力并衡量 ROI。

为了充分利用本书

要遵循本书中的指示，您需要一个安装了以下软件的 Windows 系统：

Java
Eclipse
Git
Jenkins
ANT
PMD

下载彩色图片

我们还提供了一份包含本书中截图/图表的彩色图片的 PDF 文件。您可以在这里下载：www.packtpub.com/sites/default/files/downloads/9781788833349_ColorImages.pdf。

使用的约定

本书中使用了多种文本约定。

CodeInText：表示文本中的代码词汇、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 账号名。以下是一个例子：“在命令面板中输入 apex stat。”

一段代码设置如下：

<?xml version="1.0" encoding="UTF-8"?>
<Package >
    <version>42.0</version>
</Package>

当我们希望您关注代码块的特定部分时，相关的行或项目会以粗体显示：

<?xml version="1.0" encoding="UTF-8"?>
<Package >
    <version>42.0</version>
</Package>

所有命令行输入或输出如下所示：

$pmd -d "Source Path" -R apex-ruleset -language apex -f CSV > "Destination Ptah\ReportName.csv"

粗体：表示一个新术语、重要的词汇或您在屏幕上看到的文字。例如，菜单或对话框中的文字会以这种方式显示。以下是一个例子：“输入项目名称和组织设置详情以建立连接。”

警告或重要提示如下所示。

提示和技巧如下所示。

联系我们

我们非常欢迎读者的反馈。

一般反馈：通过电子邮件 customercare@packtpub.com 并在邮件主题中注明书名。如果您对本书的任何内容有疑问，请通过电子邮件与我们联系，地址为 customercare@packtpub.com。

勘误：尽管我们已经尽一切努力确保内容的准确性，但错误还是会发生。如果您在本书中发现错误，我们将非常感谢您向我们报告。请访问 www.packt.com/submit-errata，选择您的书籍，点击“勘误提交表单”链接，并输入详细信息。

盗版：如果您在互联网上发现任何非法复制的作品，我们将非常感谢您提供该作品的地址或网站名称。请通过 copyright@packt.com 与我们联系，并提供该资料的链接。

如果你有兴趣成为作者：如果你在某个领域有专业知识，并且有兴趣编写或贡献一本书，请访问 authors.packtpub.com。

评价

请留下评价。阅读并使用本书后，为什么不在你购买该书的网站上留下评价呢？潜在读者可以看到并参考你的公正意见来做出购买决策，我们在 Packt 可以了解你对我们产品的看法，而我们的作者也能看到你对他们书籍的反馈。谢谢！

欲了解更多关于 Packt 的信息，请访问 packt.com。

第一章：Salesforce 开发和交付过程

在我们深入探讨 Salesforce 的 DevOps 过程或如何将 DevOps 应用于 Salesforce 应用程序之前，我们首先看一下典型的或传统的 Salesforce 开发是如何在组织中进行的。

在本章中，我们将了解 Salesforce 应用程序的传统开发过程。我们将概述一些 Salesforce 的概念，例如沙箱，包括不同类型的沙箱及其区别。我们将看到我们的示例应用程序——Recruiting 应用的开发过程，并解释 Salesforce 概念。我们还将讨论在 Salesforce 应用程序的开发、部署和交付过程中遇到的技术挑战。我们将讨论没有 DevOps 的 Salesforce 开发者的工作生活及 DevOps 的必要性。

在本章中，我们将学习以下主题：

典型的 Salesforce 开发过程（没有 DevOps）
沙箱
Salesforce 开发的 Eclipse 使用
商业和技术挑战
DevOps 的必要性

典型的 Salesforce 开发过程（没有 DevOps）

Salesforce 开发不同于其他堆栈开发平台。你所需的一切开发工具都可以通过云端获得，无需安装任何软件。基于沙箱的开发的主要缺点是沙箱不提供代码版本控制。因此，如果有人覆盖了你的代码，你将无法获取代码的先前版本。这会导致在多个开发人员共同参与的大型项目中出现严重的混乱。

我们将通过创建自己的 Salesforce 开发者版账户开始开发，且此账户免费。注册 Salesforce 免费账户并进行测试。以下是一些新 Salesforce 用户创建自己 Salesforce 应用程序的指南，使用 developer.salesforce.com/signup：

登录到你的 Salesforce 账户并提供用户名和密码。
转到屏幕右上角的设置。然后在快速查找框中搜索“应用”，再选择“应用”。你将看到应用的欢迎页面。在欢迎页面上，你将看到一些已为你的组织启用的应用。
我们想创建一个新的应用程序。点击“新建”按钮。由于你是新用户，选择“自定义应用”。输入Recruiting作为应用程序标签名。一个应用程序是一个由多个标签组成的集合，用于创建功能。用户可以在不同应用程序之间切换：

在下一个屏幕上，你可以选择将用作应用程序徽标的图像。测试时，你可以使用默认图像或上传自己选择的图像。你可以稍后更改它。
下一个屏幕让您指定在应用程序中想要查看的标签。已经有一些标准和自定义标签供您选择，或者您可以创建自己的自定义标签。对于示例应用程序，您可以接受默认设置并转到下一页。主页标签将作为默认标签显示。
在下一个屏幕上，您需要选择哪些用户配置文件将能够访问该应用程序：

使其对标准用户和系统管理员配置文件可见。
保存并完成。

传统部署

部署代码到沙盒或生产环境进行测试有两种方式：

变更集：变更集用于将变更从开发沙盒迁移到生产环境。变更集不包含数据。变更集最适用于将相同的组件部署到多个组织。变更集适合小型部署，但不适用于大型部署。对于大型部署，可以使用 Force.com 迁移工具，因为部署组件可以更容易地进行管理。
Force.com 迁移工具：使用 Force.com 迁移工具需要一些设置。它是可脚本化的，因此适用于多阶段发布过程，在此过程中，我们可以轻松地编写脚本来检索和部署组件。可以使用参数进行重复部署。我们可以检索组织中的所有元数据，使用编辑器进行更改，并部署相同的组件子集。

传统部署的问题

沙盒环境中不提供版本控制，因此当多个开发人员在同一个项目上工作且未同步时，管理变得困难。跟踪项目中的所有变更就像在大海捞针。使用变更集进行部署不推荐用于大型项目，而且创建变更集无法脚本化，因此它成为一项重复性任务。

Force.com 迁移工具适用于大型项目，但我们没有版本控制，因此无法将代码恢复到先前版本。此外，我们也无法追踪开发人员所做的变更。

在几乎所有技术栈中，我们都有不同的环境，比如开发、测试、预发布和生产环境。在 Salesforce 中，我们使用沙盒来作为开发和测试环境。根据需求，沙盒有不同的类型，我们可以选择使用哪种沙盒。让我们看看不同类型的沙盒。

沙盒

"沙盒是生产组织的副本，包含相同的配置或元数据，如自定义对象和字段、流程构建器、流程等。"

沙盒类似于其他技术栈中的开发（dev）、测试（test）和阶段（stage）环境。它们主要用于 Salesforce 应用程序的开发和新功能的测试。我们不希望在生产环境中直接进行更改而不彻底测试。因此，我们需要这些不同类型的沙盒；根据我们可以在其中做的事情，我们可以选择使用哪种沙盒。有些沙盒仅包含来自生产的元数据，而有些则可能包含元数据和数据。沙盒的大小也各不相同。让我们来看看它们的区别。

沙盒用于开发和测试应用程序。根据你使用的沙盒类型，它也可能包含来自生产组织的数据副本。沙盒与生产组织完全隔离，因此开发人员所做的任何更改都不会影响生产组织中其他用户的数据、应用程序或日常活动。这对于开发复杂的自定义功能以最小化风险非常理想。

沙盒有多种类型：

开发者：开发者沙盒用于开发和测试。它为开发人员提供了一个独立的环境，用于编码和测试所做的更改。根据 Salesforce 的标准，一个开发者沙盒应该由一个开发人员在同一时间使用进行编码，但多个开发人员也可以同时登录。然而，开发者沙盒不会跟踪其中所做的更改，因此有很多可能性，开发人员可能会覆盖彼此的代码。开发者沙盒包含来自生产的元数据，但不包含数据。
开发者专业版：开发者专业版沙盒也是用于开发和测试目的，但该沙盒提供了更大的存储空间。由于存储空间的增加，这个沙盒可以处理更多的开发工作负载，并且可以用于数据加载和集成测试。
部分复制：部分复制沙盒包含来自生产组织的所有元数据，并且还包含生产组织数据的一个样本，这些数据是在创建部分复制沙盒时通过沙盒模板定义的。由于该沙盒包含样本数据，因此主要用于测试目的。我们可以将部分复制沙盒用于开发、测试，甚至用于培训目的。大多数人不建议将其用于负载测试。
Full：Full 沙箱是您生产环境的副本。它包含来自生产组织的所有元数据和数据。它包含所有数据，包括记录、附件等。您可以使用沙箱模板来决定从生产环境复制哪些数据到 Full 沙箱，具体取决于您要执行的测试操作。Full 沙箱可以用于许多目的，支持负载测试、性能测试和阶段测试。由于需要较长的刷新间隔，使用 Full 沙箱进行开发较为困难。

用于 Salesforce 开发的 Eclipse

首先，我们将介绍如何使用 Eclipse 进行 Salesforce 应用程序开发。我们将从最基本的步骤开始，比如安装 Eclipse 和 Force.com IDE，接着配置 Git 与 Eclipse 的结合。

安装带有 Force.com IDE 插件的 Eclipse Neon

我们将从在开发者机器上安装 Eclipse 开始。安装 Eclipse 之前，您需要至少安装 Java 6。如果未安装，可以通过官网安装：java.com/en/download/。

我们将安装 Eclipse Neon。Eclipse Neon 需要 Java 7 版本。

以下是 Salesforce 开发环境的先决条件：

操作系统：
- Windows 7、8 或 10
- macOS 10.7、10.8、10.9、10.10 或 10.11
- Ubuntu 12.04 LTS 或 14.04 LTS
Java SE 开发工具包（JDK），运行环境 8 或更高版本（Java 下载页面）。

安装步骤如下：

推荐使用 Eclipse 4.5 或更高版本。请访问下载网站：www.eclipse.org/downloads/。
选择适用于您操作系统的可执行包。
下载完成后，您可以继续进行 Eclipse 安装。如果您使用的是 Windows，请双击 .exe 文件。
推荐的安装器是 Eclipse IDE for Java Developers 版本。
选择一个安装文件夹用于安装 Eclipse，然后点击“安装”。安装 Eclipse 可能需要一些时间。
安装完成后，启动 Eclipse。选择 Eclipse 的工作空间。
您将看到 Eclipse 的欢迎页面。

现在我们已经在系统上安装了 Eclipse，接下来可以继续安装 Force.com IDE。

以下是安装 Force.com IDE 的步骤：

启动 Eclipse，进入帮助选项，并从下拉列表中选择“安装新软件”选项：

点击添加。
在添加仓库对话框中，设置名称为 Force.com IDE，位置为 https://developer.salesforce.com/media/force-ide/eclipse45：

点击确定。
如果您没有使用 Java 8，请取消选择“仅显示最新版本的可用软件”，这样会显示插件的旧版本。
Eclipse 将显示所有可用插件的列表。选择 Force.com IDE 插件，然后点击“下一步”。
在安装详情对话框中，点击“下一步”。
审查许可证，接受条款，并点击“完成”。
Eclipse 开始下载 Force.com IDE 并安装它和其他所需的依赖项。安装完成后，你需要重启 Eclipse 以使更改生效。点击“是”。
当 Eclipse 重启后，选择“窗口”|“打开视图”|“其他”。选择 Force.com，然后点击“确定”：

我们已经完成了在 Eclipse 中设置 Salesforce 开发环境。

在 Eclipse 中配置 Force.com 项目

我们有一个 Salesforce 应用，并且希望将 Salesforce 代码放入我们刚刚使用 Force.com IDE 创建的本地工作空间：

右键单击 Package Explorer 区域，然后选择“新建”，选择 Force.com 项目：

创建一个新的 Force.com 项目。你需要提供关于项目的详细信息。输入项目名称和组织设置的连接详情：
- 用户名：提供一个用户名，并将沙箱名称附加到用户名后面。
- 密码：为给定的用户名提供一个密码。
- 安全令牌：你需要为沙箱提供一个安全令牌。
- 环境：选择你正在使用的环境，例如沙箱或生产版：

填写所有详情后，点击“下一步”。

我们将从 Salesforce 获取所有代码到 Eclipse 中。现在，无论开发人员在 Eclipse 中做出什么更改，都将与正在使用的沙箱保持同步。

技术和业务挑战

按照传统方法进行 Salesforce 项目的部署是费时的。而且，主要问题出在代码的版本管理上，这会在每个环境中引发问题。某个特性可能在开发者沙箱中运行完美，但我们可能会在生产环境中遇到问题。追踪开发人员和管理员所做的每一次更改是非常困难的，因此，团队之间的沟通不畅可能导致部署失败或产品交付延迟。

我们可以考虑一种情况，即某个特性需要尽快上线，而我们遇到了部署问题。我们可能无法及时解决这些问题，这将影响到我们的客户和业务。我们将面临以下挑战：

部署失败
无法追踪问题
没有代码覆盖率
测试用例失败

我们需要简化所有这些问题，并找到一个能够解决几乎所有问题的解决方案；在这里，DevOps 就发挥了作用！！

Salesforce 的 DevOps？

是的，我们可以将 DevOps 实践应用于 Salesforce 项目，并实现 Salesforce 项目的持续集成、持续部署和持续测试。在 DevOps 中，我们有丰富的工具集，也可以用于 Salesforce 项目。

让我们一步一步地来讨论。第一个也是最重要的考虑因素是，如何在 Salesforce 中实现版本管理，因为 Salesforce 沙箱本身并不会存储代码的版本。Salesforce 沙箱仅会存储一些最基本的变更信息，比如哪个用户进行了上一次的修改及其时间戳。显然，这些信息不足以实现完整的版本管理。我们可以使用一个非常流行的源代码管理工具，Git，来管理 Salesforce 项目，其中沙箱将与 Eclipse 工作空间和 Git 仓库同步。

Salesforce 提供了一个非常有用的工具，用于将元数据从本地仓库迁移到沙箱，这就是 Force.com 迁移工具。Force.com 迁移工具是一个基于 Ant 的工具，用于将元数据从沙箱迁移到本地仓库。使用 Force.com 迁移工具，我们可以执行诸如从沙箱检索元数据和将元数据部署到沙箱等操作。

使用 Force.com 迁移工具和 Jenkins，我们可以构建持续集成任务。Jenkins 是一个自动化服务器，允许我们自动执行任务，如在特定环境下构建、测试和部署软件。Jenkins 是用 Java 编程语言编写的，允许我们创建持续集成任务。在接下来的章节中，我们将看到如何将 Force.com 迁移工具与 Jenkins 配合使用，并在 Salesforce 项目中自动化持续集成任务。

查找问题就像大海捞针。我们需要在项目中跟踪问题。目前有许多应用程序可以在我们的项目中使用，例如 Bug Tracker 和 Jira。这些工具帮助我们了解项目中的问题，以及它们所在的环境；同时，它们还帮助我们保持进度并保持最新状态。我们将在后续章节中详细介绍其中的一些应用程序。我们还将探讨如何将这些工具整合，并为 Salesforce 项目建立 CI-CD 管道。

借助 Selenium 和 Qualitia 等工具，可以实现 Salesforce 的持续测试。Selenium 是一个用于测试 Web 应用程序的测试框架。Qualitia 是一个无脚本自动化工具，帮助创建无需编写脚本/代码的测试用例。

你是否还对将 DevOps 应用到 Salesforce 存有疑问？答案可能是肯定的，也可能是否定的，但等等，不要把这个作为你最终的答案，因为你还需要阅读接下来的章节，我们将在这些章节中尝试提供一个更清晰的关于如何使用 DevOps 工具进行 Salesforce 项目的概念。此外，我们还将涵盖一些关于 DevOps 和 Salesforce 的示例和实时场景，所以请继续关注！

总结

在这一章中，我们概述了传统的 Salesforce 开发过程，介绍了哪些环境用于 Salesforce 开发，以及如何使用 Eclipse 和 Force.com IDE 设置 Salesforce 开发环境。我们还了解了沙盒以及 Salesforce 项目中使用的沙盒类型，并分析了它们之间的区别。

我们还获取了一些关于传统 Salesforce 项目部署方法的信息，例如变更集和 Force.com 迁移工具，并讨论了哪些方法适用于小型和大型项目。我们还探讨了 Salesforce 中的技术和业务挑战。

在下一章，我们将探讨如何将 DevOps 应用于 Salesforce 项目。我们将比较其他技术栈与 Salesforce，并了解将 DevOps 应用于 Salesforce 与其他技术栈中的 DevOps 有何不同。我们还将讨论将 DevOps 应用于 Salesforce 的各种方式。

第二章：将 DevOps 应用于 Salesforce 应用程序

在上一章中，我们学习了关于 Salesforce 开发流程的一些基础知识，了解了什么是沙箱，沙箱的不同类型，以及如何根据我们的需求选择沙箱。我们使用 Salesforce 开发了自己的招聘应用程序，随后学习了 Salesforce 部署的传统方式。我们还了解了在传统的 Salesforce 应用部署过程中遇到的问题。我们学习了如何通过 Eclipse 设置 Salesforce 开发环境，并讨论了如何将 DevOps 应用于 Salesforce 应用程序。

本章中，我们将讨论为什么在 Salesforce 应用程序中需要 DevOps。我们还将讨论在涉及大量开发人员、测试人员等的大型项目中，我们面临的挑战。我们将尝试澄清将 DevOps 应用于 Salesforce 与将其应用于其他技术栈（例如简单的 Java 应用程序栈）之间的不同。我们将区分 Salesforce 应用程序开发过程中与其他技术栈（如 Java、PHP、Ruby 等）开发过程中所涉及的不同之处。我们还将详细了解 Java 应用程序中的 DevOps 流程，以便更清楚地了解 DevOps 持续集成和交付过程，以及如何使用 DevOps 工具进行操作。我们将逐步介绍如何使用 Jenkins 和 Git 设置一个简单的持续集成管道。我们还将学习如何安装所需的插件，如何在 Jenkins 中配置 Maven 插件，以及如何在 GitHub 项目中添加 Jenkins Webhook URL；我们还将实现使用 Jenkins 插件进行持续部署。最后，我们将了解如何在任何更改推送到 GitHub 时自动部署我们的代码。

本章中，我们将学习以下内容：

在 Salesforce 开发中对 DevOps 流程的需求。
Salesforce 的 DevOps 与其他技术栈的 DevOps 之间的区别。例如，Java 开发栈的典型 DevOps 流程。

在 Salesforce 开发中对 DevOps 流程的需求

正如在上一章中讨论的那样，我们可以在 Salesforce 项目中应用 DevOps 实践，以实现更快速的应用交付。那么，问题来了，为什么我们需要 DevOps？

让我们讨论一下 Salesforce 项目中的一些常见开发实践。在 Salesforce 中，一切都在云端，你只需要一个浏览器和互联网连接，就可以开始开发应用程序。但是随着开发团队的增长，构建不同功能并将它们部署到生产环境中的复杂性也变得更加困难。虽然我们可以根据需要使用不同类型的沙箱，但管理部署流程仍然是一个耗时的任务。

考虑到多个开发人员在不同的沙盒环境中处理不同的功能，我们需要从这些环境中挑选一些功能并将其部署到 用户验收测试（UAT）环境中。这个过程容易出错，因为它涉及多个阶段的人为操作。此外，我们没有任何版本控制系统来管理开发人员所做的更改。

假设我们设法与多个开发人员在多个沙盒环境中合作，并且不管理源代码（虽然这只是一个假设情况，但可以认为是可能的）。那么，如何测试应用程序中的新特性，更重要的是，如何确保不会破坏之前的应用程序呢？通过手动测试来实现这一点将需要大量的测试人员，而且我们仍然无法确保已测试每一个功能，从登录到我们刚刚在应用程序中引入的复杂功能。

为什么要做如此繁琐的工作，当我们可以借助 DevOps 实现更精简的交付呢？DevOps 减少了交付时间，使过程更不易出错；通过一系列开源工具，跟踪应用程序变得更加容易。我们可以通过将 Salesforce 应用程序开发过程与 DevOps 工具集（如 Git）集成，以保持源代码版本。我们将更详细地介绍如何在第六章，持续集成中实现这一点。

DevOps 帮助其他技术栈的应用程序提高生产力，并遵循更快的交付流程。我们可以通过对开发和交付流程进行一些修改，在 Salesforce 项目中实现快速交付。DevOps 将直接或间接地影响参与 Salesforce 应用程序开发、测试和部署的所有人员，以及其他终端用户。

Salesforce 的 DevOps 与其他技术栈的差异

在 Salesforce 中应用 DevOps 与其他环境不同，让我们一步一步来看。

首先，我们将讨论开发过程。Salesforce 开发容易上手，因为你不需要在开发机器上进行任何安装或额外的设置。你所需要的只是一个互联网连接和一个 Salesforce 支持的浏览器，如 Internet Explorer、Google Chrome、Safari 等。如我们在上一章所示，Salesforce 中的示例应用程序只需几次点击就能轻松开发，因为 Salesforce 提供了一些现有的应用程序和标签供你重用。我们可以根据需求在应用程序中创建一些自定义标签。当谈到其他技术栈（如 Java）时，为了开始开发，我们需要在机器上安装 Java 并设置一些环境变量。

在 Java、JavaScript、PHP 和 Ruby 等技术栈中，最常见的做法是使用版本控制系统，如 Git、CVS、SVN 等，帮助追踪每个开发人员对应用所做的更改。版本控制系统使多个开发人员能够在同一个项目或模块上工作而不覆盖彼此的更改。在某些情况下，比如当出现问题且我们需要回滚更新时，版本控制非常有用。

当我们只有一两名开发人员在开发一个 Salesforce 应用时，可能不需要使用版本控制。但当团队中有多个开发人员在不同的沙箱中工作，开发不同的功能并在不同的时间线或冲刺中发布时，使用版本控制就变得必要，以便实现精简的开发和交付过程。

有几种方法可以将更改部署到 Salesforce 生产组织中，例如使用 Change Set、Eclipse 和 Ant。对于使用 Change Set 的部署，你需要通过部署连接来连接组织。Eclipse 使用元数据进行部署，主要由开发人员使用。使用 Ant 进行部署时，我们可以执行基于文件的部署到生产组织。

示例 – Java 开发栈的典型 DevOps 流程

前提条件如下：

Java 版本 1.6 或更高
Apache Maven 3.5.2
Jenkins 服务器

注意：请使用最新版本的软件。将来，先前的版本可能不兼容。

如果你还没有安装 Java，可以从官方网站下载：java.com/en/download/。

使用以下命令来配置此示例 CI/CD 应用。我将使用一个 Ubuntu 16.04 实例进行设置。那么我们先开始安装 Java。

以普通用户身份登录到你的 Ubuntu 服务器机器。我们需要一个具有 sudo 权限的用户来安装机器上的软件包。这里我将使用 Ubuntu 的用户名作为示例：

# sudo apt-get update 
# sudo apt-get install default-jdk

之前的命令将在机器上安装 Java 8 版本。可以使用以下命令验证：

注意：如果 Java 版本更新到一个稳定版本，则相同的设置应当能够正常工作。

$java -version
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

现在我们已经安装了 Java，接下来我们将安装 Maven。安装步骤如下：

从官方网站下载 Maven：

$wget http://www-eu.apache.org/dist/maven/maven-3/3.5.2/binaries/apache-maven-3.5.2-bin.tar.gz

使用以下命令提取包：

$tar -xvf apache-maven-3.5.2-bin.tar.gz

我们需要设置环境变量。在 .bashrc 中添加路径：

$export M2_HOME=/home/ubuntu/apache-maven-3.5.2
$export PATH=${M2_HOME}/bin:${PATH}
$source ~/.bashrc

验证是否在机器上安装了 Maven：

$ mvn -v
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z)
Maven home: /home/ubuntu/apache-maven-3.5.2
Java version: 1.8.0_151, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "4.4.0-1049-aws", arch: "amd64", family: "unix"

我们将在 Maven 中创建一个项目。这里我们将使用官方的 Maven 示例 Maven in 5 Minutes。你可以在参考部分找到链接。

接下来我们创建一个 Maven 示例项目：

$mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

下载依赖项需要一些时间。命令执行完成后，它会创建一个目录，目录名称为传递给DartifactId的值，即my-app。

在这个示例中，src/main/java 包含源代码，src/test/java 包含测试代码，而 pom.xml 包含构建项目所需的所有信息。

以下是我们从示例应用中获得的源代码：

cat src/main/java/com/mycompany/app/App.java
package com.mycompany.app;
/**
 * Hello world!
 *
 */
public class App
{
 public static void main( String[] args )
 {
 System.out.println( "Hello World!" );
 }
}

现在我们来构建我们的示例项目：

#mvn package

这将编译项目并在目标文件夹中创建一个名为 my-app-1.0-SNAPSHOT.jar 的 JAR 文件。

使用以下命令测试 JAR 文件：

#java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App

我们得到以下输出：

Hello World!

现在，我们的示例应用已经运行起来了，但如果有多个开发人员在项目上工作怎么办？我们需要一个版本控制工具以及一些标准的部署流程，将该项目部署到服务器环境中。为此，我们将按照我们的示例 DevOps 流水线，使用 Git 和 Jenkins。

Git 是一个版本控制工具，它帮助我们跟踪源代码中的更改，并与不同的开发人员协调工作。它是当今最常用的版本控制工具。我们将在第五章《版本控制》中深入了解 Git。对于这个示例流水线，我们可以使用 GitHub 账户。

在 GitHub 上创建一个代码仓库，并将示例代码推送到该仓库：

$cd my-app
$Git init
$Git add .
$Git commit -m "first commit"
$Git remote add origin https://Github.com/priyankadive/devops-sample.Git
$Git push -u origin master

现在我们的版本控制准备好了，我们将继续下一步，使用 Jenkins 进行持续集成和持续交付。

Jenkins 是一个开源工具，用 Java 编写。它用于自动化持续集成和持续交付工作。我们将在第六章《持续集成》中详细介绍 Jenkins。

让我们开始使用 Jenkins：

安装 Jenkins。我已在一台 Ubuntu 服务器上安装了 Jenkins。
登录到 Jenkins 服务器。
使用以下过程，在 Jenkins 服务器上安装所需的 Jenkins 插件。
进入“管理 Jenkins” | “GitHub 插件”并搜索 maven plugin。
如果在设置 Jenkins 时没有安装 Maven 插件，请在 Jenkins 中安装该插件。你需要在 Jenkins 全局工具配置中配置 Maven，因为我们已经安装了它。

在 Jenkins 服务器中配置 Maven

进入“管理 Jenkins” | “全局工具配置”。

我们已经在机器上安装了 Maven。所以输入 Maven 安装的名称和 M2_HOME 路径，如下所示：

让我们配置我们的 Jenkins 任务，来构建我们的示例项目：

点击创建新任务：

创建一个带有 Maven 插件的 Jenkins 任务。提供任务名称 devops-ci-cd（如果你愿意，可以选择另一个项目名称）：

在源代码管理部分，提供你的项目的 Git URL。提供凭据以便在 Jenkins 中克隆该仓库：

在构建触发器中选择 GitHub 钩子触发器进行 GitScm 轮询。如果 Jenkins 收到来自前述仓库的 PUSH GitHub Webhook，它将触发该任务：

提供 pom.xml 的根路径。这将是相对于模块根目录的路径。在构建中，添加根 POM 文件为 pom.xml，并将 Goals 和选项设置为 package：

保存您的工作并点击立即构建。

这将在 "/var/lib/Jenkins/workspace/target" 文件夹中创建 my-app-1.0-SNAPSHOT.jar 文件。在项目构建过程中，您可以查看控制台日志。

一旦 JAR 文件成功构建，您可以看到如下截图所示的控制台日志：

我们已经成功完成了持续集成任务。现在，我们需要在 GitHub 设置中添加 Jenkins webhook URL，以便每当有人将代码推送到我们的 GitHub 项目时，Jenkins 会自动触发构建。

在 GitHub 项目中添加 Jenkins webhook URL

要添加 Jenkins webhook URL，请按照以下步骤操作：

从 "Manage Jenkins | Configure System | GitHub Web Hook Section" 获取您的 GitHub webhook URL。

示例 URL：https://<your-domain-name or IP address>/web-hook/

转到 GitHub | 选择您的项目。进入设置并选择集成和服务。点击添加服务并搜索 Jenkins。结果中会显示两个服务：Jenkins（Git 插件）和 Jenkins（GitHub 插件）。根据您的项目选择其中一个。我们选择 Jenkins（GitHub 插件）：

添加您的 Jenkins webhook URL 并点击添加服务：

通过点击测试服务来验证 hook 是否工作正常。它会将我们的测试负载发送到 Jenkins 服务器。如果一切正常，我们将看到 Jenkins webhook 前面有一个绿色勾选标记：

要测试您的持续集成管道，请在我们创建的 README 文件中添加一些更改。将更改推送到 GitHub。

在 Jenkins 中，您可以看到如下面截图所示的 "devops-ci-cd" 构建已经自动启动：

持续部署

我们已经完成了持续集成步骤。当 GitHub 项目的源代码更新时，我们的 Jenkins 服务器将构建一个 .jar 文件。接下来，我们需要将更新的代码部署到远程服务器。SSH 是一种广泛使用的安全外壳协议，用于安全地登录到远程系统。在这个示例应用程序中，我们将使用 Publish Over SSH 插件。该插件用于通过 SSH 协议将构建工件发送到远程服务器并执行命令。

在 Jenkins 服务器上安装 Publish Over SSH 插件

现在，我们将编辑之前创建的 Jenkins 任务。作为持续集成步骤的输出，我们在 Jenkins 工作空间中得到了创建的 my-app-1.0-SNAPSHOT.jar 文件。为了将此 JAR 部署到我们的测试服务器上，我们将使用一个简单的 Jenkins 插件——Publish Over SSH。这个插件允许我们将文件传输到远程服务器并运行命令。首先，我们需要在“管理 Jenkins”页面上设置 SSH 私钥。进入“管理 Jenkins”|“配置系统”，并提供以下信息：

密码短语：为密钥提供密码短语（如果未加密则留空）
密钥路径：密钥路径可以是绝对路径，也可以相对于 $JENKINS_HOME。
密钥：如果密钥不存在于 Jenkins 服务器上，则可以将其复制并粘贴到此字段中
添加 SSH 服务器的详细信息，如用户名、主机名和远程目录：

现在回到我们之前的 Jenkins 任务，并从“构建后步骤”中选择“仅在构建成功时运行”选项，这样只有在构建成功时，后续步骤才会被执行。

从“添加构建后步骤”下拉列表中选择“通过 SSH 发送文件或执行命令”选项：

添加以下配置以将 JAR 文件复制到测试服务器并运行命令启动它：

部署 Hello world! 的命令如下：

#java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App

我们已经完成了使用 Maven 和 Jenkins 对我们的示例 Java 应用程序进行持续集成和持续部署的过程。因此，每当开发者将代码提交到 Git 时，Jenkins 任务将被触发，执行构建步骤以创建 JAR 文件并将其部署到测试服务器，如果构建成功的话。我们可以添加一个步骤，在部署的应用程序上执行自动化测试用例，并获取我们新变更的结果。

总结

在本章中，我们讨论了为什么在 Salesforce 项目中需要 DevOps，以及在处理大型 Salesforce 项目的开发和部署时可能会面临的挑战。同时，我们还探讨了为什么 Salesforce 的 DevOps 与其他技术栈不同，以及从开发、设置环境和将变更部署到 Salesforce 生产环境与其他技术栈的区别。

我们了解了典型的 Java 开发栈的 DevOps 流程，在这个过程中我们创建了一个示例 Java 应用程序，并使用 Git 版本控制来跟踪在开发过程中所做的更改。我们学习了如何在 GitHub 项目中添加 Jenkins Webhook URL。我们设置了一个示例 Jenkins 任务，其中添加了一个 Maven 构建步骤，当任何人向 Git 主分支推送代码时，就会通过 Jenkins Webhook 创建一个 JAR 文件。在完成示例 Java 应用程序的持续集成步骤之后，我们在 Jenkins 任务中添加了一个使用 Publish Over SSH 插件进行持续部署的步骤。

在下一章中，我们将讨论 Salesforce 中传统部署方式的实现。我们将学习 Salesforce 中的部署方法，并讨论为什么部署过程中需要自动化，以及如何使用 Ant 脚本实现 Salesforce 部署的自动化。

参考文献

5 分钟掌握 Maven: maven.apache.org/guides/getting-started/maven-in-five-minutes.html

第三章：在 Salesforce 中的部署

在上一章中，我们讨论了在 Salesforce 应用程序部署中需要 DevOps，以及 DevOps 如何帮助大量开发人员在同一项目中协同工作。我们看到 DevOps 能够提供精简的交付，帮助我们使用开源工具跟踪应用程序问题。我们还看到了 Salesforce 与其他技术栈的不同之处。我们讲解了如何使用 Git 和 Jenkins 为 Java 开发栈设置 DevOps 的过程。

在本章中，我们将讨论如何以过渡的方式将 Salesforce 代码从一个沙盒部署到另一个沙盒，或者从沙盒部署到生产环境。部署代码有多种方式，例如使用变更集或迁移工具。

在本章中，我们将学习以下主题：

在 DevOps 中，什么是部署？
从沙盒到沙盒以及沙盒组织的部署
使用变更集进行部署
使用迁移工具进行部署
使用 Force.com IDE 进行部署
使用 Salesforce DX 插件的 Visual Studio Code 进行部署
使用第三方工具（利用元数据 API 或工具 API）进行部署

让我们首先来看看 Salesforce 中的部署。

在 DevOps 中，什么是部署？

成功地将代码更改部署到生产环境涉及许多任务，例如单元测试、集成测试、配置更改、避免停机、备份现有环境以防止部署失败导致的数据丢失、提供回滚更改的快速恢复方式等。在 DevOps 中，借助众多部署、配置管理、备份和恢复工具，可以轻松执行快速、零停机时间的部署。

在 DevOps 中，持续部署是将每个更改从开发环境部署到生产环境的过程，在此过程中，每个更改都会经过持续集成管道，并且自动进行测试。这个过程使我们能够更快速地将新特性和 bug 修复交付到生产环境中。

由于每个更改都经过 DevOps 管道处理，一切都被跟踪。例如，假设我们想要将 Java 应用程序代码从开发环境部署到生产环境，正如我们在第二章《将 DevOps 应用于 Salesforce 应用程序》中看到的那样。开发人员所做的代码更改将推送到 Git（一个版本控制系统），这会自动触发 Jenkins 作业来构建 JAR 文件并将其部署到测试环境。我们可以继续为构建作业添加持续测试阶段，在这个阶段运行测试用例，根据测试结果，构建将被推送到下一个环境阶段，然后进入生产环境。

Salesforce 中的部署过程与其他堆栈的部署过程不同。我们将讨论 Salesforce 中有哪些类型的部署以及它们之间的区别，并举一些示例场景。我们还将了解在 Salesforce 中有多少种方式可以部署项目，并探讨哪种方法最佳。

Salesforce 中的部署

有很多不同的方法可以在生产环境中部署 Salesforce。Salesforce 部署仅仅是将 Salesforce 元数据迁移到生产环境。

有三种方法可以将元数据迁移到生产环境：

从沙箱到生产组织
从一个生产组织到另一个生产组织
从开发者组织到生产组织

有多种方法可以实现 Salesforce 元数据的部署：

变更集
Ant 迁移工具
Force.com IDE
使用元数据 API 或工具 API 的第三方工具
SOAP API
配有 Salesforce DX 插件的 Visual Studio Code

变更集

使用变更集时，必须将沙箱连接到生产组织。在前一章中，我们讨论了如何创建沙箱并建立沙箱与生产组织之间的连接。这是将配置和元数据变更从一个沙箱发送到另一个沙箱或从沙箱发送到生产组织的传统且最简单的方法。

变更集有两种不同类型。前往设置并使用变更集关键词搜索。

变更集有两种类型：传入变更集和外发变更集：

外发变更集：外发变更集需要在源沙箱中创建。通常，我们会在沙箱中创建外发变更集，并将其部署到生产组织。我们可以选择将变更从沙箱迁移到生产组织，从生产组织迁移到沙箱，或者从沙箱迁移到沙箱。你需要在源沙箱中进行更改，并将这些更改上传到目标沙箱或生产组织。
传入变更集：传入变更集一旦外发沙箱成功上传后，便会自动在目标沙箱或生产组织中显示。

部署连接

在沙箱或其他组织中创建变更集之前，我们需要在组织中授权部署连接。前往设置并使用部署关键词搜索：

设置页面

使用变更集进行部署

使用变更集部署有四个步骤，分别如下：

创建部署连接
创建外发变更集
验证传入变更集
使用快速部署来部署变更集

我们将在接下来的章节中讨论这些步骤。

创建部署连接

首先，前往设置并使用部署关键词搜索：

选择部署设置：

选择部署设置

在这里，我们可以找到沙箱列表及其连接状态。

有三种不同类型的符号：

绿色的右箭头
绿色的左右箭头
红色的破损箭头

选择编辑以修改入站更改：

修改入站更改

有一个复选框名为“允许入站更改”。这是为连接的组织设置的，允许该组织向我们的组织部署更改集。我们需要勾选此复选框以建立连接：

允许入站更改

有一个名为“接受出站更改”的复选框。这个字段是只读的——你不能在这里编辑此字段。如果连接的组织选中了“允许入站更改”复选框，系统会自动选择此选项：

允许出站更改

现在点击“保存”按钮以创建连接：

创建出站更改集

前往设置并使用outbound关键词进行搜索：

使用出站关键词进行搜索

出站更改集包含你想要从此组织发送到另一个组织的定制。这些定制可能包括新的组件或现有组件的修改，例如应用程序、对象、报告或 Apex 类和触发器。出站更改集不能用于删除或重命名另一个组织中的组件。

若要创建新的出站更改集，点击“新建”按钮。

输入更改集的名称，这是必填项，并填写其描述：

创建出站更改集

点击“保存”按钮以创建出站更改集。

更改集包含应用程序、对象、报告和电子邮件模板等组件的定制。你可以使用更改集将定制从一个组织迁移到另一个组织。

上传更改集后，其组件不会自动刷新，且不能添加或移除组件。要刷新组件源并修改组件列表，需克隆更改集。

点击“添加”将 Salesforce 组件加入到你的更改集中：

添加 Salesforce 组件

你将看到所有 Salesforce 组件的列表，可以选择你想要添加的组件及其类型：

选择需要迁移到生产组织的组件：

点击“添加到更改集”。

如果误添加了组件，我们可以将其移除。方法是点击“移除”链接：

移除组件

现在点击“上传”按钮上传更改集：

更改集选项

一旦上传此变更集，您将无法编辑或从目标组织中撤回它：

上传确认消息

选择您要将变更集发送到的组织，然后点击“上传”。您将看到一条确认消息，如以下截图所示：

验证传入的变更集

进入设置并使用 inbound 关键字进行搜索：

使用 inbound 关键字进行搜索

然后选择“传入变更集”，点击一个变更集名称查看其详细信息：

有三个选项：“验证”、“部署”和“删除”。点击“验证”以验证变更集，而不部署更改。

有四个选项用于验证变更集：

默认
运行本地测试
运行所有测试
运行指定的测试

这些选项显示在下面的截图中：

Salesforce 推荐您选择“运行指定的测试”选项。在以下屏幕中，我们需要添加特定的测试类：

点击“验证”以验证生产组织中的变更集：

在确认提示中点击“确定”：

使用快速部署来部署变更集

要跟踪验证进度，请点击“部署状态”：

我们可以看到组件列表和 Apex 测试类列表：

现在，变更集已启用快速部署验证过的变更集，跳过 Apex 测试作为部署的一部分：

快速部署选项

现在点击“快速部署”将变更集部署到生产组织中。

使用 Ant 迁移工具进行部署

Ant 迁移工具提供了一种从本地目录将元数据部署到 Salesforce 沙盒的方法。我们可以使用 Ant 命令行工具来自动化 Salesforce 中的部署任务。

Ant 迁移工具帮助我们从沙盒中检索并部署元数据。

此工具也可以用来备份您的沙盒元数据。要配置沙盒的访问权限，我们需要在 build.properties 文件中提供沙盒凭证。build.xml 文件包含检索或部署元数据的命令。Package.xml 包含要检索或部署的组件。

Ant 迁移工具通过第四章中的示例进行了详细解释，Force.com 迁移工具介绍。

我们将讨论一些可以使用 Ant 迁移工具部署类型的场景：

部署可能涉及许多设置更改，但使用 Web 界面进行这些更改是一项困难且耗时的工作。可以使用 Ant 迁移工具自动化设置更改的过程。
拥有多个环境时，需要重复部署到开发、测试和预发布环境，才能将任何更改部署到生产环境。自动化组件的获取和部署将有助于加速该过程。
我们可以设置自动备份，使其在午夜时分发生，复制沙盒的元数据并在需要时进行恢复。

使用 Force.com IDE 部署 Apex

Force.com IDE 是 Eclipse IDE 的一个插件。Force.com IDE 提供了一个统一的界面，用于构建和部署 Salesforce 应用程序。该 IDE 旨在为开发人员和开发团队提供加速 Salesforce 应用程序开发的工具，包括源代码编辑器、测试执行工具、向导和集成帮助。该工具包括基本的颜色编码、大纲视图、集成单元测试和在保存时自动编译并显示错误消息的功能。

Force.com IDE 是 Salesforce 提供的免费资源，旨在支持其用户和合作伙伴，但不被视为 Salesforce 主订阅协议中的一部分。

要将 Apex 从本地项目部署到 Salesforce 组织，可以使用“部署到服务器”向导。

如果你正在部署到生产组织，至少 75% 的 Apex 代码必须由单元测试覆盖，并且所有这些测试必须成功完成。

请注意以下几点：

在将组件部署到生产组织时，组织中的所有测试类默认都会执行
每个触发器中应该至少有 1% 的测试覆盖率
所有组件应成功编译
测试类和测试方法不计入 Apex 代码覆盖率
代码的某些部分不计入 Apex 代码覆盖率，例如调试、注释和空格不包括在内

要使用 Force.com IDE，必须首先安装 Eclipse。安装完 Eclipse 后，按照以下步骤安装 Force.com IDE：

打开 Eclipse：

现在输入工作区路径并点击确定：

现在选择“帮助”，点击“安装新软件”：

要添加新软件，请点击“添加...”按钮。
在“添加仓库”对话框中，输入名称为 Force.com，并将位置输入为 https://developer.salesforce.com/media/force-ide/eclipse45：

我们将获得与 Force.com IDE 相关的所有内容的列表：

可用软件列表

我们需要选择 Force.com IDE。我们还可以添加其他软件，如 Force.com 调试器和 Force.com Lightning 支持：

点击下一步继续。如果有任何问题，我们可以取消安装：

安装所需的软件

选择保持我的安装不变并修改安装的项目以兼容单选按钮。要继续，点击下一步。如果出现任何问题，我们可以取消安装：

在审查许可中，接受条款并点击完成：

点击确认继续。现在，Eclipse 成功安装了 Force.com IDE 和所需的依赖项。安装完成后，系统会提示重启。点击立即重启。此时只有 Eclipse 会重启，而不是你的电脑：

等待 Eclipse 重启。现在选择窗口选项卡，在打开透视图选项卡中，选择其他。
选择 Force.com 并点击确定。

按照这些步骤从 Force IDE 部署代码：

首先，我们需要打开项目。然后右键点击项目，会显示很多选项。选择 Force.com 并点击项目属性：

在这里我们需要通过使用凭证创建与组织的连接。填写所有详细信息；即用户名、密码和安全令牌。

选择环境为生产/开发者版本：

点击应用并关闭按钮：

再次右击项目。我们会看到很多选项；选择 Force.com 并点击部署到服务器...：

在这里我们需要添加凭证。填写所有详细信息（在用户名、密码和安全令牌字段中）：

点击下一步按钮。将出现一个窗口，显示元数据组件的列表：

通过相关的复选框选择要部署的组件：

要验证组件，请点击验证部署。我们必须在实际部署之前验证所有组件：

一旦验证成功完成，点击下一步。所有选中的组件将被部署到 Salesforce 组织中。

将 Salesforce DX 插件安装到 Visual Studio Code 中

执行以下步骤以设置 Visual Studio Code：

从 code.visualstudio.com/download 下载并安装最新版本的 Visual Studio Code。
安装完成后，打开 Visual Studio Code，在左侧工具栏中点击扩展图标。搜索 Salesforce Extensions for VS Code：

搜索结果中显示 Salesforce Extensions for VS Code

点击相关的安装按钮以安装扩展包：

安装所需的扩展

安装完成后，点击重新加载按钮：

总结

在本章中，我们学习了如何将 Salesforce 代码从一个沙箱部署到另一个沙箱，从沙箱部署到生产环境，以及从一个组织部署到另一个组织。我们了解了不同类型的代码部署。我们还学习了如何根据项目类型使用它们。我们学习了如何使用变更集（Change Sets）和 Force.com IDE 将代码迁移到生产环境，特别是在需要持续将代码迁移到生产环境的项目中，比如正在进行的项目。

在敏捷方法论中，我们主要使用 Ant 迁移工具（Ant Migration Tool），该工具使得代码能够在特定时间间隔或迭代中迁移。在下一章中，我们将更深入地讨论 Ant 迁移工具。

第四章：Force.com 迁移工具简介

在上一章，我们介绍了传统的 Salesforce 部署方式。我们学习了变更集部署、Salesforce 中的入站和出站变更，如何使用 Eclipse 将代码部署到沙盒，以及 Ant 脚本的使用。同时，我们还比较了 Salesforce 中的不同部署方法，分析了它们的优缺点，并学习了如何根据使用场景选择合适的部署方法。

本章中，我们将详细研究 Force.com 迁移工具。我们将了解如何安装和设置 Force.com 迁移工具。此外，我们将看到如何使用迁移工具从 Salesforce 沙盒中提取元数据组件，并将它们部署到另一个沙盒中。同时，我们还将解释一些重要操作，如部署代码和撤销部署代码。我们将讨论涉及沙盒操作的配置文件。

我们将解释从沙盒中提取元数据并构建项目清单的完整过程。我们将学习如何在 Force.com 迁移工具中配置沙盒凭证，以执行诸如部署或删除沙盒中的元数据文件等操作。

本章中，我们将学习以下主题：

什么是 Force.com 迁移工具？
如何设置 Force.com 迁移工具
Force.com 工具如何帮助开发人员和 DevOps
使用迁移工具从沙盒中提取元数据
在沙盒上部署元数据
使用destructiveChanges.xml从 Salesforce 组织中删除文件/组件
故障排除

什么是 Force.com 迁移工具？

Force.com 迁移工具提供了一种脚本化的方式，用于将元数据部署到 Salesforce 沙盒中，或从沙盒中提取元数据。它基于 Ant/Java。

Force.com 迁移工具帮助我们轻松地将 Salesforce 组件从一个组织复制到另一个组织。在实际操作中，我们通常有多个不同的环境，如开发、测试、UAT 和生产环境。开发人员在开发者沙盒中开发组件时，需要将这些更改移至测试或 UAT 环境，让测试人员进行测试并为功能/更改在生产环境中的发布提供批准。然而，这并不是一次性的过程。许多时候，功能或更改不能正常工作，或引入了一些 bug，测试人员会提出问题或 bug，开发人员会开始修复。一旦在开发环境中修复了 bug/问题，我们还需要将这些更改再次部署到测试/UAT 环境中。因此，由于多种原因，这成为了一个重复的过程。每次使用变更集进行部署并不是一个方便的选择，因此我们需要一个快速、简便且少出错的解决方案来执行此任务。

Ant 迁移工具提供了解决我们刚才讨论的所有问题的方案。Ant 迁移工具易于设置和使用。完成设置后，只需进行少量更改即可重复使用。Ant 迁移任务可以编写脚本，因此我们可以轻松地自动化大多数日常任务。Force.com 迁移工具是 Salesforce 支持的工具；我们无需过多担心它与应用程序的兼容性和安全性。

设置 Force.com 迁移工具

要设置 Force.com 迁移工具，需要安装以下部分提到的前提条件。我们可以在 Windows、Mac 或 Linux 操作系统上设置迁移工具。以下是设置 Linux 机器上 Force.com 迁移工具的步骤。

前提条件

设置的前提条件如下：

Java 1.7.x 或更高版本
Ant 工具

让我们在系统上安装这些工具。

Java

推荐使用 Java 版本 1.7.x 或更高版本以确保更好的安全性。使用命令行检查系统上是否已安装 Java，如下所示：

打开终端。
输入java -version并按Enter键。

你将看到以下输出：

java version "1.7.0_21" 
Java(TM) SE Runtime Environment (build 1.7.0_21-b11) 
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

如果系统上未安装 Java，请使用以下说明安装 Java：

访问www.oracle.com/technetwork/java/javase/downloads/index.html。
下载最新版本的 Java JDK 并安装 JDK。
在命令提示符下输入java -version进行验证。

Ant

要检查已安装的 Ant 版本，你需要执行以下步骤：

打开终端。
运行ant -version命令以验证系统上是否已安装 Ant。

输出将如下所示：

ant -version 
Apache Ant(TM) version 1.10.1 compiled on February 2 2017

如果系统上未安装 Ant，可以使用以下步骤安装 Ant：

推荐的 Ant 版本是 1.5.x 或更高版本；你需要下载最新版本的 Ant。

从ant.apache.org/bindownload.cgi下载 Apache Ant。你需要下载一个版本高于 1.6 的 Ant 到ANT_HOME。请注意，在我们的案例中，它是/usr/local/：

$wget http://www-eu.apache.org/dist//ant/binaries/apache-ant-
1.9.13-bin.tar.gz

解压 Apache Ant 到ANT_HOME：

$unzip apache-ant-1.9.13-bin.tar.gz

将bin目录添加到你的路径中。
将 Ant 的二进制路径添加到.bashrc文件中，如下所示：

export JAVA_HOME=/usr/lib/jvm/java-1.8.0 
export PATH=$PATH:$JAVA_HOME/bin 
export ANT_HOME=/usr/local/apache-ant-1.9.13 
export PATH=$PATH:$ANT_HOME/bin

更多信息，请参见ant.apache.org/manual/install.html。

在 Linux 上安装 Ant 迁移工具

安装步骤如下：

从developer.salesforce.com/page/Force.com_Migration_Tool下载 Force.com 迁移工具：

#wget https://gs0.Salesforce.com/dwnld/
SfdcAnt/Salesforce_ant_39.0.zip

将.zip文件保存在本地并将内容解压到你选择的目录：

#unzip Salesforce_ant_39.0.zip

请注意，在我们的案例中，它是/home/devops/Force_com_tool。

解压Salesforce_ant_39.0.zip后，你会找到ant-Salesforce.jar文件；这是运行 Ant 任务所必需的。将Salesforce_ant_39.0.zip复制到另一个名为Sample的文件夹中，里面有用于从沙箱中部署和检索元数据的示例，包括codepkgclasses、removecodepkg。此外，Sample文件夹中还包含一个build.properties文件，我们在其中提供访问 Salesforce 沙箱的凭证。Build.xml文件中列出了 Ant 任务，这些任务使用build.properties中的凭证。

在 Windows 上安装 Ant 迁移工具

要在 Windows 机器上使用 Ant 迁移工具，我们需要在机器上安装 Java 和 Ant。安装 Java 和 Ant 的步骤已在前面的部分中提到。

以下步骤需要在 Windows 上设置ANT_HOME环境变量：

在搜索框中输入environment：

选择编辑系统环境变量。在“高级”选项卡下，选择“环境变量”：

在系统环境变量下，创建一个新的ANT_HOME环境变量。将ANT_HOME的值设置为 Ant 二进制路径：

创建一个新的环境变量，名称为ANT_OPTS，值为-Xms256M：

编辑Path环境变量，并按以下截图所示添加ANT_HOME路径。点击“确定”，然后再次点击“确定”保存环境变量：

打开命令提示符，使用ant -version命令检查 Ant 版本。你将看到如下输出：

Apache Ant(TM) version 1.10.5 compiled on July 10 2018

安装 Salesforce Ant 迁移工具

安装步骤如下：

从developer.salesforce.com/docs/atlas.en-us.daas.meta/daas/forcemigrationtool_install.htm下载 Ant 迁移工具的 ZIP 文件
将 ZIP 文件保存到你喜欢的任何目录。在本例中，我们将使用C:\Demo路径下的Demo文件夹。
将Salesforce_ant_43.0.zip解压到C:\Demo\Salesforce_ant_43.0。ZIP 文件的内容已在在 Linux 上安装 Ant 迁移工具部分中说明。

从沙箱中检索元数据

要开始从沙箱中检索元数据，我们需要配置build.xml、package.xml和build.properties文件。build.properties文件用于指定 Salesforce 凭证，以在你的计算机和 Salesforce 沙箱之间建立连接。build.xml文件包含在沙箱中需要执行的 Ant 任务。package.xml是项目清单文件，包含需要检索或部署的包。

我们将通过常规流程，使用 Ant 迁移工具从 Salesforce 组织中检索元数据到本地计算机：

前往提取 Force.com 迁移工具.zip文件的文件夹。你需要使用任何编辑器编辑build.properties文件。
在此案例中，我们将使用 vim 编辑器。运行以下命令：

$vim build.properties

让我们看一下示例build.properties文件：

build.properties 
sf.username = devopsxxx@Salesforce.com.dev 
sf.password = mypassxxxxxxxxxxxxxxxxxxxxxxxxx 
sf.token = <Security Token Generated> 
#sf.sessionId = <Insert your Salesforce session id here. Use this or username/password above. Cannot use both> 
#sf.pkgName = <Insert comma separated package names to be retrieved> 
#sf.zipFile = <Insert path of the zipfile to be retrieved> 
#sf.metadataType = <Insert metadata type name for which listMetadata or bulkRetrieve operations are to be performed> 
# Use 'https://login.Salesforce.com' for production or developer edition (the default if not specified). 
# Use 'https://test.Salesforce.com for sandbox. 
sf.serverurl = https://test.Salesforce.com <ForSandbox>
sf.maxPoll = 20 
# If your network requires an HTTP proxy, see http://ant.apache.org/manual/proxy.html for configuration. 
Load properties from file

添加所需的登录凭证以连接到目标 Salesforce 组织，例如以下内容：

Sf.username：此字段指定你的 Salesforce 沙盒/生产环境的用户名。提供的用户名应该具有修改所有数据的权限。如果你连接的是沙盒实例，则需要在用户名后面附加沙盒名称。
例如，你可以按需指定用户名，但使用有意义的名称是一种良好的做法，它将帮助我们识别沙盒。如果你的用户名是xxx@Salesforce.com，并且你想连接沙盒dev，那么sf.username的值可以是xxx@Salesforce.com.dev。
Sf.password：此字段指定 Salesforce 用户名的密码。你需要将 Salesforce 安全令牌附加到密码后。安全令牌是一个 25 位的区分大小写的代码，用于 API 登录身份验证。当你使用 API 登录时，必须提供安全令牌。
例如，如果你的密码是mypass，安全令牌是xxxxxxxxxxxxxxxxxxxxxxxxx，那么sf.password字段的值应为mypassxxxxxxxxxxxxxxxxxxxxxxxxx。
如果你没有安全令牌，你可以重置它。重置安全令牌的步骤如下：

登录到你的组织，并导航到顶部导航栏。前往<你的名字> | 我的设置 | 个人设置 | 重置我的安全令牌：

- 1. 点击“重置安全令牌”。这将使你现有的令牌失效。
  2. 你将通过你的用户邮箱获取安全令牌。出于安全原因，安全令牌在重置设置中不会显示。

注意：如果你在登录时仍然遇到问题，你需要检查是否设置了登录 IP 范围，例如从 53.14.120.10 到 53.14.120.255。如果你不在相同的 IP 范围内，你需要删除登录 IP 范围。

Sf.serverurl：此字段指定 Salesforce 的服务器 URL。如果你想连接到生产组织或开发者版本组织，则该字段的值为https://login.Salesforce.com。如果你想使用沙盒环境，则字段的值为https://test.Salesforce.com。如果你使用自定义域名，可以将值设置为https://custom-domain.my.salesforce.com。

现在我们需要列出所有要从沙盒中检索的组件。
package.xml文件是一个项目清单文件，我们在其中列出了所有要检索或部署的组件。在我们的package.xml文件中，我们列出了项目中的所有 Apex 类组件。如果你想备份你的沙盒元数据，可以在package.xml中列出所有组件。例如，package.xml仅包含 Apex 类：

<?xml version="1.0" encoding="UTF-8"?> 
<Package > 
    <types> 
    <members>*</members> 
    <name>ApexClass</name> 
    </types> 
    <version>36.0</version> 
</Package>

下一个需要配置的文件是build.xml。该文件指定了一个目标来检索和部署元数据。Ant 任务在build.xml文件中提到。配置步骤如下：
1. 转到build.xml所在的目录
2. 运行ant命令，验证你是否正确安装了 Apache Ant。
3. build.xml文件加载build.properties文件以获取沙箱的访问权限。
4. 要从沙箱中检索元数据，可以为每个<sf:retrieve>目标设置用户参数。
5. 由于我们的检索目标是DevOps/src，所有的元数据将存储在这个目录中。
例如，查看以下build.xml文件：

<project name="Force.com Migration Tool" default="retrieveUnpackaged" basedir="." > 
<taskdef uri="antlib:com.Salesforce" 
        resource="com/Salesforce/antlib.xml" 
        classpath="lib/ant-Salesforce.jar" 
    /> 
    <!-- Load properties from file --> 
    <property file="build.properties"/> 
    <!-- Load properites from environment --> 
    <!-- These will override properties from the file --> 
        <property environment="env"/> 
        <property name="sf.username" value="${env.SF_USERNAME}"/> 
        <property name="sf.password" value="${env.SF_PASSWORD}"/> 
        <property name="sf.token" value="${env.SF_TOKEN}"/> 
        <property name="sf.serverurl" value="${env.SF_SERVERURL}"/> 

        <!-- Retrieve an unpackaged set of metadata from your org --> 
        <!-- The attribute 'unpackaged' is where metadata will be stored --> 
        <target name="retrieveUnpackaged"> 
        <!-- Retrieve the contents into another directory --> 
                <sf:retrieve 
                        username="${sf.username}" 
                        password="${sf.password}${sf.token}" 
                        serverurl="${sf.serverurl}" 
                        retrieveTarget="DevOps/src" 
                        unpackaged="${basedir}/package.xml" 
                /> 
        </target> 
    <!-- Retrieve the information on all supported metadata types --> 
</project>

使用ant命令检索元数据。运行以下命令以检索 Apex 类元数据，即DevOps/src中的检索目标：

$ ant -file build.xml

控制台日志如下所示：

如果构建成功，它将显示BUILD SUCCESSFUL消息。

在沙箱中部署元数据。

在前面的示例中，我们展示了如何从沙箱中检索元数据并部署到本地环境。我们可以使用 Eclipse 编辑代码并进行修改，或者添加新功能代码。开发者可以使用 Force.com 迁移插件将元数据与 Eclipse 中的工作区同步。修改代码后，开发者可以将更改部署到测试/UAT 沙箱。我们可以使用 Force.com 迁移工具将更改部署到沙箱。

我们将通过常见的程序，使用 Ant 迁移工具从本地机器将元数据部署到 Salesforce 组织。为了提供沙箱访问权限，我们需要在build.properties文件中添加沙箱凭证，就像我们在步骤 3中，在从沙箱检索元数据部分所提供的凭证一样。Sf.serverurl字段的值将取决于你希望部署更改的位置。如果你想部署到测试、UAT 沙箱，或任何其他开发沙箱，那么它的值将是https://test.Salesforce.com。如果你正在将更改部署到生产环境，则使用https://login.Salesforce.com。但在所有测试用例成功通过之前，我们不应直接将更改部署到生产环境；这样做可能会导致现有功能失败并破坏应用程序。

完成build.properties文件的更改后，我们需要将所有要部署到沙箱的组件添加到package.xml中：

<project name="Force.com Migration Tool" default="retrieveUnpackaged" basedir="." > 
<taskdef uri="antlib:com.Salesforce" 
        resource="com/Salesforce/antlib.xml" 
        classpath="lib/ant-Salesforce.jar" 
    /> 
        <property environment="env"/> 
        <property name="sf.username" value="${env.SF_USERNAME}"/> 
        <property name="sf.password" value="${env.SF_PASSWORD}"/> 
        <property name="sf.token" value="${env.SF_TOKEN}"/> 
        <property name="sf.serverurl" value="${env.SF_SERVERURL}"/> 

                      <sf:deploy 
                        username="${sf.username}" 
                        password="${sf.password}${sf.token}" 
                        serverurl="${sf.serverurl}" 
                        deployRoot="DevOps/src" 
                        maxPoll="1000"  
                                                  testLevel="NoTestRun" 
                                                  pollWaitMillis="10000"  
                                                  rollbackOnError="true" 
                /> 
        </target> 
    </project>

在前面的文件中，有一些新的参数，例如以下内容：

deployRoot：这是一个必填参数。所有要部署的文件都将存放在这个目录中。
maxPoll：这是一个可选参数。该参数定义了轮询服务器以获取部署请求结果的次数。其默认值为 200。
testLevel: 这是一个可选参数，指定在特定沙盒上进行部署时要运行的测试。此参数的值可以根据沙盒类型和部署位置而异。对于开发沙盒，默认设置为 NoTestRun，不会运行任何测试。您可以指定其他选项，选择要运行的测试用例或在组织上运行所有测试，我们将在第七章“持续测试”中详细介绍。
pollWaitMillis: 这是一个可选参数，用于定义在等待部署结果时轮询的毫秒数。此参数的默认值为 10,000，因此我们可以相应地设置它。

使用 `destructiveChanges.xml` 从 Salesforce 组织中删除文件/组件

我们已经看到可以从沙盒检索元数据，并可以使用 Ant 迁移工具将更改部署到沙盒。但有时我们不需要某些功能，希望从 Salesforce 组织中删除某些组件或文件，如对象、字段等。我们需要创建一个与 package.xml 文件一起的额外文件，即 destructiveChanges.xml。删除清单的格式与 package.xml 相同，只是不接受通配符字符。

删除组件与使用删除清单文件部署组件的过程相同。我们需要在 destructiveChanges.xml 中添加要删除的组件列表。删除自定义对象的示例文件如下：

<?xml version="1.0" encoding="UTF-8"?> 
    <Package http://soap.sforce.com/2006/04/metadata">http://soap.sforce.com/2006/04/metadata"> 
    <types> 
        <members>MyTestObject__c</members> 
        <name>CustomObject</name> 
    </types> 
</Package>

要部署破坏性更改，我们需要 package.xml 文件，其中仅包含 API 版本。它不应包含任何组件列表。destructiveChanges.xml 和 package.xml 文件应位于同一目录中。

Force.com 工具如何帮助开发人员和 DevOps

Force.com 迁移工具为开发人员提供了一种轻松执行其沙盒上操作（如检索、部署和删除元数据）的方式。使用 Force.com 迁移工具，开发人员可以将代码部署到不同的沙盒，并在 Eclipse 上的工作空间之间切换。迁移工具易于在开发人员的机器上设置，并提供了与 Salesforce 组织安全通信的方式。

如果部署过程中出现问题，我们可能会遇到一些问题；在这种情况下，自动化的每日备份非常重要。Force.com 迁移工具提供了通过命令行从 Salesforce 沙盒中检索代码和配置的方式，因此 DevOps 或管理员可以自动化执行备份任务，备份 Salesforce 组织的代码和配置。此外，我们还可以利用开源的持续集成工具，如 Jenkins，来自动化备份 Salesforce 组织并将其保存到 Git 中的过程。在第六章，持续集成中，我们将逐步介绍如何使用 Jenkins 自动化 Salesforce 组织备份过程。

故障排除

在本节中，我们将查看一些故障排除的场景：

连接问题：在检索或部署元数据时，我们最常遇到的问题是连接问题。在检索或部署元数据时，我们使用的是异步请求类型，因此不会立即收到响应。部署操作调用是异步的，有时在部署过程中，Ant 迁移工具会因超时而失败。如果 Ant 迁移工具因超时而失败并且部署中存在错误，我们将无法看到错误日志。在这种情况下，我们需要配置pollWaitMillis和maxPoll参数。
无效的凭证或用户被锁定：如果你看到这个错误，说明你的build.properties文件存在问题。你需要验证用户名、密码、安全令牌和服务器 URL 是否正确。如果你有多次登录失败的尝试，可能会导致你的用户被锁定。因此，允许的失败尝试次数取决于你所在组织的设置。有时，验证代理设置也有助于解决凭证问题。
测试用例失败：如果你正在将变更部署到生产环境，根据 Salesforce 标准，你需要确保 75% 的代码被测试用例覆盖，并且所有测试用例都需要通过，才能成功将代码部署到生产环境。

摘要

在本章中，我们了解了 Force.com 迁移工具以及如何在你的环境中设置该工具。我们已经查看了使用 Ant 脚本从沙盒中检索元数据的逐步过程，学习了如何在build.properties中配置沙盒凭证以提供沙盒环境的访问权限，列出在package.xml项目清单中要检索的组件，并将内容检索到build.xml文件中提到的目录中。

在成功从沙箱将元数据检索到本地机器后，我们进入了下一步，即将更改部署到沙箱。我们已经看到了使用 Ant 迁移工具将元数据部署到开发者沙箱或测试沙箱的示例。有时，我们可能需要从沙箱中删除组件或文件。我们已经了解了如何使用destructiveChanges.xml从 Salesforce 组织中删除组件。

在下一章，我们将了解什么是源代码控制版本管理。我们还将学习使用 Git 的优点，Git 中的分支策略，以及如何为你的 Salesforce 项目设置一个 Git 仓库。我们还将介绍如何在使用 Eclipse 等代码编辑器时，进行 Git 的开发者流程。

第五章：版本控制

在上一章中，我们学习了 Force.com 迁移工具。我们逐步讲解了如何在 Windows 和 Linux 机器上设置 Force.com 或 Ant 迁移工具，研究了从沙箱中提取元数据所需的文件，以及如何提供凭据来访问沙箱。我们还了解了在沙箱上部署元数据的过程，并讨论了 Force.com 如何帮助开发者和 DevOps 日常工作。

在本章中，我们将学习源代码版本控制系统及其类型。我们将主要关注 Git 分布式版本控制，以及在 Git 仓库上执行的操作，如提交、推送、合并等。我们还将逐步讲解如何搭建自己的 GitLab 服务器、添加仓库、添加用户以及创建分支。我们将讨论 Git 分支策略及保护分支的相关内容。最后，我们将学习如何在 Salesforce 项目中使用 Git，以及如何将 Salesforce 元数据保存到 Git 中。

SCVS 是什么？

源代码版本控制系统（SCVS）顾名思义，它帮助管理源代码随时间的变化。有许多源代码版本控制系统可供选择，如 CVS、SVN、Git 等。版本控制维护每个文件变更的历史记录，并帮助开发者追踪应用程序中的变更。实施版本控制的主要原因是能够追踪应用程序中的变更，以及在出现问题时能够回滚。随着代码经历各种变化，版本控制帮助我们保持代码的可用版本，并且借助版本控制，我们还能维护不同的环境，如测试、预生产和生产环境。多个用户可以同时在同一应用程序源代码上进行工作。

版本控制有两种类型：集中式和分布式。在集中式版本控制中，有一个中央仓库，每个用户都获得自己的工作副本。如果有人提交更改到源代码控制系统，其他共同用户可以通过更新自己的工作副本来获取这些更改。Subversion 和 CVS 是集中式版本控制系统。

在分布式版本控制中，每个用户都拥有一个本地仓库和工作副本。用户所做的更改会在提交代码时保存到他们的本地仓库。其他用户可以在该用户将更改推送到远程仓库后获取这些更改。

Salesforce 中的版本控制

Salesforce 在沙箱中跟踪变更的审计能力有限。在生产环境中进行更改是有风险的，而且我们无法查看文件版本或跟踪沙箱中的变更。

如果没有版本控制，回滚 Salesforce 中的代码是一个非常困难的任务。

为什么 Salesforce 不提供自己的版本控制？Salesforce 最初是为用户设计的，目的是让用户能够在云端运行应用程序，而无需深入理解代码。我们可以通过简单的点击构建小型应用程序，因此 Salesforce 并没有关注版本控制。在 Salesforce 中，我们可以直接修改 Salesforce 组织，所以不需要在本地计算机上存储代码。

大多数在 Salesforce 工作的人认为，为 Salesforce 设置版本控制需要做很多工作，实际上只有在团队较大时才需要。要为 Salesforce 项目设置版本控制，开发人员和管理员需要学习如何使用版本控制系统，并且他们可能需要一些关于命令行指令的知识。但我们有许多 Git 的集成工具，不需要了解命令行指令，因为我们可以通过按钮或选项卡来操作。

正如我们在此提到的，Salesforce 不提供内置的版本控制功能，因此我们需要设置一个源代码版本控制系统。有很多版本控制系统，但最流行的版本控制系统是 Git。在接下来的部分中，我们将介绍 GitLab 的设置，并在 Salesforce 项目中使用 Git。

Git 介绍

Git 是由 Linus Torvalds 发明的常用版本控制系统。它是一种分布式版本控制，允许多个开发者同时在同一个项目上工作。

它有助于维护源代码的版本，以便在出现问题时，您可以随时恢复到工作版本的源代码。要使用 Git，您需要一个可以存储源代码并使其对所有参与者可用的代码仓库。

Git 使用 GitHub 作为 Git 仓库的托管服务，因此，首先，您需要一个 GitHub 账户，以便能够创建一个仓库来存储您的源代码。Git 仓库有两种类型：

公开仓库：您可以免费在 GitHub 上托管公开仓库。这些仓库对所有人开放，因此，如果您打算将重要的源代码保存到 GitHub，您不应该将它保存在公开仓库中。
私有仓库：这些仓库是受保护的，除非您授予他人访问权限，否则任何人都无法访问它们。私有仓库需要付费。

我们已经介绍了 GitHub，但现在我们将使用 GitLab。GitLab 是一个功能齐全的开源 Git 服务器，您可以将其安装在自己的服务器上。GitLab 是一个数据库后台的 Web 应用程序，提供社区版和企业版两种版本。

让我们进入下一个主题，即设置我们自己的 GitLab 服务器。

在 Linux 实例上设置 GitLab 服务器

为了设置服务器，推荐使用全包安装。我们将在 Ubuntu 16.04 服务器上安装 GitLab 社区版。您也可以在其他操作系统上安装 GitLab，例如 Ubuntu、Centos、Debian 等；您可以在这里找到详细列表：about.gitlab.com/installation/。全包安装是 GitLab 推荐的方法，因为设置过程简单，升级过程也非常顺利。

系统要求

GitLab 推荐使用以下配置的服务器：

2 核心
4 GB 内存

在安装 GitLab 社区版之前，安装所需的包：

$sudo apt-get update 
$sudo apt-get install ca-certificates curl openssh-server postfix

对于 Postfix 安装，当系统提示时，选择“Internet Site”。在下一个屏幕中，输入您的服务器的域名或 IP 地址来配置将发送邮件的系统：

让我们继续 GitLab 服务器的安装。

安装 GitLab 服务器

我们已安装 GitLab 服务器所需的所有依赖项。运行以下命令以安装 GitLab：

$curl -LO https://packages.gitlab.com/install/repositories
/gitlab/gitlab-ce/script.deb.sh
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current Dload  Upload   Total   Spent    Left  Speed
100  5933    0  5933    0     0  23796      0 --:--:-- --:--:-- --:--:-- 23827

您可以检查 script.deb.sh 并查看所有将要安装的包及其配置，因为您需要了解在服务器上安装了哪些内容。一旦您验证了 script.deb.sh，就可以继续安装的下一步：

$ sudo bash script.deb.sh 
Detected operating system as Ubuntu/xenial.
Checking for curl...
Detected curl...
Checking for gpg...
Detected gpg...
Running apt-get update... done.
Installing apt-transport-https... done.
Installing /etc/apt/sources.list.d/gitlab_gitlab-ce.list...done.
Importing packagecloud gpg key... done.
Running apt-get update... done.

仓库已设置完毕！您现在可以安装包了。

这个脚本将设置我们的服务器以使用 GitLab 维护的仓库。在完成此脚本之后，我们将使用 apt 安装实际的 GitLab 应用程序：

$sudo apt-get install gitlab-ce

这将安装系统所需的组件，GitLab 配置文件路径为 /etc/gitlab/gitlab.rb。您可以编辑配置文件并重新配置 GitLab 服务器：

$sudo gitlab-ctl reconfigure

安装完成后，访问您的 GitLab 外部 URL，并为 root 用户设置密码：

以 root 用户登录，您将看到 GitLab 的欢迎页面，如下图所示：

现在您已经成功设置了 GitLab，让我们开始使用它并创建您的第一个仓库。

在 GitLab 中创建您的第一个项目

登录到您的 GitLab 服务器，按照步骤创建您的第一个项目仓库：

选择“创建项目”以在 GitLab 服务器上创建项目。在项目中，我们将存储所有与应用程序相关的代码、配置和其他信息。
提供项目名称和描述。目前，我们将创建一个示例的 Hello World node 应用程序。我们的项目名称是 Sample。
接下来，设置您的项目的可见性级别；它可以是公开的、内部的或私有的。
公共仓库可以被任何人克隆；任何已登录的用户都可以克隆内部项目仓库。要克隆私有项目，用户需要明确的访问权限。
目前我们将保持公开，并勾选“初始化仓库并附加 README 以快速开始”。
点击“创建项目”：

克隆项目 URL：

如果你的计算机上已经安装了 Git 命令，运行以下命令将仓库克隆到本地计算机：

$git clone http://35.155.183.87/root/Sample.git
Cloning into 'Sample'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.

你会看到 Readme.md 文件已经在 Sample 项目中创建好了。你可以开始使用你的 Git 仓库了：

使用 Git 仓库

我们已经将 Sample 仓库克隆到本地计算机。现在我们将了解如何使用 Git 仓库：

创建一个 Node.js Hello World 应用程序，该应用程序将创建一个 HTTP 服务器，并在 8080 端口上响应所有请求，返回字符串 Hello World。下面是 Node.js 应用程序的示例代码：

var http = require("http"); 

http.createServer(function (request, response) { 

   // Send the HTTP header  
   // HTTP Status 200 OK 
   // Content Type is text/plain 
   response.writeHead(200, {'Content-Type': 'text/plain'}); 

   // Send response body as "Hello World" 
   response.end('Hello World\n'); 
}).listen(8080); 

// Print message 
console.log('Server running at http://127.0.0.1:8080/');

将代码保存在 **main.js** 中，并将此文件添加到我们的 Git 仓库中。
使用以下命令检查我们 Git 仓库中的未跟踪更改：

$git status 
On branch master 
Your branch is up to date with 'origin/master'. 
Untracked files: 
  (use "git add <file>..." to include in what will be committed) 
   main.js 
nothing added to commit but untracked files present (use "git add" to track)

默认情况下，GitLab 将 master 分支设置为我们的默认分支。新添加的 main.js 文件在远程仓库中不存在，它在本地 Git 中也没有被跟踪。
Git 工作目录中的每个文件都可以是跟踪、未跟踪 或忽略文件。已经提交或暂存过的文件是跟踪文件。没有暂存或提交的文件是未跟踪文件。你不想添加到仓库中的文件，例如包含凭据或机器生成的文件，会在 .gitignore 文件中提到。
一个 .gitignore 文件的示例，用于忽略所有 .log 扩展名的文件如下所示：

.gitignore 
# ignore all logs 
*.log

让我们将 main.js 文件添加到本地仓库中；首先需要将其索引。git add 命令会使用工作目录中的内容更新索引。这些更改将被暂存以备提交。你可以使用 * 或 -a 选项将所有更改添加到索引中：

$git add . 
$ git status 
On branch master 
Your branch is up to date with 'origin/master'. 
Changes to be committed: 
  (use "git reset HEAD <file>..." to unstage) 
          new file:   main.js

下一步是将暂存的更改提交到本地仓库：

$git commit -m "Add main.js file" 
[master 9d8892d] Add main.js file 
 1 file changed, 15 insertions(+) 
 create mode 100644 main.js

commit 命令用于提交本地仓库中的更改。其他开发人员将无法看到这些更改。提交更改时，重要的是使用 -m 选项提供提交信息。确保你的提交信息与代码中的更改相关，以便其他使用它的人能够理解你的更改。

如果你没有指定文件名，它将提交你在代码中所做的所有最近更改。

最后的步骤是将本地更改推送到远程仓库；推送操作是指将更改推送到远程仓库。在推送更改时，重要的是要提到更改的来源：

$ git push origin master 
Username for 'http://35.155.183.87': priyanka 
Password for 'http://priyanka@35.155.183.87':  
Counting objects: 3, done. 
Delta compression using up to 4 threads. 
Compressing objects: 100% (3/3), done. 
Writing objects: 100% (3/3), 547 bytes | 547.00 KiB/s, done. 
Total 3 (delta 0), reused 0 (delta 0) 
To http://35.155.183.87/priyanka/Sample.git 
   aad9bc9..9d8892d  master -> master

Git 会要求你提供凭据以验证用户身份，并将更改推送到托管在 GitLab 服务器上的远程仓库。现在，你将能够在 GitLab 的网页 URL 上查看这些更改。

它将是这样的：

查看提交历史

您可以通过命令行查看日志，切换到 Git 仓库并运行 git log 命令，如下所示，以查看最近的提交。此命令没有任何附加参数时，会按逆序显示仓库中的提交。命令输出还包含信息，如 SHA-1 校验和、提交消息、提交的日期和时间，以及作者的详细信息：

$git log 
commit 9d8892da192fffb93a9a8a58fdf700632dabee3c (HEAD -> master, origin/master, origin/HEAD) 
Author: Priyanka Dive <user@example.com> 
Date:   Mon Aug 27 00:56:39 2018 +0530 

    Add main.js file 

commit aad9bc971f4e69242e550f9e1771e23c1785b5e2 
Author: priyanka <user@example.com> 
Date:   Sun Aug 26 18:47:08 2018 +0000 

    Initial commit

您可以查看带有时间戳和用户详细信息的 Git 提交消息，如下所示：

向 GitLab 添加用户

添加用户的步骤如下：

使用管理员用户（root）登录 GitLab。
点击扳手图标（右上角）进入管理员区域：

您将看到三个按钮：新项目、新用户和新组。点击“New user”：

填写所需的信息——名称、用户名和电子邮件：

根据您所在组织的规则提供项目用户限制。同时，如果您希望用户能够创建组，请勾选“Can create group”以授予其创建组的权限。如果您希望用户的访问权限有限，则选择“Access level”为 Regular；如果用户需要管理员权限，则选择“Access level”为 Admin：

填写完所有必填信息后，点击“Create user”。这将创建用户并将密码重置链接发送到该用户的电子邮件。

故障排除

请考虑以下错误：

There was an error running gitlab-ctl reconfigure: 
execute[/opt/gitlab/embedded/bin/initdb -D /var/opt/gitlab/postgresql/data -E UTF8] (postgresql::enable line 80) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1' 
---- Begin output of /opt/gitlab/embedded/bin/initdb -D /var/opt/gitlab/postgresql/data -E UTF8 ---- 
STDOUT: The files belonging to this database system will be owned by user "gitlab-psql". 
This user must also own the server process. 
STDERR: initdb: invalid locale settings; check LANG and LC_* environment variables 
---- End output of /opt/gitlab/embedded/bin/initdb -D /var/opt/gitlab/postgresql/data -E UTF8 ---- 
Ran /opt/gitlab/embedded/bin/initdb -D /var/opt/gitlab/postgresql/data -E UTF8 returned 1

解决方案

这个问题可能是由于 Linux 系统中未设置 LANG 和 LC_* 变量导致的。在 omnibus 安装中，我们可以使用以下命令设置这些变量，并重新运行安装命令或重新配置 GitLab：

$export LC_ALL="en_US.UTF-8" 
$export LC_CTYPE="en_US.UTF-8"

分支策略

分支是 Git 提供的一个非常有用的功能。它有助于并行开发多个功能。分支可以用于定义特定环境的代码，例如 develop、test、stage 和 production。通常，Git 分支与环境的映射关系为：例如，将开发环境的代码存储在 develop Git 分支中；测试环境使用 test Git 分支，以此类推。对于生产环境，我们使用 master 分支，因为它是创建任何 Git 仓库时默认创建的第一个分支。

让我们看看如何使用网页 UI 创建分支：

登录 GitLab。
转到我们在“创建你的第一个 GitLab 项目”部分创建的仓库 Sample，：

如您在此截图中所见，我们只有一个分支，即 master，它是默认分支。
点击“Branch”，您将被重定向到一个页面，您可以在该页面查看此仓库的所有活跃分支。目前，我们有一个 master 分支：

点击新建分支，输入分支名称develop。我们将使用这个分支进行开发：

点击创建分支。就这样，你可以看到从主分支创建的新分支。现在你可以从开发分支或主分支创建另一个分支。由于开发分支是从主分支创建的，因此目前开发分支中的所有代码都与主分支相同：

现在，如果我们查看活动分支，我们可以在列表中看到两个分支。它们之间有所不同。主分支是默认分支和受保护分支，而新创建的开发分支不是受保护分支。只有被授权的用户才能在受保护的分支上进行修改，通常是高级开发人员或项目负责人。由于这个原因，我们可以避免多个开发人员同时在不同功能上进行工作的情况。

使用 Git CLI 处理分支

在 Git 克隆之后，默认情况下，你将获得仓库中设置的默认分支的代码。在我们的例子中，它是主分支。让我们通过以下命令检查我们克隆了哪个分支：

$git branch 
* master

分支名称前的星号表示当前分支。

让我们创建一个test分支：

$git branch test

这将创建一个名为test的新分支，在你的本地 Git 仓库中：

    $git branch
    * master
      test

现在你将在本地 Git 仓库中看到两个分支，git branch <BRANCH_NAME>命令将从当前分支创建一个新分支。因此，测试分支是从主分支创建的。

切换到新创建的test分支并将其push到remote仓库：

    $git checkout test
    Switched to branch 'test'

    $git push origin test
    Username for 'http://54.202.196.64': root
    Password for 'http://root@54.202.196.64': 
    Total 0 (delta 0), reused 0 (delta 0)
    remote: 
    remote: To create a merge request for test, visit:
    remote:   http://54.202.196.64/root/Sample/merge_requests/new?merge_request%5Bsource_branch%5D=test
    remote: 
    To http://54.202.196.64/root/Sample.git
     * [new branch]      test -> test

验证是否能在 GitLab 网页 UI 中看到测试分支：

将更改从开发分支合并到主分支

让我们来看一下如何将更改从开发分支合并到主分支：

你可以指定从 Git 仓库克隆哪个分支：

$git clone http://54.202.196.64/root/Sample.git -b develop
Cloning into 'Sample'...
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.

为了测试，我们将做一个小修改，比如将控制台日志消息从Hello World改为Hello Git。将更改添加到 Git 并将更改推送到远程开发分支：

$git add main.js
$git commit -m "Test merge request"
$git push origin develop
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 321 bytes | 321.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: 
remote: To create a merge request for develop, visit:
remote: http://54.202.196.64/root/Sample/merge_requests/new?merge_request%5Bsource_branch%5D=develop
remote: 
To http://54.202.196.64/root/Sample.git
44fd847..a93bd41  develop -> develop

如果你想创建合并请求，打开显示在remote的 URL。
将其分配给有权接受主分支合并请求的人：

在我们的例子中，分配给了管理员。填写所需的信息并点击提交合并请求。
管理员用户可以看到合并请求，经过开发人员验证更改后，如果没有合并冲突且所有之前的检查都成功通过，那么管理员将通过点击合并来接受合并请求。测试中的更改将被移动到主分支：

管理员可以修改提交信息，并在不需要时删除源分支。如果发生错误，管理员也可以还原更改：

在 Eclipse IDE 中使用 Git

步骤 1 至 3 已在第一章中解释，Salesforce 开发与交付流程：

Eclipse 安装
安装 Force.com IDE 插件
在 Eclipse 中配置 Force.com 项目

我们将在接下来的部分继续进行下一步操作。

配置 Git 并推送代码到 Git

现在我们需要配置 Git。

右键点击文件夹并选择“在此创建 Git 仓库...”以在新文件夹中创建仓库：

在这里，我们没有选择“Make it Bare”，点击确认：

你将看到下一个屏幕。点击确认：

右键点击文件夹，选择 TortoiseGit 并点击设置：

你将看到下一个屏幕。点击确认：

选择 Git 并输入名称和电子邮件：

你将看到下一个屏幕。选择 Git 并点击“远程”：

打开浏览器中的 Git 项目并选择该项目。
从项目中复制 HTTP URL：

在 URL 和 Push URL 中输入复制的 URL。选择标签字段中的全部，然后点击“添加新标签/保存”按钮：

点击是按钮：

你将看到此屏幕，点击确认：

在此屏幕中输入 Git 凭证：

点击确认：

完成过程后，点击关闭按钮：

最后，点击确认：

现在，你需要从 Git 仓库拉取文件，步骤如下：

右键点击相同的文件并选择 TortoiseGit，点击拉取...：

你会看到一个弹出窗口，如图所示。选择“...”以选择远程分支：

在这里，你可以看到所有远程分支的列表，选择特定的分支并点击确认：

安装完成后，点击关闭：

现在，连接已经创建，所有文件已从 Git 仓库复制到本地文件夹。
将你的文件添加到此文件夹：

右键单击相同的文件夹，选择 TortoiseGit 并点击 Add...：

选择所有文件并点击 OK：

一旦过程完成，点击 Commit...：

现在添加提交信息并点击 Commit & Push：

要查看所有远程分支，点击 ... 按钮：

这里你可以看到所有的分支，选择特定的分支：

现在点击 OK：

一旦过程完成，点击 Close：

现在所有文件都已移动到 Git 仓库。检查 Git 仓库：

检查所有文件是否已正确提交：

所有代码已成功提交到 Git 仓库。

总结

在本章节中，我们学习了版本控制系统。我们了解了 Salesforce 中的版本控制以及为什么我们需要像 Git 这样的版本控制系统。我们学习了如何使用 GitLab 官方推荐的方式——全套安装方法，在本地服务器上安装 GitLab。设置好自己的 GitLab 服务器后，我们学会了如何通过 Web UI 在 GitLab 中创建我们的第一个项目。我们使用 Git 命令（如 git clone、add、commit、push 等）操作 Git 仓库。

我们讨论了 Git 中的分支策略以及在一般场景中如何处理不同的分支。我们了解了受保护分支和默认分支等概念，还知道了如何从现有分支创建新分支，并将代码从一个分支合并到另一个分支。最后，我们学会了如何在 Eclipse 中使用 Git 进行 Salesforce 项目的开发。

在下一章节中，我们将进入下一阶段，即使用 Jenkins 服务器进行持续集成。我们将学习 Jenkins 如何帮助我们自动化日常任务，例如使用 Force.com 迁移工具和 Git 检索和部署元数据。

第六章：持续集成

在上一章中，我们了解了版本控制系统在项目中的重要性，以及如何在我们的 Salesforce 项目中实现版本控制。我们查看了如何设置自己的 GitLab 服务器，并将 Salesforce 组织中的元数据推送到 Git 仓库的说明。按照步骤在开发者机器上安装 Git 并与 Salesforce 沙盒同步后，开发人员将能够在 Git 仓库中进行并保存他们的更改。

在本章中，我们将学习如何通过 Git 集成与 Jenkins 自动备份和部署 Salesforce 元数据。我们将讨论 Jenkins，并查看如何在 Salesforce 中通过 Jenkins 和 Ant Migration Tool 实现持续集成。我们将查看如何配置 Ant Migration Tool 与 Jenkins 配合使用，以及如何配置 Jenkins 作业从沙盒中获取元数据。我们将提供逐步的说明，介绍如何使用 Jenkins 将更改部署到 UAT 或测试环境。

在本章中，我们将涵盖以下主题：

什么是 Jenkins？
安装 Jenkins
配置 Ant Migration Tool 与 Jenkins 配合使用
提供沙盒凭证给 Jenkins
配置 Jenkins 作业以从沙盒中获取元数据
配置 Jenkins 作业以在沙盒上部署元数据

什么是 Jenkins？

Jenkins 是一个用 Java 编写的持续集成服务器。Jenkins 是一个开源自动化服务器，你可以轻松地在你的机器上安装它。Jenkins 可以安装在 Windows、macOS 和 Linux 机器上。Jenkins 配置简单，并且有很多插件来支持持续集成和部署。如果你有使用容器的经验，可以使用 Docker 从注册表中获取 Docker 镜像来安装 Jenkins。

使用 Jenkins 的 CI

持续集成是指开发人员将他们的代码推送到共享的代码库，并通过定期构建进行测试，这样他们可以逐步发现代码中的问题。

有几种工具可以用于实现持续集成。

通过持续集成，你可以轻松地追溯代码出现问题的地方。如果你不遵循持续集成，那么在生产阶段发现代码错误将变得更加困难和昂贵。

以下是 CI 工具的列表：

Jenkins
TeamCity
Travis CI
Go CD
Bamboo

在本章中，我们将使用 Jenkins 实现持续集成。

Jenkins 是一个开源的跨平台 CI 工具。Jenkins 可以添加插件，这使得它非常灵活且易于集成。你可以通过 UI 或命令来配置 CI。

安装 Jenkins 服务器

让我们从 Windows 服务器上的 Jenkins 安装开始。Linux 服务器的安装过程已在第二章，将 DevOps 应用到 Salesforce 应用程序中介绍过。这里我们将介绍 Windows 机器上的 Jenkins 安装，以便 Windows 用户了解安装步骤。

以下是 Jenkins 服务器安装的硬件和软件要求。

硬件要求如下：

256 MB 的内存
1 GB 的硬盘空间

软件要求如下：

Java 8
一个网页浏览器：Jenkins 支持大多数流行的网页浏览器，如 Google Chrome、Mozilla Firefox、Microsoft Internet Explorer 以及最新版本的 Apple Safari。

访问以下网站下载最新的 Jenkins 服务器包适用于 Windows：mirrors.jenkins.io/windows/latest。你将获得最新版本的 Jenkins 包的 ZIP 文件。

下载完成后，解压 ZIP 文件并通过双击 jenkins.msi 文件启动安装。按照 Jenkins 安装向导完成 Jenkins 服务器安装。选择 Jenkins 服务器的安装路径并点击“下一步”：

在下一屏幕上，点击“安装”以继续安装：

Jenkins 安装完成后，你需要配置 Jenkins 服务器。如果是在本地机器上进行测试安装，请访问 http://<Server-IP-address>:8080。你也可以通过访问 http://localhost:8080 来访问 Jenkins 服务器。如果看到“请稍等，Jenkins 正在准备工作...”的信息，你需要等待一段时间：

要解锁 Jenkins 服务器，你需要提供默认的 Jenkins 密码，密码存储在以下位置：C:\Program Files (x86)\Jenkins\secrets\initialAdminPassword。对于 Linux 系统，路径会有所不同。

在下一屏幕上，我们可以选择要安装的插件。点击“选择要安装的插件”：

我们只选择 Ant 插件和 Git 插件，因为在基本配置完成后可以安装其他插件：

这是下一页：

插件安装完成后，在“创建第一个管理员用户”中提供用户名、密码、全名和电子邮件地址：

点击“保存并完成”以完成 Jenkins 配置。

配置 Ant 迁移工具与 Jenkins

为了与 Salesforce 通信，我们需要在 Jenkins 服务器上安装 Ant 迁移工具。我们已经在第四章，Force.com 迁移工具介绍中涵盖了 Ant 迁移工具的安装步骤。在 Jenkins 服务器上安装 Ant 迁移工具并在 Jenkins 中配置路径。一旦在 Jenkins 中安装了 Ant 插件，您将能在“添加构建步骤”下拉菜单中看到“调用 Ant”选项，它将运行 build.xml 并执行脚本中提到的任务：

当开发者触发 Jenkins 作业时，我们将选择调用 Ant 来检索 Salesforce 元数据。构建成功后，元数据将保存在目录中，并触发 Jenkins 作业将元数据从 Jenkins 推送到 GitLab 仓库。验证 GitLab 仓库中的元数据。

现在，我们将在 Jenkins 中设置全局凭据。

转到“管理 Jenkins”并选择“全局工具配置”。在您的机器上，可执行文件可能不同。转到 Git 部分并提供 Git 可执行文件的路径，如下图所示：

配置一个 Jenkins 作业以从沙盒检索元数据

我们已经在第五章，版本控制中创建了一个包含来自 Salesforce 生产组织的元数据的 Git 仓库。我们将使用相同的示例项目和 GitLab 仓库 Salesforce_demo，以及来自 Salesforce 沙盒的当前生产代码。操作步骤如下：

创建一个分支以从沙盒检索代码：

Branch : sandbox_to_git

将 Jenkins 作业命名为 Retrive_sandbox_to_git。由于我们正在处理一个 Ant 构建项目，选择“构建自由风格项目”。点击确定。自由风格项目类型用于创建一个可以使用任何构建系统的 Jenkins 项目：

配置作业。创建作业后，我们将进入作业配置页面。在“常规”选项卡中，提供项目名称和描述，如下所示：
- 项目名称：Retrive_sandbox_to_git。
- 描述：用于从沙盒检索元数据并推送到 Git 的作业。
- 源代码管理：保持为“无”，因为我们不需要在此作业中使用 SCM。
- 构建触发器：不要选择任何触发器。
- 构建环境：如果可用，选择“添加时间戳到控制台输出”：

从“添加构建步骤”下拉菜单中选择调用 Ant，并提供 build.xml 的路径，以将元数据从沙盒检索到 Jenkins 工作区：

配置构建：
1. 目标：保持目标为空。在此，你可以指定一个你想运行的目标列表。如果我们将其保持为空，构建脚本中指定的目标将会执行。
2. 构建文件：build.xml 文件的位置在 <JENKINS_WORKSPACE>/<ITEM-NAME>。你可以在此指定构建文件；默认情况下，Ant 会使用根目录中的 build.xml 文件。工作空间根目录的位置是：<JENKINS_WORKSPACE>/$ITEM_NAME。示例：在工作空间 <JENKINS_WORKSPACE>/Retrive_SandBox_to_Git 中构建。
3. Java 选项：<-Xmn1024m> 提供 Java 内存限制，因为如果内存不足，任务会抛出错误。

示例 build.xml 如下所示：

<project name="Force.com Migration Tool" default="retrieveUnpackaged" basedir="." > 
<taskdef uri="antlib:com.Salesforce" 
       resource="com/Salesforce/antlib.xml" 
       classpath="lib/ant-Salesforce.jar" 
   /> 
   <property file="build.properties"/> 
       <property environment="env"/> 
       <property name="sf.username" value="${env.SF_USERNAME}"/> 
       <property name="sf.password" value="${env.SF_PASSWORD}"/> 
       <property name="sf.token" value="${env.SF_TOKEN}"/> 
       <property name="sf.serverurl" value="${env.SF_SERVERURL}"/> 
             <target name="retrieveUnpackaged"> 
                     <sf:retrieve 
                       username="${sf.username}" 
                       password="${sf.password}${sf.token}" 
                       serverurl="${sf.serverurl}" 
                       retrieveTarget="DevOps/src" 
                       unpackaged="${basedir}/package.xml" 
               /> 
       </target> 
</project>

这将从你的组织中检索一组未打包的元数据。在 retrieveTarget 中，指定元数据将存储的路径：

在构建后操作中，我们将执行一个 Shell 脚本，将代码推送到 sandbox_to_git 分支：
- 触发任务 Retrive_SandBox_to_Git2。它将推送 DevOps/src 中由 Build.xml 脚本检索到的所有代码。
- 以下是一些推送代码到 Git 仓库的示例命令：

    $git add.
    $git commit -m "Retrieve metadata from sandbox"
    $git remote add origin <remote-repository-URL>
    $git push -u origin sandbox_to_git

测试任务：确保 Jenkins 中的项目已启用。从项目列表中选择它，然后点击立即构建。
1. 检查控制台输出。构建完成后，点击 “构建详情”，你也可以查看控制台输出，检查构建脚本中是否有错误：

在 Jenkins 控制台查看控制台输出。如果构建成功，则会显示以下消息：BUILD SUCCESSFUL：

验证 Git 分支 sandbox_to_git 中更新的代码。

再次触发相同的任务

要再次执行相同的 Jenkins 任务，请按照以下步骤操作：

登录 Jenkins。
选择你想运行的任务。
点击立即构建。
检查状态/控制台输出。

配置 Jenkins 任务以将元数据部署到沙盒

我们已在 Eclipse 中安装了 Force.com IDE 和 Git。开发者沙盒与 Eclipse 同步。开发者使用 Eclipse 和 Force.com IDE，沙盒将与 Eclipse 工作区同步。修改完成后，开发者将代码推送到 Git 分支，并在 package.xml 中提及部署组件。这个 Git 推送将触发 Jenkins 任务，执行 Ant 部署脚本，将开发者沙盒中的更改部署到测试沙盒：

使用的工具有：

Git：用于跟踪 Salesforce 更改在 Git 中的记录
Force.com Migration Tool：用于 Salesforce 部署
Jenkins：使用 Jenkins 和 Ant 脚本自动化部署到预 UAT 环境

配置步骤如下：

创建一个 Jenkins 任务以将代码部署到沙盒。登录 Jenkins 服务器并点击新建项来创建 Jenkins 任务：

配置源代码管理。复制你 Git 项目的项目 URL，并将其粘贴到仓库 URL 中。

在 Jenkins 凭证中添加 Git 访问凭证。添加你的用户名和密码，并选择以下凭证：

配置你希望构建的 Git 凭证和分支：

选择构建并选择调用 Ant。配置构建文件和 build.properties 文件：

开发者希望部署的组件将会在 package.xml 中列出，并在 Ant 任务中部署。部署任务的示例 Build.xml 如下：

<target name="deployCode">             
    <!-- Deploy Code From src to SandBox --> 
        <sf:deploy 
            username="${sf.username}" 
            password="${sf.password}${sf.token}" 
            serverurl="${sf.serverurl}" 
            deployroot="src" 
                        runAllTests="false" 
        /> 
</target>

一旦开发者将代码推送到相应的 Git 分支，Jenkins 任务将被触发，新代码将被部署到目标沙箱中。这个沙箱可以是 UAT 沙箱或生产环境。你可以使用同一个任务来处理不同的场景。

总结

在本章中，我们学习了如何自动化备份 Salesforce 元数据，并使用 Jenkins 将代码推送到 Git 仓库。通过 GitLab 和 Jenkins 任务，可以跟踪 Salesforce 中的变化。我们解释了如何配置 Ant 迁移工具与 Jenkins 配合使用，以及从沙箱到 Jenkins 服务器的代码提取流程，并使用备份脚本将其推送到 Git 分支。

我们学习了如何搭建自己的 Jenkins 服务器，并配置它从 Salesforce 沙箱中检索元数据。同时，我们还配置了一个 Jenkins 任务，将元数据从一个沙箱部署到另一个沙箱。关于部署任务，我们讨论了可以使用的工具，并通过图示解释了 UAT 或测试环境的部署流程。

在下一章中，我们将学习 Salesforce 中的持续测试和代码覆盖率。我们将讨论如何使用 Selenium 和 Qualitia 在 Salesforce 上进行测试的步骤。我们还将学习如何使用 Jenkins 自动化持续测试的过程。

第七章：持续测试

在上一章中，我们学习了如何设置自己的 Jenkins 服务器并使用 Jenkins 进行持续集成，如何配置 Jenkins 从 Salesforce 沙盒中检索元数据，以及如何将代码推送到 Git 版本控制系统。我们还进行了将元数据部署到 UAT 沙盒的步骤，使用 Jenkins 和 Ant 迁移工具。

本章我们将学习使用 PMD 进行代码质量分析。我们将讨论在使用 Jenkins 进行部署时的持续测试和执行 Apex 测试。我们还将了解 Selenium，并学习如何使用 Firefox 设置 Selenium。我们还将介绍 Salesforce 示例应用程序的录制和回放。我们将讨论如何在 Jenkins 中使用 Qualitia 无脚本自动化工具，在其中我们可以获得 HTML 格式的测试报告。

什么是代码质量？

代码质量是基于一些参数识别的，例如最佳实践标准和规则集。当代码质量提高时，用户接受度测试问题和生产问题减少，生产力提高。通过使用由开源静态源代码分析器生成的 PMD 报告，我们可以分配更多时间来审查代码，从而提高产品质量，同时遵循最佳实践标准和有效的治理。

使用 PMD 报告检查代码质量

执行分析有两种方法。我们将在接下来的章节中讨论它们。

使用 Visual Studio (VS) Code 扩展进行 Salesforce Apex 的 PMD 静态分析

在这里，我们将学习如何直接在 VS Code 上分析 Apex 和 Visual force 文件。首先，你需要在你的机器上安装 Visual Studio Code。（我们已经在第三章中学习了如何安装 VS Code，Salesforce 部署）。

你需要执行以下步骤：

打开 Visual Studio Code 并点击扩展 (Ctrl + Shift + X)：

在市场扩展中的搜索框输入 pmd：

选择 Apex PMD 并点击安装：

安装完成后，点击重新加载，这将重启你的 VS Code：

打开你想分析的文件，以查看 PMD 报告：

现在，通过右键单击并选择所有命令，或者按 Ctrl + Shift + P 打开命令面板。在命令面板中输入 Apex stat：

现在，点击 Apex 静态分析：在文件上。它将在 PROBLEMS 中显示所有分析结果。
解决所有问题后，再次运行 Apex 静态分析：在文件上。

使用命令行进行 Salesforce Apex 的 PMD 静态分析

在这里，我们可以通过单个命令对所有文件执行 PMD 分析。步骤如下：

首先，从sourceforge.net/projects/pmd/files/pmd-eclipse/update-site/下载 PMD JAR 文件，然后查看此截图：

解压 JAR 文件，进入 bin 文件夹，复制该文件夹的路径。
现在，按下 Windows + R 打开运行，然后输入命令以打开命令行面板。
进入你的 bin 路径，方法是输入该文件夹的路径。如果你在另一个驱动器上，首先进入该驱动器并输入复制的路径：

现在，创建你的命令：

pmd -d "Source Path" -R apex-ruleset -language Apex -f CSV > "Destination Ptah\ReportName.csv" //Source Path: Your Project Directory Path till src.
//Destination Path: Report Folder Path where you want to store the report.

然后，执行此命令：

你将获得一个导出的 CSV 文件：

现在，打开那个 CSV 文件，并根据错误类型修改你的代码。

在 CSV 文件中，我们获取以下列：

问题：这是问题的序列号
包：在此列中，我们获取该文件的包名称
文件：在此列中，我们获取该文件的准确文件路径
优先级：有不同类型的优先级，从 1 到 3，它们被添加到此列中
行：在此列中，我们获取问题的准确行号
描述：在此列中，我们获取问题的单行描述
规则集：在此列中，我们获取规则集的名称
规则：在此列中，我们获取规则的名称

规则和规则集有不同的类型。以下是一些规则和规则集的示例：

最佳实践：
- ApexUnitTestClassShouldHaveAsserts
- AvoidGlobalModifier
- AvoidLogicInTrigger
代码风格：
- ClassNamingConventions
- ForLoopsMustUseBraces
- IfElseStmtsMustUseBraces
- IfStmtsMustUseBraces
- MethodNamingConventions
- VariableNamingConventions
设计：
- AvoidDeeplyNestedIfStmts
- CyclomaticComplexity
- ExcessiveClassLength
- ExcessiveParameterList
- ExcessivePublicCount
- NcssMethodCount
- StdCyclomaticComplexity
- TooManyFields
易出错：
- AvoidHardcodingId
- EmptyCatchBlock
- EmptyStatementBlock
性能：
- AvoidSoqlInLoops
安全：
- ApexCRUDViolation
- ApexSharingViolations
- ApexSOQLInjection
- ApexXSSFromURLParam

使用 Jenkins 在部署中执行 Apex 测试

在 Salesforce 代码中，Apex 组件的覆盖率应该超过 75%，才能将变更部署到生产环境。如果在部署过程中任何测试用例失败，则部署到生产环境也会失败。为了避免这种情况，建议先在沙盒环境中测试部署，再将其部署到生产环境。有时，Apex 组件的单个代码覆盖率可能低于 75%，但组织的整体代码覆盖率应该为 75%或更高。为了确保在生产环境中测试用例不失败，可以在沙盒环境中执行一部分测试用例。我们已经在上一章中看到从一个沙盒部署变更到另一个沙盒。我们只需要在build.xml中做少量更改，以指定在部署时要执行的测试子集。

下面是一个带有要执行的测试用例的build.xml示例：

<target name="deployCode"> 
    <sf:deploy username="${sf.username}" password="${sf.password}" 
           sessionId="${sf.sessionId}" serverurl="${sf.serverurl}" 
           deployroot="codepkg" testLevel="RunSpecifiedTests"> 
        <runTest>TestClassSample1</runTest> 
        <runTest>TestClassSample2</runTest> 
        <runTest>TestClassSample3</runTest> 
    </sf:deploy> 
</target>

要运行特定的测试，应该将testLevel参数的值设置为RunSpecifiedTests。一个子元素</runTest>用于指定要运行的测试类。

要从sf:deploy任务中运行所有测试用例，并且带有runAllTests="true"属性，package.xml应该为空，如下所示：

<?xml version="1.0" encoding="UTF-8"?> <Package > <version>42.0</version> </Package>

下面是一个示例build.xml，用于运行所有测试用例：

<target name="deployCode">              
    <!-- Deploy Code From src to sandBox --> 
    <sf:deploy 
        username="${sf.username}" 
        password="${sf.password}${sf.token}" 
        serverurl="${sf.serverurl}" 
        deployroot="src" 
        runAllTests="true" 
    />
</target>

Jenkins 在部署中的角色将保持不变；开发人员只需要更改build.xml和package.xml配置文件中的参数。

什么是持续测试？

持续测试是指在新变化部署到环境后执行测试用例的过程。在持续测试中，我们在每个阶段评估部署，以便在软件开发周期的早期发现现有代码中引入的任何漏洞。软件变更持续从开发环境移至测试环境，测试团队需要测试所有现有功能以及新功能。手动测试需要更长时间完成，并且需要测试团队的反馈来做出进一步的应用交付决策。持续测试帮助我们获得即时反馈，并使测试周期变得更容易。实施持续测试可以减少由于发布包含缺陷的软件而带来的业务风险：

持续测试在前面的图示中已经定义。每当开发团队开发出任何新功能时，开发人员将代码推送到源代码版本管理系统（如 Git），以便跟踪变更。一旦开发环境中的功能准备就绪，它将被移至持续集成服务器，如 Jenkins。Jenkins 将构建源代码，一旦构建部署到测试环境，我们将配置 Jenkins 作业来执行测试用例。对于持续测试，我们可以使用工具编写并执行自动化测试用例，例如 Selenium、Katalon Studio、Qualitia 等。在本章中，我们将只关注 Selenium 测试框架。

引入 Selenium

Selenium 是一个开源工具，用于自动化我们在 Web 应用程序上运行的测试。Selenium 是一个基于 Web 的应用程序。我们可以使用 Selenium 来自动化测试。Selenium 支持多种浏览器，包括 Chrome、Firefox 和 Safari。你不需要脚本或开发知识就可以开始使用 Selenium，具有管理经验的人也可以开始设置 Selenium。使用 Selenium 的录制/回放工具，我们可以在没有脚本语言知识的情况下进行测试。Selenium 支持多个平台，包括 Windows、Linux 和 Mac。我们将查看在 Mac 上设置 Selenium 的步骤。

使用 Firefox 设置 Selenium

我们将在 macOS 上设置 Selenium 与 Firefox。Firefox 的安装步骤可能会有所不同，具体取决于你的操作系统。在本例中，我们使用的是 Mac。

以下是在 Mac 上安装 Firefox 的一些先决条件：

操作系统：macOS 10.9、10.10、10.11、10.12 和 10.13
推荐硬件：配备 Intel x86 处理器的 Macintosh 电脑
512 MB 内存
200 MB 硬盘空间

安装步骤如下：

访问www.mozilla.org/firefox/new/?utm_medium=referral&utm_source=support.mozilla.org。它将自动检测你所使用的平台，并在浏览器中提供下载链接。
点击下载按钮，它将开始下载 Firefox。
下载完成后，打开Firefox.dmg文件。
将 Firefox 拖放到应用程序文件夹中：

它将开始将Firefox.dmg文件复制到应用程序文件夹中：

从应用程序中打开 Firefox。你将看到一个警告，提示 Firefox 正从互联网安装。点击“打开”。
我们的系统中已经安装了 Firefox。我们可以跳过 Firefox 中的邮箱验证。请在 Firefox 中打开www.seleniumhq.org/download/。
转到 Selenium IDE 部分并点击“For Firefox”链接。它会将你重定向到添加 Selenium IDE 扩展页面：

点击“添加到 Firefox”：

该扩展需要一些权限才能正常工作。点击“添加”：

一旦添加了Selenium IDE插件，你将看到弹出窗口：

一旦 Selenium IDE 插件在 Firefox 中安装完成，你可以通过点击右上角的 Selenium IDE 图标来启动它：

使用 Selenium 录制测试

录制测试的步骤如下：

一旦启动 Selenium，你将看到以下窗口。提供基础 URL：login.salesforce.com，然后点击“开始录制”：

您在 Firefox 中执行的每一个操作都将被 Selenium 跟踪。打开 login.salesforce.com，提供用户名和密码进行登录，然后点击登录：

一旦登录，您可以点击任何项目或执行任何操作。您将看到一个通知，表示 Selenium 正在录制命令：

执行任务后，点击注销。您可以在此屏幕截图中看到 Selenium 录制的步骤：

您可以在 Selenium IDE 中看到已存储的命令：

打开 Selenium IDE 窗口，您将看到 Selenium 收集的数据。点击停止录制：

将录制保存为任意名称，例如 Sample。您可以将名称指定为您执行的测试，以便遵循有意义的命名约定：

使用 Selenium 回放录制的测试

Selenium 完成了一条记录步骤。现在，我们可以使用相同的文件重新运行这些步骤。这个过程叫做回放：

从 Firefox 浏览器打开 Selenium IDE。
点击打开项目：

浏览到我们在录制步骤中存储的文件 Sample.side。打开该文件并点击运行 当前测试：

Selenium 会打开 Salesforce UEL，并执行示例测试用例中的步骤。登录 Salesforce 后，执行完测试用例再注销。
检查 Selenium 的日志控制台中的日志：

如果要停止执行，请点击停止测试执行：

我们可以用任何语言编写测试用例，并在部署到 Salesforce 沙盒后执行测试用例。Selenium 可以用于自动化测试。每当我们将代码从开发沙盒部署到 UAT 沙盒，或从沙盒部署到生产环境时，我们可以使用 Selenium 执行测试用例，覆盖每一个场景，确保应用程序没有 bug。手动测试所有功能可能需要很长时间，最终会导致测试周期延长。频繁将更改发布到生产环境通常需要大量的测试和反馈循环，以确保应用程序的质量。

我们可以为在部署沙盒上使用 Selenium 执行测试用例创建一个 Jenkins 作业。如果沙盒不是完全复制沙盒，那么我们可能需要添加一些测试数据、修改用户的电子邮件 ID 等。对于这样的任务，我们可以使用 Selenium 来自动化并加速软件测试和交付的过程。

引入 Qualitia

Qualitia 是一个无脚本测试工具。Qualitia 是一个功能测试自动化平台，提供了一种无需编写脚本即可自动化测试的方法。Qualitia 也与 Jenkins 集成。Qualitia 基于 Selenium，不要求你编写任何脚本。执行 sandbox 中的测试用例后，Qualitia 会以 HTML 格式呈现测试用例的结果，以便最终用户可以阅读。我们可以将这些 HTML 文件托管在文件服务器上，开发人员和测试人员可以使用 Web 浏览器访问它们。

Qualitia 提供与 Jenkins 的集成。我们可以在部署到 UAT sandbox 后执行自动化测试用例。此外，我们还可以在我们的预生产或暂存 sandbox 中每天定时执行自动化测试。

使用 Qualitia 运行测试用例

要使用 Qualitia 运行测试用例，我们需要将其与 Jenkins 集成。Qualitia 的任务将在 Windows 服务器上执行，如果我们的 Windows 服务器上没有 Jenkins，我们可以将 Windows 客户端添加到 Jenkins 服务器，并在其上运行 Qualitia 测试用例。我们需要 Qualitia JAR 文件、XML 测试用例的路径和 Chrome 驱动程序，以便执行测试。Qualitia 将运行一个测试用例 sandbox，并生成 HTML 格式的报告。

用例 – 使用 Qualitia 进行持续测试

以下图表展示了开源工具与 Salesforce sandbox 的集成，并使用 GitLab、Force.com Migration 工具、Jenkins 和 Qualitia 提供版本控制、无脚本测试和自动化部署：

在前面的场景中，开发人员使用 Eclipse 和 Force.com IDE。sandbox 将与 Eclipse 工作空间保持同步。更改完成后，开发人员将把更改推送到 Git，并在 package.xml 文件中提及要部署的组件。此 Git 推送将触发 Jenkins 任务，执行 Ant 部署脚本，并将开发人员的 sandbox 更改部署到测试 sandbox。如果部署成功，将触发另一个任务运行 Qualitia 测试，并生成 HTML 格式的报告。

以下是所使用工具的列表：

Git：用于跟踪 Salesforce 更改的 Git
Force.com Migration 工具：用于 Salesforce 部署
Jenkins：用于自动化部署到预 UAT 环境，通过 Jenkins 和 Ant 脚本
Qualitia：无脚本测试工具

注意：我们可以使用 Selenium 进行自动化测试，代替 Qualitia。

总结

在本章中，我们学习了代码质量和持续测试。我们讨论了自动化测试中使用的工具，如 Selenium 和 Qualitia。我们学习了如何一步一步地设置 Selenium 与 Firefox 的集成。我们在一个示例 Salesforce 应用中执行了一个测试用例，使用 Selenium 的录制和回放功能。

我们讨论了 Qualitia 无脚本自动化工具的使用案例，该工具用于对 Salesforce 应用程序进行测试，并以 HTML 格式存储自动化测试的结果。我们演示了一个使用图表与 Git 进行版本控制、Jenkins 作为持续集成服务器，以及使用 Qualitia 执行 Salesforce 应用程序自动化测试的使用案例。如果需要，我们可以将 Qualitia 替换为 Selenium。

第八章：跟踪应用程序变更和将 DevOps 应用于 Salesforce 的投资回报率（ROI）

本章我们将讨论如何使用开源技术（例如 Git 源代码控制版本系统）来跟踪应用程序变更。我们将学习 Bugzilla 的基础知识，以及如何跟踪测试人员或用户报告的问题，直到问题/功能的修复部署到生产环境。

我们还将看到如何在 Jenkins 中添加一些构建后步骤，将构建状态报告给 Git。这将使开发人员能够获得与每个提交相关的构建状态信息。我们将讨论 DevOps 如何帮助任何 Salesforce 组织更快速地交付应用程序，以及将 DevOps 应用于 Salesforce 的投资回报率（ROI）。

如何跟踪应用程序变更

没有版本控制系统的情况下跟踪应用程序的变更，就像在大海捞针。我们已经在第五章《版本控制》中看到如何使用 GitLab 跟踪应用程序变更。每当测试人员报告 bug 时，我们会使用 Bugzilla 等 bug 跟踪工具来追踪 bug 的生命周期——从发现问题到修复发布到生产环境。当一个新的 bug 或功能被添加到 bug 跟踪工具中时，它会被分配给开发人员，开发人员开始处理该修复或新功能。当开发人员提交变更到相应的功能分支时，代码变更会被记录在 Git 仓库中。开发分支的提交信息应包含 bug ID，以便标识与特定 bug 或功能相关的变更。

如果添加了新功能或修复了某个问题，开发人员可以添加有意义的提交信息，帮助我们追踪新功能的变更。当我们想将变更合并到开发分支或对提交进行樱桃挑选时，带有 bug ID 的有意义提交信息让这一过程变得更容易。

介绍 Bugzilla

Bugzilla 是一款开源的错误跟踪系统。使用 Bugzilla，你可以创建一个 bug 并追踪这个 bug，直到它被关闭。Bugzilla 提供了项目管理和问题跟踪功能。Bugzilla 被用来提升性能和可扩展性。其他功能包括一个先进的查询应用，可以记住你的搜索记录以及集成的电子邮件功能。

首先，你需要在系统或服务器上安装 Bugzilla，通过浏览器访问 Bugzilla。步骤如下：

你可以从www.bugzilla.org/docs/4.4/en/html/installation.html安装 Bugzilla 到一台机器上。
现在通过浏览器打开 Bugzilla，屏幕会显示如下内容：

点击登录并输入凭证。登录后，页面将显示如下内容：

现在点击“用户偏好”或“管理”以打开管理面板。
打开管理面板后，点击用户（Users）：

在下一个页面，点击添加新用户（add a new user）：

输入登录名、密码和真实姓名。最后，点击添加（Add）：

选择相关权限并点击保存更改（Save Changes）：

现在点击主页上的“报告 bug（File a Bug）”：

在下一个页面，你可以看到多个字段：
- 产品：Git 演示项目
- 报告人：ngornalli
- 组件：Git 项目模型
- 组件描述：此组件是为 Git 演示项目创建的
- 版本：1.0
- 严重性：高
- 硬件：其他
- 操作系统：Windows
- 组织*：Transformer
- 工单类型*：缺陷
- 提出者：QA
- 复现问题的步骤*：复现问题的步骤
- 预期结果*：预期结果
- 摘要：为 Git 演示项目添加了新缺陷
- 描述：描述
- 附件：如果有任何截图，请附在此处

最后，点击提交 bug（Submit Bug）。

将构建报告发布到 Git

正如我们在第六章《持续集成》中看到的那样，我们可以通过 Git Webhook 在代码推送到 Jenkins 时触发 Jenkins 任务。Jenkins 将使用 Ant Migration Tool 启动构建并将元数据部署到沙箱中。然而，构建是否成功或失败并不会显示出来。所以我们需要修改 Jenkins 任务，使其从 Git 部署更改到沙箱。进入你想修改的 Jenkins 任务，点击配置（Configure）。

添加构建后 Git 发布器（Git Publisher）步骤，以将构建状态设置为 Git 提交：

在 GitLab 中，你可以查看 Jenkins 任务的状态，以检查它是成功还是失败。我们可以跟踪 Git 中的每次提交，查看沙箱构建的部署步骤是否通过。如果我们配置 Jenkins 任务在沙箱测试完成后运行自动化测试用例，我们可以在 Git 中获得自动化测试用例执行的状态：

DevOps 如何帮助组织快速交付

版本控制帮助我们跟踪问题并回滚更改。在 GitLab 中区分分支变得更加容易。如果出现问题，查找 bug 或问题也变得更加简单，因为我们所有的更改都已在 Git 仓库中跟踪。并且，Jenkins 能够从沙箱中检索元数据并将其存储到 Git，这在进行备份时非常有用。我们无需重复相同的任务。我们可以配置 Jenkins 任务，在 Git 中备份元数据组件并发送通知邮件给相关管理员。

Jenkins 持续集成服务器帮助我们将更改从开发人员的机器部署到沙箱环境，或从一个沙箱环境部署到另一个沙箱环境。我们可以通过 Jenkins Webhooks 配置 Jenkins 作业，以便在更改推送到 Git 时自动进行部署。从开发人员沙箱到 UAT 沙箱的元数据部署可以自动化，并且 Salesforce 凭证安全地存储在 Jenkins 凭证中的密文文本中，仅在执行 Jenkins 作业时使用。

代码覆盖率对于提高开发人员编写的代码质量至关重要。我们可以确保在开发应用程序时遵循标准实践。通过 Jenkins 执行 Apex 测试来部署元数据到沙箱环境，是确保按照 Salesforce 标准实现 75% 代码覆盖率的简便方法。

提高生产力

当我们大部分部署任务通过 Jenkins 持续集成服务器自动化，并且所有更改都在 Git 等源代码版本控制系统中进行追踪时，开发人员可以将更多时间投入到实际的开发任务中。如第七章《持续测试》中所示，借助自动化测试，我们可以更快地覆盖测试周期，并满足 Salesforce 中的代码覆盖率标准。Selenium 使得自动化测试用例变得更加简单。在软件开发周期的早期阶段发现缺陷非常重要，这可以确保软件无缺陷，并使得应用交付到生产环境的速度更快。

如何衡量投资回报率（ROI）？

使用开源工具（如 GitLab、Jenkins、Selenium 等）将 DevOps 方法应用于 Salesforce，帮助组织以最小成本和最小努力（仅需一次性设置和配置）建立自动化流程。

ROI 无法仅通过一个数字来衡量，但通过应用 DevOps 的 ROI 可以通过节省部署 Salesforce 所需的时间以及开发人员不小心覆盖彼此更改时需要返工的时间来衡量。在软件开发的早期阶段通过自动化测试更快地识别问题，使得修复问题变得更容易。修复生产环境中的缺陷所耗费的时间，比在测试或预生产环境中修复缺陷要多。生产环境中的缺陷会对我们的应用程序产生业务影响。

在将更改部署到生产环境时，维护窗口内的时间缩短和生产环境中问题数量的减少，帮助我们衡量将 DevOps 应用于 Salesforce 组织的 ROI。通过 Jenkins 持续集成，自动化测试用例可以将发布周期从几周缩短到几天。

通过将 DevOps 实践应用于 Salesforce 应用程序，我们可以实现客户满意度，并加快产品交付过程。开发人员无需在应用程序维护上花费过多时间，而可以更多地专注于开发新功能。

总结

在本章中，我们了解了如何跟踪应用程序变化，使用 Bugzilla，提升生产力以及衡量投资回报率（ROI）。

我们从对 DevOps 实践或相关工具几乎没有了解开始本书的学习。我们通过在 Salesforce 中创建一个示例应用程序，学习了一些 Salesforce 的基础知识，并讨论了不同的沙盒环境。通过将 Eclipse 与 Salesforce 结合使用，我们可以将 Git 与沙盒集成，实现源代码控制版本系统。我们了解了 Salesforce 中使用的不同部署方法，并使用 Jenkins 持续集成服务器自动化了 Salesforce 的部署。

我们学习了如何搭建自己的 GitLab 服务器，并将代码更改从 Salesforce 沙盒推送到 GitLab 仓库。在 Salesforce 环境中使用 Jenkins 服务器实现持续集成，帮助我们加速部署到 UAT 或其他沙盒环境。

我们学习了如何使用 Selenium 自动化测试 Salesforce 应用程序。我们通过一个示例 Salesforce 应用程序讨论了 Selenium 的录制与回放功能。自动化测试帮助我们将测试周期从几天缩短到几个小时。我们看到 DevOps 工具如何在 Salesforce 应用程序中发挥作用。你可以将本书中学到的概念应用到任何 Salesforce 应用程序中。在本书中，我们尽力为你提供有关 DevOps 工具的有益见解，并提供一步步的指导，帮助你使用开源工具设置自己的 DevOps 流程。本书中的大多数练习都可以通过免费 Salesforce 账户来完成。

posted @ 2025-06-29 10:39 绝不原创的飞龙阅读(15) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

Salesforce-DevOps-全-

Salesforce DevOps（全）

序言

本书适合谁阅读

本书涵盖的内容

为了充分利用本书

下载彩色图片

使用的约定

联系我们

评价

第一章：Salesforce 开发和交付过程

典型的 Salesforce 开发过程（没有 DevOps）

传统部署

传统部署的问题

沙盒

用于 Salesforce 开发的 Eclipse

安装带有 Force.com IDE 插件的 Eclipse Neon

在 Eclipse 中配置 Force.com 项目

技术和业务挑战

Salesforce 的 DevOps？

总结

第二章：将 DevOps 应用于 Salesforce 应用程序

在 Salesforce 开发中对 DevOps 流程的需求

Salesforce 的 DevOps 与其他技术栈的差异

示例 – Java 开发栈的典型 DevOps 流程

在 Jenkins 服务器中配置 Maven

在 GitHub 项目中添加 Jenkins webhook URL

持续部署

在 Jenkins 服务器上安装 Publish Over SSH 插件

总结

参考文献

第三章：在 Salesforce 中的部署

在 DevOps 中，什么是部署？

Salesforce 中的部署

变更集

部署连接

使用变更集进行部署

创建部署连接

创建出站更改集

验证传入的变更集

使用快速部署来部署变更集

使用 Ant 迁移工具进行部署

使用 Force.com IDE 部署 Apex

将 Salesforce DX 插件安装到 Visual Studio Code 中

总结

第四章：Force.com 迁移工具简介

什么是 Force.com 迁移工具？

设置 Force.com 迁移工具

前提条件

Java

Ant

在 Linux 上安装 Ant 迁移工具

在 Windows 上安装 Ant 迁移工具

安装 Salesforce Ant 迁移工具

从沙箱中检索元数据

在沙箱中部署元数据。

使用 destructiveChanges.xml 从 Salesforce 组织中删除文件/组件

Force.com 工具如何帮助开发人员和 DevOps

故障排除

摘要

第五章：版本控制

SCVS 是什么？

Salesforce 中的版本控制

Git 介绍

在 Linux 实例上设置 GitLab 服务器

系统要求

安装 GitLab 服务器

在 GitLab 中创建您的第一个项目

使用 Git 仓库

查看提交历史

向 GitLab 添加用户

故障排除

解决方案

分支策略

使用 Git CLI 处理分支

将更改从开发分支合并到主分支

在 Eclipse IDE 中使用 Git

配置 Git 并推送代码到 Git

使用 `destructiveChanges.xml` 从 Salesforce 组织中删除文件/组件