Continuous Integration for an MMO lets do it
This blog post is going to be the first one of a series of technical geek talk that we want to feature in this blog as well. Today, Zlatko introduces how one can improve software quality in games and how you can set up continuous integration for mobile MMO games like Gbanga.
Software quality assurance (SQA) is a crucial part of the software development process. And it obviously becomes more important the bigger the software project is. Unfortunately, as a software project’s complexity grows, so does SQA complexity. Thus, managing and structuring the SQA process is a key factor. It comes as no surprise that SQA as we know it today is an engineering discipline itself.
One of the reasons SQA nowadays is an interesting playground for (software) engineers is the fact that automation has become ubiquitous in the realm of SQA. Manual software testing is being replaced by coding automated tests at any and all levels (unit, integration, system). Moreover, testing is done continuously, day and night, by specialized software – QA people use the term continuous integration (CI) to denote this kind of SQA characteristic.
Overview of cross-platform continuous integration at Gbanga
At Gbanga, we have set up a continuous integration process and system a while ago (we use Jenkins, formerly known as Hudson). However, due to the heterogeneous technologies in our project (server-side and divers mobile environments), we didn’t take the extra effort to prepare our various projects for the process. Lately though, as our system has become increasingly complex and we saw that we’re working quality issues and bug-fixes more often. Things that worked before suddenly broke – because no one actually tested that special case Y that our ever increasing user base stumbled upon almost immediately.
Cross-platform continuous integration
So, during our last Scrum retrospective we decided: let’s do continuous integration to improve the software quality – this time for real. Thus, we reactivated the Jenkins CI server. Last year, Sara, our summer intern started to write automated tests for our website and integrate them into Jenkins (thanks Sara!). We also had some tests for scripts used to drive the Famiglia quest that were run by Jenkins. So, starting from that, we polished the existing integration during the current Scrum sprint and added other existing automated tests not yet run by Jenkins, as well. In particular, we now have the following components continuously tested:
- Website
- Back-end
- Quest scripts
There’s still quite some work to do (for instance, the tests for our mobile client software is not being run continuously yet), and we expect the CI efforts to be particularly beneficial when new functionality is added.
From a technological point of view, we depend mostly on open-source software, without which our current CI set up would not have been possible:
- Jenkins CI with (3rd-party) plugins – the report aggregation and trend charts are pretty useful
- SeleniumHQ, Selenium Grid and the respective Jenkins plugins – for the website
- JUnit, Mockito, Powermock - for our Java-based back-end components
- Apache Ant – to run some tests that need preparatory steps and to generate XML reports for (J)unit tests
- Luaunit, Lemock – for our Lua-based quest scripts
- MySQL Sandbox – to start a sandbox MySQL server that our back-end interacts with during testing
Naturally, we had to add a lot of extensions to that software so that if fitted our needs (mostly patches and [shell] scripts). But we are really happy we did not have to start from scratch – we probably would have ditched the CI idea immediately.
We will do a follow-up post to show in more detail, for instance, how we integrated Lua script testing into Jenkins. Stay tuned…