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.

Deployment

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.