We use and really like Jenkins for our Continuous Integration. It’s been around forever and has lots of capabilities as a result. Yet in spite of its maturity, Jenkins lacks a really great build monitor (either built-in or as a plugin).

So, during a recent Hackathon, a few of us decided to make a new build monitor for Jenkins. We wanted it to be informative, big-screen friendly, and beautiful (yes, beautiful). Here’s what we ended up making:

We call it Z-mon. It’s distributed as a Jenkins plugin and you can find the code for it on gitHub.

Making a Build Monitor

The Challenge: TMI (Too Much Information)

Build monitors present an interesting UX challenge. Like with most glance-able interfaces, the tough part with build monitors isn’t what to show, it’s what to omit. This is due to the fact that CI pipelines can get quite complex:

  1. Multiple roles: different jobs have different purposes (builds, deploys, tests, etc)
  2. Dependencies: jobs typically depend on other jobs and they may run sequentially or in parallel
  3. Sheer volume: it’s not unusual for a CI system to manage tens if not hundreds of jobs

Though it’s tempting to cram all of this information into a build monitor, that strategy is unlikely to yield positive results. Fire-hosing people with data will probably not help them quickly decide whether an action is required. By the way, probably the most common action that arises from checking the build monitor is visiting Jenkins for more information, which is perfectly fine.

It’s also important to realize that build monitors can serve different audiences (devs, release management, devOps, etc.). Each group may be looking for different types of information, so it’s probably unrealistic to create a single build monitor which would work for all.

The Solution: Simplify, Simplify, Simplify

So, how did we distill all of this CI data into an easily digestible, big monitor compliant visualization? We focused on helping developers answer three key questions:

  1. How is the health of the current work stream (i.e. the iteration I’m currently working on)?
  2. How is the health of next release (across multiple teams)?
  3. How is the health of overall code base?

To do that, we organized the information displayed on a screen into three different areas:

At the top, we display a simplified version of the current iteration pipeline. It includes just three jobs: build, deploy, and tests. On the bottom left corner, we display a single job representing the current release. Finally, the bottom right corner shows a single job representing the health of the overall code base.

For each job we display the current status (using red, green, or gray) and duration as well as the status and recency of the previous run. For all test jobs (which includes tests, mature, and regression) we also show a % of failed tests next to it.

And there you have it: five jobs to represent your entire CI. Is this reasonable? Certainly not for everyone, though it seems to address our needs pretty well.

By the way, I should note that Z-mon allows you to decide which specific jobs to show in these five slots. So, even though we have opinions about which jobs should be shown where, you can change that if you like.

What About the Eye Candy?

Functionality is important, but who wants to stare at an ugly build monitor all day? With that in mind, we tried to pretty it up a bit. Using some CSS3 goodness, we added a bit of polish to the visual elements. My favorite element is a spinner for currently executing jobs, heavily influenced by this wonderful tutorial from CSS ninja Chris Coyier.

Final Thought

I hope you find this tool useful. If you have suggestions or ideas on how to change it, please drop me a note at @AlexTatiyants.

P.S. Huge thanks to Steve Moyer and Aslan Brooke for working on this project with me. You guys rock.

You may also like:

Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!

This post got 22 comments so far. Care to add yours?

  1. I like the look of that a lot. I don’t use Jenkins, but I’m wondering in general how hard a problem it would be to put the same front-end on multiple CI tools…? Would that be a fairly straightforward extension of what you’ve done here?

    • Alex Tatiyants says:

      Thanks Erik, glad you like it. The plugin has two components: the HTML template (using Jelly) and the Java code which interfaces with Jenkins API to produce various metrics required. While the template would probably be relatively easy to tweak for other CI systems, back-end code is not really portable.

      By the way, did you have a specific CI system in mind to adopt this for?

  2. Dave Stewart says:

    This looks really nice, and I’d love to use it. However, it seems to be missing some information – specifically how to install and configure it. Is this a manual bit – rename a zip to .jpi, install using advanced, and hand edit the config?

    • Alex Tatiyants says:

      Hi Dave, you’re right, all we have on gitHub right now is the source. As soon as I get a bit of time, I’ll create an hpi file for it.

      • Dave Stewart says:

        So, I cloned this, compiled it, and installed it in Jenkins. Perhaps I’m missing something obvious, however, I can’t seem to find it in Jenkins, other than in the installed plugins list. I also can’t seem to find any configuration settings.

        Am I doing something horribly wrong?

        • Dave Stewart says:

          Nevermind… found the setup, config, etc. For the benefit of anyone else reading this, you need to configure a new view from the dashboard. Thanks for this Alex, it’s really quite nice! You should put it up on the Jenkins plugins site.

  3. Sebastian says:

    Hi Alex,

    looks very nice,
    but i’m not sure if i got this right:

    I can build it by myself and add it to my jenkins yet,
    or do i have to wait for your hpi file?

    Sorry, but the only experience with jenkins plugins i made,
    was installing them via the jenkins gui…

  4. Atomicus says:

    Hi guys, can anyone provide me with working hpi? I’ve tried to build one with nebeans but it fails to install (no z-mon plugin on instlled plugins list)

    • Atomicus says:

      That’s my error:
      SEVERE: Failed Loading plugin z-mon
      java.io.IOException: Dependency claim (2.2) doesn’t exist
      at hudson.PluginWrapper.resolvePluginDependencies(PluginWrapper.java:479)
      at hudson.PluginManager$2$1$1.run(PluginManager.java:332)
      at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
      at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
      at jenkins.model.Jenkins$7.runTask(Jenkins.java:888)
      at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
      at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
      at java.lang.Thread.run(Thread.java:679)
      2013-06-26 13:08:31 hudson.plugins.greenballs.PluginImpl start

  5. Samar says:

    I am using jenkins 1.4. I build hpi file with mvn and uploaded that with Jenkins GUI.
    I am configuring the new Dashboard after that but not able to find z-mon plugin to configure.

    Is there any step I am missing in this?

    • Dave Stewart says:

      Samar, it doesn’t show up in the usual configure location. Look in the tabs on your main Jenkins page, there should be a new one called Status Monitor. To configure it, take the URL for the status monitor and add /configure to the end of it – so mine, for instance, looks like so:

      http://jenkins:8080/view/Status%20Monitor/configure

      • Samar says:

        Dave,
        There was no new tab created after adding that hpi file. I m on jenkins 4 is that a issue?
        I tried to access Status Monitor url direclty also but getting 404 as tab never exists

  6. Mishal says:

    I added the hpi file using adv option in jenkins, however I can not find the plug in. What is the name of the plug-in? z-mon? I cant find it for some reason.

  7. Andrew Sumner says:

    Could someone place the hpi file on gitHub for those of us that are unable to build it, but would like to try it.

  8. Vanetta Floyd says:

    Hi Everyone….Still looking for the hpi. Can someone let me know where I can get one? I am unable to build the hpi.

  9. Edward says:

    Same issues here. No HPI on Git Hub, had to build manually. No read me. Build tests fail using current Jenkins version (from pom.xml). mvn install -DskipTests will bypass tests and build HPI. Wasted an hour on this. Address the issues or take it off Git. Shame because it looks nice.

  10. Rodrigo Dapper says:

    Hi

    Dear, could you send the .hpi to test in my Jenkins projects?

    Tks!

  11. Rodrigo Dapper says:

    Dear, i already create the hpi, imported, but how to use now?

    Tks in advance

  12. Thomas says:

    Very, very beautiful. It would be nice if the configuration is not limited to explicit five projects. In most cases Jenkins handles much more projects and the view could display more if the configuration would allow it.

    I can also say that the tests currently fail but the plugin seems to correctly work when Maven tests are skipped.