Evolution of Star Wars Combine Development Process

That's it! We just migrated the Star Wars Combine online game to our new servers. We perform such an upgrade of hardware every 3 years roughly to cope with growth of both users and resources. We also use these upgrades as an opportunity to improve our development processes. Or maybe it is the opposite: we decide to update our development processes and we upgrade our hardware at the same time.

To make it short when we we started the Combine back in 1998, all we had as environment was a few text flat files as database, some HTML files for the website and a downloadable client developed by a single person who uploaded the compiled software on the server so that our players could download it. Back then the server was in fact just a small account on a free hosting services whose name I have long forgotten. Do not forget that we are just a bunch of volunteers working on this project during their free time and for free (or least for the sake of code).

Over time, we switched from a client/server model to a pure web-based model. Our architecture became clearer in our mind and since 2006 we were using 2 servers: one as production environment and one as development environment. Since a couple of years, we even decided to release our new features and bugfixes as weekly patches, allowing us to fix most problems on the development environment before going live.

This was already an improvement but we still had several issues regarding code quality due to our developers working in parallel and most of them having very different programming levels and background.

Now, since our recent Development Meeting of last February in Berlin, a new process has been introduced along with new tools. First we have created a virtual machine our server so that developers can work locally on their repository. That VM includes the database and the web server. When they perform some changes, all they need is to save their file and refresh the concerned VM webpage. Once they are happy with their changes, they can commit them to the development server.

On the development server, we have testers performing functional tests and providing input to the developers. On top of the functional testing, we have some unit tests that ensure that new developments will not break existing code (and features). Then, once all our tests are passed, we can proceed with our weekly release. Database schema changes are pushed and the production code is updated.

Even if this new process require more efforts from the developers such as writing unit tests and spending more time in the testing phase, the middle-term and long-term benefits of this new process will be invaluable. We are creating today a way to decrease tomorrow's bugs.

At the same time, we introduced a powerful database dedicated server to cope of the increasing database demands generated by our natural growth and increasing game complexity. Our frond-end web server can now only take care of generating webpages and will so open us the gate for future load-balancing.