[In this reprinted #altdevblogaday-opinion piece, Blitz Game Studios' technical manager Lee Winder offers advice on improving your Continuous Integration process to get what you want out of your CI server.] Having a Continuous Integration server running is one of the most useful and powerful tools a development team can use. Constantly checking the state of the code, building assets which might otherwise take hours and generating stats on build quality are all really useful things to have running in the background hour after hour and day after day. But if it's not done with care, a CI process, while still providing some useful information, will stop being an important part of a development teams tool set. The main problems usually stem from a single CI step taking to long. For example, it might take hours to build all the game assets or it might take 40 minutes to build a single configuration. You might have additional build steps (like copying files to a network drive) which can take quite a while if you're dealing with gigabytes of data. As soon as a CI step takes to long, you lose the main benefit – the fast turnaround of information. For example, when we first start a project, our simple CI process will consist of the following steps:
- Detect modification
- Build code
- Build game assets
- Copy to network drive
- E-mail developers (who's mailed depends on success or failure)
- Continuous Build – We need the process to constantly compile the source, all configs, all platforms. This is so we can detect any compile errors quickly without having to build everything manually.
- 'Designer' Builds – Creating an executable the designers, artists, animators etc. can get with the latest code changes. Ideally one they can request as required and one that is built as quickly as possible.
- Full builds – A complete build of the game including executable and all in-game assets along with anything else needed to run the game.
- QA Builds – QA could use the full build if needed, but this is an additional step which packages the build as it would be submitted allowing a better QA pass (DVD emulation, submission content etc.).
- It would take every member of the team far to long to rebuild all the assets themselves
- When a build gets out of sync with the assets, developers need a quick way to get everything back on track
- When testing the build it needs to have been built on an independent build machine
In our case using CCTray allows us to do this very easily, so a new build can be requested by anyone (including QA) at any point of the day without any input from a programmer, allowing them to concentrate on making the game rather than just enabling others. Technically, anyone in the company could request and get a new build (very useful for getting demo builds together without getting the team involved) but I've not seen that happen yet. What I Haven't Covered One major thing I've not covered here: self-testing builds. This can range from simple unit tests running after every build to a scripted run through of the game after every full integration. The scope of this will very much depend on the size of the game and the time you have available to add them. Since this is a big topic in it's own right, I've left that for another time. Conclusion So, by simply reviewing what we actually want to get out of the Continuous Integration process we're able to streamline it down to be much faster and much more useful. Complete integrations still happen (and happen when needed) but the common information needed by the team is generated quickly and allows teams to get short turn-around from the CI machine throughout the day. I'd be very interested to know what other uses people are getting from their CI processes and how they are still making sure the speed and quick turnaround is happening all the time. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]