I am CI and so can you
Hello, this is Piet Bronders and I’m here with some technobabble to discuss part of our technological pipeline. You might know me from such previous blog-posts as “Our FOSS pipeline – Backgrounds from draft to import” and Open source game appreciation month: Godot engine.
Both posts that were more on the development/technological side and, to no one’s surprise, they let me come out of my dank coding basement to entertain you, folks, once again.
As the main developer of ‘Trip the Ark Fantastic’, I am constantly bugged by all members of the development team for updates on the game and tasked with supplying them with the latest builds and bug fixes. Evidently, I can’t be bothered to manually export the game every time I fix a bug or add a feature, therefore it would be a blessing to have someone or something take this menial task of my hands…
Such a system is, of course, well-known (and admired) by software engineers everywhere. The acronym “CI/CD“, which stands for Continuous Integration/Continuous Delivery, is a broad term for any technology that allows for automatically exporting and building your software, including games, and deploying them to a platform of your choice. However, before delving too deep ( I aim to make this blog-post at least a little bit layman-friendly) there is the concept of “version control“.
Version Control – Git
Different programmers working on the same code is a recipe for disaster. Programmers add features that other coders have already implemented in their own version of the code and merging both code-bases is a horrendous affair. But… what if there was a big outside entity that kept track of everyone’s progress and took care not to accept work of someone who is writing bad code or code that is too incompatible with the rest? This is exactly the purpose of version control!
There’s more to the story than this, but I’m keeping it deliberately low-level as not to bloat this article with the technical nitty-gritty.
Evidently, most programmers use some sort of version control algorithm to keep track of the changes in their code-base, and GIT has, over time, become the de-facto industry standard. Each programmer has its own version of the source code and periodically (whenever he/she is done with a feature or bug fix) “commits” a change to the master branch. A branch is, as the same would suggest, a constantly growing sequence of coding commits on which the programmers build their empire.
CI/CD – Gitlab Runners
Now, each of these “commits” can be important and fix an essential bug or add some super-requested feature. Therefore, it is imperative that the latest version of the game is always available for download and deployed on whatever aggregate platform is wanted.
In our case, we use godot-ci, a CI/CD template that can be used to (you guessed it) automatically export Godot games!
In layman’s terms this template is run on Gitlab’s server each time when a programmer of the Ark team commits some changes to the master branch and it “emulates/fakes” a Linux computer that has Godot installed on it. It’s rather well-documented and we love it.
Here’s someone explaining it much better than I could ever dream of:
That takes care of the CI-bit, but there’s isn’t any delivery yet! In the case of “Trip the Ark Fantastic”, we haven’t released yet, so you might have to wait just a little while longer…
Well… that will be all… I hope I haven’t lost anyone halfway through my explanation and for those adventurous ones among you to attempt CI themselves, I say: The initial hurdle is more than worth it!