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.