Recently, I had the opportunity to create a prototype for an in-house technology radar, based on the build-your-own-radar (BYOR) open-source implementation from Thoughtworks. I thought I’d write a post explaining the infrastructural side of the implementation, as I found it quite interesting – and I’ll end it with an open question.
We wanted various people to be able to add or modify entries of the radar, so a small web frontend was developed in Elm. I tried a few different open-source CMS variants, but found nothing that worked for my needs. When making changes to the entries, the continuous integration pipelines will take care of the rest and provide an updated visualization of the radar.
The whole project is realized within a single git repository involving various branches and CI pipelines. Here’s a quick overview of each:
- infrastructure: Contains Dockerfiles for the different images being used. Whenever one of them is changed, the CI pipeline builds the images and pushes them to the registry. Currently, there are two images: one for an nginx configuration used to serve the radar entries and the Elm frontend, and one used to build the Elm frontend.
- elm: Contains the source code for the Elm frontend. The corresponding pipeline builds the Elm code and deploys the result.
- data: Contains the radar entries and a small CSV converter. The pipeline runs the converter program to generate a CSV and deploy it.
How does it work in conjunction? You define the underlying docker infrastructure in the corresponding branch and get it pushed to the registry. The Elm frontend is written such that when you make a change to an entry it uses the Gitlab API in order to make a commit to the data branch. Hence, a change triggers the pipeline, which results in an updated CSV being served to the BYOR container, which generates the interactive radar visualization, which is in turn embedded via an iframe in the Elm frontend. The round trip takes about a minute, so it’s not really an instant update of the radar, but we just wanted to have a single entry point for viewing and editing it and not invest a lot of time. Speaking of time, it took less than 4 days to get all of this working, including a day wasted on various CMS experiments.
As promised, I’m going to end with an open-ended question: Given this setup, which involves the interaction of various branches, pipelines, deployments and automated commits, what is a good way to document / visualize all of this? Let me know in the comments if you did something similar or have an answer to my question.