Game g = new Game();

For some time now I wanted to blog about our build process and the environment and tools I have set up for developing our multiuser browser community.

There are several subteams involved in the project :

• Web developers working on the public website and the administration interface – they are producing standard HTML, JavaScript, PHP files and images
• Flash coders implementing the actual game client and the minigames – lots of FLAs and resources, then compiled into modular SWFs
• Game backend developers extending the multiuser socket server functionality -  this is a complete Java subproject on its own

All of them are working in sub directories of a single svn repository. Maybe I will go into details about repository selection at a later date, but svn seemed the most pragmatic choice, with support and integration for several IDEs and platforms.

Having experimented with CruiseControl and hudson as continuous integration platforms before, I wanted to try out TeamCity – distributed build management sounded pretty interesting: You don’t have to checkout and build everything on one machine, but you can install remote build agents on several machines, and control them from a central server.

TeamCity is constantly watching svn for commits and triggering a new build, if it found a new revision in the repository.

The deployment script itself is your “typical” ant build script. My initial version checked out all the website and flash resources on the TeamCity machine itself, and copied everything via scp to the test server.

The script also rebuilds and deploys the Java sources to the multiuser socket server, generates javadocs and FTPs them to a webserver, and restarts the multiuser socket server.

I was not sure whether it’s possible (and makes sense) to automate the compilation of the Flash sources into SWFs, and the Flash developers were more happy to commit both FLAs and SWFs.

The problem was that copying the whole website structure was taking a long time, starting from 15 minutes for even small changes, up to more than 1 hour for bigger changes.

Thankfully, build times could be reduced drastically by installing a build agent on the test server itself. After authenticating this agent with the TeamCity server, we could checkout and build directly in a tmp directory on the test server (which was way faster, because only the modified files needed to be fetched form the repository), thereby reducing the deployment times to less than 1 minute (!).

(In retrospect, I could have spent some time making the copying via scp-target a bit more clever (and a lot faster) by copying only dirty directories, but I had no idea how to check for dirty files or directories for resources like PHP and CSS files.)

We use Jira for issue tracking, and the subversion plugin makes it easy to link repository commits to Jira tickets by adding the Jira ID to the commit comment. (We do not use any automated workflow, so the developer still has to resolve the Jira issue manually.)

So that’s about it. So far I’m pretty happy with the setup – of course, there is always room for improvement, but we are running this build process now for almost 5 months without any major hickups, and people can rely on their changes in the repository being available on the testserver within minutes.

Facing the question how to implement a basic survey functionality within a web application, I had several options:

• Implementing a new system from scratch
• Linking to an external hosted system
• Integrating an existing 3rd party survey tool into the web application

The survey features were important, but would not justify a big amount of workload, so implementing a new system from scratch (that would give enough flexibilty to support different types of question types and complex ways of analyzing results) was out of the question.

The downside of this decision was that the survey administration will not be integrated into the rest of the administration interface, but we could live with that.

Linking to an external hosted system (like SurveyMonkey or SurveyGizmo) sounded nice, but I needed to be able to control access to the survey via tokens – so that a single user could answer a certain survey only once by using a token issued to him by me.

Most of the external hosted survey tools have no problem using tokens, but I needed to dynamically generate this token within my web application right before I send the user the invitation to answer the survey, so I needed to be able to insert new tokens at runtime from my application – and could not figure out how to do that using a hosted system.

By integrating an existing solution, I would be able to have direct access to the (local) database, inserting tokens on the fly.

What I ended up doing was using the open source LimeSurvey. It’s a standard PHP/mySQL application, and seems like the defacto standard solution for surveys on the web.

LimeSurvey can serve all sorts of question types, and – most importantly – use tokens to control access to restricted, non-anonymous surveys.

These tokens are stored in DB tables named tokens_<SURVEYID> whereas <SURVEYID> is (you guessed it) the numerical ID of the survey.

Now, if you construct the SQL update statement manually, it’s pretty easy to concat the survey ID into the statement string, but since I was already using Hibernate, I wanted to refrain from hardcoding SQL in my application.

After some research, I implemented a custom Hibernate Interceptor, which allowed me to insert the surveyID into the SQL-string on the fly without any other hassle.

I will write more about how we use and trigger the survey invitations in a later post.

Finally, the project I have been working on has been announced:

Atlantis, the underwater-themed kids community , opens it’s gates for users interested in participating in the closed beta tests (for free, of course):

Here are some screenshots, to give you some impression of what’s in store:

Read more…