【51CTO.com快译】随着编排工具的普及，我们能够以持续集成(CI)和持续交付(CD)的方式，实现开发与运营的无缝协作。在许多软件开发团队中，他们首选的DevOps自动化工具，当属Jenkins。下面，我将和您讨论在使用Jenkins的过程中，一些值得遵循的优秀实践。
一、时刻保持Jenkins的安全
在默认配置情况下，Jenkins是不执行任何安全检查的。也就是说，除一些简单基本的Jenkins配置、作业和构建，网站的访问者几乎可以在Jenkins的主数据库中执行任何随机代码。同时，Jenkins还允许在所有连接的代理上，执行包括用户密码、证书、以及其他隐私数据之类的代码操作。
具体实践
为了保护Jenkins的安全，我们需要通过如下两个方面，来“配置全局安全性(Configure Global Security)”选项。
安全领域： 通常也被称为“身份验证”。它会告知Jenkins的基本环境，以及从何处提取用户信息。
如上图所示，从Jenkins V2.214和Jenkins LTS V2.222.1开始，“Jenkins自己的用户数据库”被用作了默认的安全选项。而对于两者之前的版本，我们应当选中“启用安全”复选框，以方便用户使用其凭据登录，进而避免任何侵入。
在配置有诸如LDAP之类外部身份提供者的组织中，我们需要为Jenkins实例安装并启用LDAP插件，以实现将所有身份验证(包括用户和组)，都委派给已配置的LDAP服务器。
授权：告知Jenkins环境中有关哪些用户和(或)组，可以访问Jenkins的哪些方面，以及他们的权限。如上图所示，我们有五种授权的选择方式：
- 任何人都可以做任何事：除了本地测试的Jenkins控制器，我们应避免启用该设置。毕竟所有人、包括匿名用户都可以完全控制Jenkins，是极其危险的。
- 旧版模式：我们同样应当避免选用该设置。只有具有“管理员”角色的用户才能被授予对系统具有完全控制权;否则，他们将只有读取权限。
- 已登录的用户可以执行任何操作：此模式会强制每个用户在使用Jenkins之前，必须登录。据此，匿名用户只能获得对于Jenkins的读取访问权限，或者根本就没有访问权限。同时，用户的任何操作也会得到审核。
- 基于矩阵的安全性：该方案可以准确控制在Jenkins环境中，哪些用户和组可以执行哪些操作。
- 基于项目的矩阵授权策略：该插件提供了基于矩阵的安全性，和基于项目的矩阵授权策略，因此它们需要在Jenkins上被单独安装。同时，该授权方案是对基于矩阵的安全性的扩展，它允许在“项目配置”的界面中，为每个项目、以及特定的用户或组，分别定义访问控制列表(ACL)。总的说来，此类策略为许多Jenkins环境提供了极好的安全性和灵活性，因此是一种不错的实践。
为了保护Jenkins用户免受其他威胁，我们还可以按需开启如下功能(它们默认处于关闭状态)：
- 跨站点请求伪造(CSRF)保护：防止针对运行在防火墙内部的Jenkins进行远程攻击。CSRF设置的路径为：“管理Jenkins”>“配置全局安全性”>“部分：CSRF保护”。具体说明请参见--https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery。当然，从Jenkins 2.0开始，CSRF保护是默认已启用的。
- 在主节点上运行构建的安全隐患：在主节点上运行的构建，是可以读取或修改JENKINS_HOME中任何文件的。由于可以读取凭据，创建管道与作业，安装插件，因此会影响Jenkins的整个构建过程。通常，为了配置主节点为不具备执行权限，我们既可以只在构建代理上运行构建，又可以在构建代理中，将管理Jenkins的人员与配置人员，以及提交项目的人员角色区分开来;或者直接使用“作业限制插件(Jobs Restrictions Plugin)”，来对哪些作业可以在主节点上运行进行过滤。
二、始终备份JENKINS_HOME目录
Jenkins的主目录包含了：作业配置、构建日志、插件配置等各种重要的数据。我们可以通过Jenkins提供的插件，来配置需要备份的作业。
具体实践
1.精简备份(Thin Backup)插件
这是所有提供自动化定期备份的工具中，最方便的插件之一。它的启用过程为：
- 通过“管理Jenkins”>“管理插件”>“单击‘可用’选项卡”>“搜索‘精简备份’”以安装插件。
- 完成安装后，请转到“管理Jenkins”>“精简备份”>“设置”。
- 单击“立即备份”以测试备份的效果。
2.定期备份插件
如下图所示，一旦配置完成，该插件将会定期运行备份作业。具体内容，请参阅--https://plugins.jenkins.io/periodicbackup/。
该插件定义了如下三个方面：
- 文件管理器：定义在备份中需要包括哪些文件，以及文件的还原策略。例如，ConfigOnly将仅选择配置类XML文件。
- 存储：指定存档和取消存档备份的方法。例如，“ZipStorage”会将备份文件压缩为ZIP档案。
- 位置：指定备份的位置。例如，“LocalDirectory”是将备份文件存储到指定的路径上。
3.配置常规备份作业
- 在创建新的Jenkins任务时选择“自由式项目”。
- 将SCM标记为“无”。
- 在“构建触发器”中选择“定期构建”，然后在“计划”中配置频率。
- 根据配置文件，添加执行壳(Execute Shell)，以构建作业。
4.将Jenkins配置备份到Google Cloud存储空间
如果您在Google Cloud的Kubernetes集群上部署了Jenkins的服务器配置，则可以将上述精简备份插件与Google Cloud Storage插件一起使用，以便连接到云端。具体实现说明，请参照--https://medium.com/faun/backing-up-jenkins-to-google-cloud-storage-4ba12e69ded2。
三、为每个维护或开发分支，设置不同的作业/项目
众所周知，利用持续集成工具的优势之一便是：在开发生命周期的早期阶段，能够检测出问题。而Jenkins恰好提供了并行构建管道的方法。因此，为每个分支设置不同的作业/项目，可以让我们在开展并行开发的同时，尽早发现问题，降低风险，并提高开发人员的生产率。
具体实践
最新的Parallel Test Executor插件(请参见--https://plugins.jenkins.io/parallel-test-executor/)，可帮助我们执行并行测试。
四、防止并行运行的作业产生资源冲突
当然，值得注意的是，多个同时运行的作业在创建服务或需要排他式的访问时，可能由于冲突的产生，而导致Jenkins管道失效。
具体实践
我们可以为并行的各个项目构建，分配不同的端口，以避免冲突。例如，对于数据库之类需要锁定某个持久资源的需求场景，我们可以通过采用Throttle Concurrent Builds 插件(请参见--https://wiki.jenkins.io/display/JENKINS/Throttle+Concurrent+Builds+Plugin)，来根据全局配置或某个项目启用的节点数，调节并行构建的数量。
如上图所示，我们可以使用0，将并发构建设置为无限。
五、使用“文件指纹”管理依赖项
我们在Jenkins上创建依赖项时，往往容易引发相互之间版本的混淆问题。而Jenkins支持的“文件指纹(File fingerprinting)”功能正好可以简化该过程。
具体实践
我们需要将所有相关项目，都配置为记录下由项目产生的jar文件，以及项目所有依赖项的jar文件指纹。在具体配置上，您可以依次进入：“项目”>“配置”>“构建后操作”>“记录指纹”。同时，您可以参考文档--https://wiki.jenkins.io/display/JENKINS//Fingerprint。
六、避免在管道中使用复杂的Groovy代码
对于Jenkins管道，Groovy代码往往会在主服务器上调用大量的主资源(如：内存和CPU)来执行。因此，我们需要减少在管道中执行的Groovy代码量。
具体实践
1. JsonSlurper
此功能函数与XmlSlurper或readFile类似，可被用于从磁盘上读取文件，将文件中的数据解析为JSON对象，然后使用JsonSlurper().parseText(readFile(“$LOCAL_FILE”))命令，将该对象注入管道中。由于该命令会两次将本地文件加载到主服务器上的内存中，因此如果文件过大、或该命令被反复执行的话，则将消耗大量的内存。
解决方案：为了代替JsonSlurper，我们可以使用shell step的如下命令。
- def JsonReturn = sh label: ”, returnStdout: true, script: ‘echo “$LOCAL_FILE”| jq “$PARSING_QUERY”‘
它将使用代理资源来读取文件，其中的$PARSING_QUERY将有助于将文件解析成小块。
2. HttpRequest
通常，此命令可用于从外部资源获取数据，并将其存储在变量中。在此过程中，由于请求直接来自主服务器，而如果主服务器未加载证书，则可能造成HTTPS请求的结果不一致。另外，该请求的响应也会被重复性地存储了两次。
解决方案：使用shell step来执行代理的HTTP请求。例如，我们可以适当地使用诸如curl或wget等工具。同时，如果结果必须是在Jenkins管道的后端，那么我们则必须在代理端过滤掉尽可能多地结果，以便只把必要的信息传送到Jenkins的主数据库中。
七、建立可扩展的Jenkins管道
相比一般的程序库，共享库(Shared Libraries)提供了版本控制的管道代码。我们可以从源代码管理(SCM)处进行存储和访问。
具体实践
我们需要在SCM中存储具有一致性结构的源文件，然后使用SCM的插件，将该库连接到Jenkins实例上。具体的操作步骤为：依次在“管理Jenkins”>“配置系统”>“全局管道库”下启用全局共享库。当然，我们也可以在Jenkinsfile中使用库名称，以允许管道访问共享库。
八、管理声明式语法和声明式管道
当涉及到企业级Jenkins的实施和管道资源的管理时，我们可以通过声明式管道配置，告知系统该如何运作，以便将复杂性转移到系统上。同时，您可以参考通用的声明性步骤(请参见--https://jenkins.io/doc/book/pipeline/getting-started/#directive-generator)，来创建未开发的管道;或使用代码段生成器(请参见--https://www.jenkins.io/doc/book/pipeline/getting-started/#snippet-generator)，将现有的构建步骤转换为管道语法。此外，《管道入门指南》和《管道示例》都是两个不错的社区参考资源。
九、保持较高的测试代码覆盖率，并将单元测试作为管道的一部分
显然，代码测试的覆盖率越高，产品的缺陷就会越少，用户验收测试(UAT)的通过率也就越高。因此，我们需要依靠更详细的单元测试，以及更高的测试覆盖范围，来确保开发人员在开发生命周期的早期阶段，提高代码的质量。
具体实践
1. Jenkins Cobertura插件
为了捕获代码覆盖率的相关报告，我们需要完成Cobertura插件的如下配置步骤：
- 通过“管理Jenkins”>“管理插件”来安装Cobertura插件。
- 配置项目的构建脚本，以生成Cobertura XML报告。
- 启用“发布Cobertura覆盖率报告”。
- 指定生成coverage.xml报告的目录。
- (可选)配置覆盖率的相关指标。
您可以通过链接，来获悉如何配置单个项目、项目的层次结构、以及Maven。
2.代码覆盖率API插件
作为统一的API插件，它能够支持Cobertura等其他插件。其主要功能包括：
- 根据用户的配置，查找覆盖率的相关报告。
- 使用适配器将报告转换为标准格式。
- 汇总已解析的标准格式化报告，并在图表中显示已解析的结果。
3.LambdaTest Selenium Grid Cloud
由于提供了广泛的浏览器及其版本库，因此您可以在使用Selenium测试套件，在执行自动化测试时，获得更高的测试覆盖率。通常，LambdaTest Jenkins插件可以提供：
- 为Jenkins作业配置LambdaTest凭据。
- 设置Lambda隧道并删除二进制文件，以方便在本地托管的Web应用上，进行自动化跨浏览器测试。
- 将包括视频日志、网络日志、以及LambdaTest执行步骤的相关截图等所有测试结果，嵌入Jenkins的作业结果。
在完成LambdaTest Jenkins插件的安装后，我们通过将Jenkins CI实例连接到LambdaTest grid上，来自动化Selenium自动化测试脚本。您也可以通过链接，参考Jenkins集成的支持文档。
十、监控CI/CD管道
我们需要通过监控，来获悉诸如云服务、网络、测试服务等外部依赖项是如何影响CI/CD管道的，以便及时采取行动。在此，我们可以使用Jenkins Slack插件，将错误通知发送到由值守工程师监控的频道中。该插件不但可以提供诸如：构建合格率、平均构建时间、以及特定阶段的错误计数等信息;还能够协助我们识别出在构建中，效率低下、需要改进的潜在区域。
小结
总的说来，Jenkins的优秀实践包括：让Jenkins运行在自己的用户数据库上，采用基于权限和用户矩阵的访问控制方式，自动运行相关配置的备份，鼓励应用团队采用Shell step，以避免复杂的Groovy脚本，拥有共享库和Jenkinsfiles的所有权，通过使用自动化状态插件来监控管道，并定义声明性的管道，提高代码测试的覆盖率，以及让代码覆盖率API与LambdaTest Selenium Grid相集成，以实现无缺陷的交付。
原文标题：Are You Following These Jenkins Best Practices?，作者: Kritika Murari
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
