使用Jenkins进行Salesforce部署

简介

Salesforce是一个CRM（客户关系管理）平台，用于记录客户从公司购买服务时的核心用户旅程。它有自己的专有开发语言，叫做Apex。作为一个平台，它能够存储和处理大量的数据。它也有不同的连接器，可以整齐地与其他平台整合。

我最近有机会使用Jenkins创建管道，将代码部署到Salesforce平台上。这篇文章描述了我在使用一些不同的技术实现流水线时遇到的挑战:

蚂蚁
带有改进的Git策略的Ant
SFDX（Salesforce开发者体验）

如果你正在寻找使用Jenkins协调Salesforce部署的方法，那么请继续阅读......你可以在文章的最后感谢我 🙂

第一种方法:蚂蚁

Jenkins是市场上最流行的CI工具，并提供了各种各样的开源插件。最重要的是，它对Groovy语言的支持意味着几乎所有的事情都可以用脚本来完成。我们的第一个方法是一个Ant项目，它将Salesforce Apex代码，构建成一个包，并将其部署到Salesforce环境中。

<project name="Sample" basedir=".." xmlns:sf="antlib:com.salesforce">
    <property environment="env"/>
    <target name="deploy">
      <sf:deploy username="${sf.username}" 
        password="${sf.password}" 
        serverurl="${sf.serverUrl}" 
        maxPoll="200"
        pollWaitMillis="500000"
        testLevel="${sf.testLevel}"
        deployRoot="src" 
        checkOnly="${sf.checkOnly}" />
    </target>
</project>

请注意，包的部署是分两个阶段进行的，我们现在要深入研究。

第1阶段

这个阶段针对给定的环境验证软件包，以确保现有功能不被破坏。这是通过在该环境中运行所有单元测试来完成的，而不需要实际部署该包。这是通过设置checkOnly 到true 来实现的。

在我们的案例中，团队使用项目分支，由团队负责人管理。开发人员为用户故事的实现创建功能分支，并在完成后将其合并到 "中心枢纽 "集成分支。每天，团队负责人都会将集成分支合并到项目分支中。请注意，本地代码的合并是为了确保功能分支的代码总是从上游的集成分支中更新。

第二阶段

如果第1阶段成功，第2阶段就将软件包部署到环境中。

这种方法花了大约20分钟来验证，再花20分钟来部署。此外，运营团队的人需要合并拉动请求，以便通过Jenkins触发自动部署。

针对环境验证一个软件包所需的时间是不同的，这取决于你的Salesforce组织的规模。我们发现，单元测试的数量对部署的时间有很大影响。默认情况下，Salesforce需要75%的单元测试在代码验证中成功通过。虽然这被认为是一个最佳实践值，但如果有必要，也可以修改。

因此，综上所述，这种方法在分支维护和冲突解决方面的成本很高，因为它要求团队领导每天都要合并项目分支，而运营团队也要合并以触发部署。这也是非常缓慢的。

第二种方法:采用改进的Git策略的Ant

第二种方法的主要目标是允许开发人员在不需要运营团队的情况下触发部署，但也要确保部署的执行仍然由有特权的人（如团队领导）批准。这一点很重要，因为开发人员在海外工作，而运营团队在岸上工作，所以消除合并的依赖性是弥合不同地点和时区之间差距的一种方式。

顺便说一下，在尝试这种方法的同时，SonarQube还推出了对Apex代码分析的支持，所以我们认为除了传统的PMD代码扫描之外，我们还应该包括这个。

这种方法的关键是，管道行为是以拉动请求的标题为条件的。如果标题是 "Deploy to <environment>"，那么管道将部署到该Salesforce环境。否则，管道只对环境进行代码验证，而不进行部署。

这个过程涉及到一个开发人员提出一个拉动请求，以验证针对Salesforce环境的代码。验证成功后，拉动请求被更新为构建状态。基于构建状态，团队领导将拉动请求的标题更新为 "Deploy to <environment>"，这就触发了Jenkins重新运行管道并部署到Salesforce环境。

请注意，对于这种方法，项目分支被删除，集成分支是所有团队中唯一的上游分支。

这个管道流程运行良好，运营团队也得到了极大的解放。然而，我们仍然没有加快验证或部署过程。为了使这个过程更有效率，减少管道的执行时间，我们必须尝试一些完全不同的方法。

第三种方法: SFDX

Salesforce开发者体验（SFDX）引入了很多新功能，这意味着我们的代码必须迁移到新的SFDX结构中，以便在SFDX环境中工作。

最重要的是，SFDX有自己的CLI工具，用于部署代码或针对任何环境运行验证。它还支持创建Scratch Orgs，这是一个为代码验证而即时创建的环境，但不必保留持久的环境。

对于这种方法，分支策略与我们之前使用的类似，只是代码是用CLI命令部署的。

//Deploy to SIT with no Unit tests
sfdx force:source:deploy -p deploypackage/force-app/main/default -w $SF_TIMEOUT -u $SF_USERNAME

请注意，该命令将代码部署为独立的文件，而不是创建一个完整的部署包。这有助于我们将部署剥离到只有在特定拉动请求中被修改的文件（通过使用Git APIs）。然而，请注意，如果一个文件作为拉动请求的一部分被删除，那么就需要运行一个额外的命令来删除相应的包。

//Delete files using the delete command
sfdx force:source:delete -p deletepackage\\force-app\\main\\default\\ -w 90 -u $SF_USERNAME -r

还要注意的是，为了实现这一点，Jenkins管道必须创建两个单独的文件夹，并根据拉动请求有选择地将文件放入其中。

这种方法将典型部署的总体时间缩短到2秒左右（取决于拉动请求中包含的文件数量）。这大大减少了开发人员不得不花费的等待反馈的时间。运行的单元测试的数量也大大减少，因为Salesforce只在相关功能被改变时才运行特定的单元测试。

总结

对我们来说，一个既快速又需要最少人工干预的部署管道的关键是我们的Git分支策略，以及使用最近Salesforce版本中引入的更有效的功能。在Salesforce中还有很多其他工具可以执行类似的部署策略，但我相信，你使用哪种工具取决于你如何使用Salesforce，以及你愿意在多大程度上确保部署过程中的代码质量。