Jenkins World Speaker Highlight: Enforcing Jenkins Best Practices

This is a guest post by Jenkins World speaker David Hinske, Release Engineer at Goodgame Studios .

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, using several Jenkins instances comes in handy. 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. Problems, which where mostly caused by misconfiguration/non-usage of plugins. With “configuration as code” in mind, I took the approach to apply static code-analysis with the help of SonarQube, a platform that manages 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 a Jenkins configuration analysis can not 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 involved in 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 were defined.

Of course the needs depend strongly on the way Jenkins is being used, so not every rule implemented will be useful for every team, but this applies as well as all other code-analysis. The main inspiration for the rules were developer feedback and some articles found on the web. The different possibilities to use and configure Jenkins provides a lot of potential for many more rules. With this new approach of quality-analysis, we can enforce best practices like:

• Polling must die (Trigger a build due to pushes instead of poll the repository every x minutes)

• Use Log Rotator (Not using log rotator can result in disk space problems on the controller)

• Use agents/labels (Jobs should be defined where to run)

• Don’t build on the controller (In larger systems, don't build on the controller)

• Enforce plugin usage (For example: Timestamp, Mask-Passwords)

• Naming sanity (Limit project names to a sane (e.g. alphanumeric) character set)

• Analyze Groovy Scripts (For example: Prevent System.exit(0) in System Groovy Scripts)

Besides taking control over 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, job configuration gets harder to understand as 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 complex pipelines are being created.

For 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 talk 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!

David Hinske
Release Engineer
Goodgame Studios

This is a guest post written by Jenkins World 2016 speaker David Hinske. Leading up to the event, there will be many more blog posts from speakers giving you a sneak peak of their upcoming presentations. Like what you see? Register for Jenkins World! For 20% off, use the code JWHINMAN ​