DevOps

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.

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
Subscribe
Notify of
guest

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

0 Comments
Inline Feedbacks
View all comments
Back to top button