Third Time Around

As I move between clients, I’m building a playbook of tools I like to have/make in order to help manage the environment.

While I remember how a tool needs to be made, each environment calls for a different implementation.

I’ve recently rebuilt a classic tool, and I was surprised how I approached it differently.

The Jenkins Build Visualizer

The original design for this tool used the Jenkins API to monitor multi-branch builds to build a wall board showing each branch’s success/failure status.

The Jenkins wallboard plugin didn’t offer this view for multi branch builds, and indeed the problem with multi branch builds is more complex anyway. We have a different opinion of the current state of the world based on:

  • Is the main or master build green – that’s the most important thing
  • What other branches are there?
  • Are there too many other branches going on?
  • Are the other branches green/red?

It might not matter if a feature branch isn’t green, as we may deliberately push to that branch in order to get realistic test feedback on our work. It being red may be a natural feedback loop.

It probably does matter if there are too many feature branches in a given repo, or even across repos, as this would indicate some sort of proliferation of incomplete work.

The idea is to look at the colour and complexity of a diagram which has a region for each build and a sub-region for each branch. To make it clearer whether the main branch is green, that branch gets more of the area for its parent repository added to it.

A D3 Treemap does a good job of this visualization.


I’ve built such a tool as a docker container, deployed to either a Kubernetes cluster, or to an ECS/Fargate cluster.

For something we may occasionally look at, or maybe run on a wallboard (now we’re remote, that’s less important), paying for the (even cheap) constant machine time of such a visualization might seem a little expensive, but it’s not a very busy service, so only needs CPU when someone’s fetching the summary of the Jenkins branches/pulling the html.

New Client New Approach

The key thing about this tool has been that it was a Jenkins visualizer. But actually, it should really be a build visualizer. The depedency on Jenkins is secondary.

In my current client there are two considerations:

  • Unnecessary cost – even a few pounds a month for a tool occasionally used is a potential down side (though when you cost up the solution below, you may consider it equivalent)
  • Cost of bringing on Jenkins

To have a Jenkins box for all builds could be quite an investment, both in terms of the machine hours for a beefy enough machine, and also for the maintenance costs in terms of building and patching a Jenkins server.

So we decided to use AWS CodeBuild for our builds, which is beautifully serverless. It’s not quite as nice as Jenkins in a few minor respects, but it’s pretty good.

Out of the box, CodeBuild can register itself with a GitHub repo, building on webhook updates, building every commit that gets pushed (i.e. doing multi-branch builds) and providing GitHub’s build status API with feedback on whether each commit is ok.

The GitHub Visualizer Lambda

So, a new environment resulted in a new design. Interestingly, I wish I’d considered this one in previous environments because it’s sort of better.

  • The whole service is an AWS Lambda… even the static HTML!!! (you can serve static content from a Lambda if you really want to… weird though that may seem)
  • So we only pay for the time we use it, which is a few clicks a day
  • The service uses the GitHub API to find all repos, all branches and all their commit build statuses – this is relatively easy to do, and would have been potentially easier, had I considered using Octokit to build the code

It took a few hours to put together, which was itself part of an effort to provide some simple AWS Lambda boilerplate code for templating other projects, and it works a treat.

I like this version better than its predecessors, but perhaps next time I need one, I’ll come up with something even better.

Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: Third Time Around

Opinions expressed by Java Code Geeks contributors are their own.

Ashley Frieze

Software developer, stand-up comedian, musician, writer, jolly big cheer-monkey, skeptical thinker, Doctor Who fan, lover of fine sounds
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments
Back to top button