Hey there, my name is David Hinske and I work at Goodgame Studios (GGS), a game development company in Hamburg, Germany. As Release Engineer in a company with several development teams, it comes in handy using several Jenkins instances. While this approach works fine in our company and gives the developers a lot of freedom, we came across some long-term problems concerning maintenance and standards. These problems were mostly caused by misconfiguration or non-use of plugins. With “configuration as code” in mind, I took the approach to apply static code analysis with the help of SonarQube, a platform to manage code quality, for all of our Jenkins job configurations.

As a small centralized team, we were looking for an easy way to control the health of our growing Jenkins infrastructure. With considering “configuration as code“, I developed a simple extension of SonarQube, to manage the quality and usage of all spawned Jenkins instances. The given SonarQube features (like customized rules/metrics, quality profiles and dashboards) allow us and the development teams to analyze and measure the quality of all created jobs in our company. Even though Jenkins configuration analysis cannot cover all SonarQube’s axes of code quality, I think there is still potential for conventions/standards, duplications, complexity, potential bugs (misconfiguration) and design and architecture.

The results of this analysis can be used by all people working with Jenkins. To achieve this, I developed a simple extension of SonarQube, containing everything which is needed to hook up our SonarQube with our Jenkins environment. The implementation contains a new basic-language “Jenkins“ and an initial set of rules.

Of course the needs depend strongly on the way Jenkins is being used, so not every rule implemented might be useful for every team, but this applies to all types of code analysis. The main inspirations for the rules were developer feedback and some articles found in the web. The different ways Jenkins can be configured provides the potential for many more rules. With this new approach of quality analysis, we can enforce best practices like:

Besides taking control of all configuration of any Jenkins instance we want, there is also room for additional metrics, like measuring the amount and different types of jobs (Freestyle/Maven etc…​) to get an overview about the general load of the Jenkins instance. A more sophisticated idea is to measure complexity of jobs and even pipelines. As code, jobs configuration gets harder to understand the more steps are involved. On the one hand scripts, conditions and many parameters can negatively influence the readability, especially if you have external dependencies (like scripts) in different locations. On the other hand, pipelines can also grow very complex when many jobs are involved and chained for execution. It will be very interesting for us to see where and why too complex pipelines are being created.

On visualization we rely on the data and its interpretation of SonarQube, which offers a big bandwidth of widgets. Everybody can use and customize the dashboards. Our centralized team for example has a separate dashboard where we can get a quick overview over all instances.

The problem of "growing" Jenkins with maintenance problems is not new. Especially when you have many developers involved, including with the access to create jobs and pipelines themselves, an analysis like this SonarQube plugin provides can be useful for anyone who wants to keep their Jenkins in shape. Customization and standards are playing a big role in this scenario. This blog post surely is not an advertisement for my developed plugin, it is more about the crazy idea of using static code analysis for Jenkins job configuration. I haven’t seen anything like it so far and I feel that there might be some potential behind this idea.

Join me at my Enforcing Jenkins Best Practices session at the 2016 Jenkins World to hear more!