Probably, nowadays no organisation that develops some kind of software non-trivial complexity has some Continuous Integration system in place. They’re great: people send their code changes to a code versioning and sharing repository like github (virtually nobody develops without them nowadays) and a process is triggered, which spins some virtual server, runs a software build command, including automated tests, moves the resulting binaries into some test server, ready to be tested and showcased.
TL;DR: go to the presentation at the end of the article 🙂
As many others, recently my team has had to move away from Travis.
The open source community has enjoyed many years of free use of their infrastructure, which allowed for tons of hours of automated testing, builds, deployment of open software. Then, following a quite common pattern, they were acquired by another company and, last November, they announced that, de-facto, they won’t support open source projects anymore.
That’s how modern capitalism works, there ain’t no such free lunch and there is no such company that actually gives things for free forever.
So, I had to migrate to a new CI. Once again...
Indeed, it was the fourth time in five years. A concerning frequency, which made me think a bit: since it’s likely that in the next five years I’ll need such a migration again (and likely not only once) can this be made independent on the particular CI, at least a little bit? And while I was at it, can I avoid to copy the same files (or slight variants of it) over and over again, once for each new github repository?
I soon discovered that I wasn’t the only one having such concerns: the very interesting mkdkr project addresses precisely that. While that project is great, unfortunately, I don’t recall Make enough to be willing to tight myself to something like that (plus other doubts explained below). Maybe I’ll go back to it in future. If you’ve tried it, I’d welcome any feedback.
So, I did something different: common scripts to reduce pretty much any Java/Maven build to essentially running the same script, plus some possible customisations (which aren’t needed in simple cases).
This is what I’m presenting in this post! Have a look at this presentation I used to explain things to my team. Please let me have any feedback!
