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
mainormasterbuild 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.
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. |
