强制执行 Jenkins 最佳实践
| 这是 Jenkins World 演讲者 David Hinske 的客座文章，他是 Goodgame Studios 的 Release Engineer。 |
大家好，我叫 David Hinske，我在 Goodgame Studios (GGS) 工作，这是一家位于德国汉堡的游戏开发公司。作为拥有多个开发团队的公司中的 Release Engineer，使用多个 Jenkins 实例非常方便。虽然这种方法在我们公司效果很好，并且给了开发人员很大的自由度，但我们在维护和标准方面遇到了一些长期问题。这些问题主要由插件的错误配置或未使用引起。考虑到“以代码即配置”的理念，我采用了静态代码分析的方法，借助 SonarQube（一个用于管理代码质量的平台）来分析我们所有的 Jenkins 作业配置。
作为一个小型集中的团队，我们一直在寻找一种简单的方法来控制我们不断增长的 Jenkins 基础设施的健康状况。考虑到“以代码即配置”，我开发了一个 SonarQube 的简单扩展，用于管理所有新创建的 Jenkins 实例的质量和使用情况。现有的 SonarQube 功能（如自定义规则/指标、质量配置文件和仪表板）使我们和开发团队能够分析和衡量我们公司所有创建作业的质量。尽管 Jenkins 配置分析不能涵盖 SonarQube 代码质量的所有方面，但我认为在约定/标准、重复、复杂性、潜在错误（错误配置）以及设计和架构方面仍有潜力。
所有使用 Jenkins 的人都可以利用这次分析的结果。为了实现这一点，我开发了一个 SonarQube 的简单扩展，其中包含了连接我们的 SonarQube 和 Jenkins 环境所需的一切。该实现包含一个新的基本语言“Jenkins”和一个初始规则集。
当然，需求很大程度上取决于 Jenkins 的使用方式，因此并非所有实现的规则都可能对每个团队都有用，但这适用于所有类型的代码分析。规则的主要灵感来自开发人员的反馈和网上找到的一些文章。Jenkins 配置的多种方式为更多规则提供了潜力。通过这种新的质量分析方法，我们可以强制执行最佳实践，例如
-
轮询（Polling）必须死（最好从推送触发构建，而不是每隔 x 分钟轮询一次存储库）。
-
使用日志轮换器（Log Rotator）（不使用日志轮换器可能会导致控制器磁盘空间不足）。
-
使用代理/标签（Agents/Labels）（作业应定义运行位置）。
-
不要在控制器上构建（Don’t build on the controller）（在大型系统中，不要在控制器上构建）。
-
强制使用插件（Enforce plugin usage）（例如：Timestamp, Mask-Passwords）。
-
命名规范（Naming sanity）（将项目名称限制在合理的（例如，字母数字）字符集中）。
-
分析 Groovy 脚本（Analyze Groovy Scripts）（例如：防止在系统 Groovy 脚本中使用 System.exit(0)）。
除了能够控制我们想要的任何 Jenkins 实例的所有配置之外，还可以添加额外的指标，例如测量作业的数量和不同类型（Freestyle/Maven 等）以概览 Jenkins 实例的整体负载。一个更复杂的想法是测量作业甚至流水线（pipelines）的复杂性。作为代码，作业配置的理解难度会随着涉及步骤的增加而增加。一方面，脚本、条件和许多参数会负面影响可读性，特别是当存在不同位置的外部依赖项（如脚本）时。另一方面，当许多作业涉及并链式执行时，流水线也可能变得非常复杂。对我们来说，了解在哪里以及为什么创建过于复杂的流水线将非常有趣。
在可视化方面，我们依赖 SonarQube 的数据及其解释，它提供了广泛的插件。每个人都可以使用和自定义仪表板。例如，我们的中央团队有一个单独的仪表板，可以快速概览所有实例。
“增长”的 Jenkins 带来维护问题的这种情况并不新鲜。特别是当您有许多开发人员参与时，包括他们拥有创建作业和流水线本身的访问权限，像 SonarQube 插件提供的这种分析对于任何想要保持 Jenkins 良好运行的人来说都可能是有用的。定制化和标准在这种场景中起着重要作用。这篇博文肯定不是对我的插件的广告，它更多地是关于使用静态代码分析来进行 Jenkins 作业配置的疯狂想法。到目前为止，我还没有见过类似的东西，我认为这个想法可能有一些潜力。
在 2016 年 Jenkins World 大会上，参加我的“强制执行 Jenkins 最佳实践”会议，了解更多信息！
|
David 将在九月的 Jenkins World 大会上 展示更多这个概念。使用代码 |