Continuous Integration Server

Rather than trying to address all the issues with a "straight forward" OpenSourceWebCatProject release, an alternative is to set up a local server for "continuous integration" (CI). For those who don't know what CI is, it is basically a variation on the idea of an automated daily build.

We could set up a separate Web-CAT development server with a full CVS archive of the source, completely set up to run Web-CAT. This server would run a "test" version of Web-CAT off of an independent copy of the MySQL database so that it wouldn't interfere with any users trying out the "real thing".

Then, the CVS setup would be tweaked so that after every group of CVS check-ins (say, after 30 seconds of no CVS activity), an automated build process would kick in that would: shut down the test Web-CAT application, rebuild using the latest CVS changes, and restart the test Web-CAT application.

This would allow others to work on the source code, make changes, and try out new things while side-stepping all of the issues related to licensing of commercial products or devising a robust installation sequence for the necessary underpinnings. Plus, by not allowing anonymous CVS access, we could put off the issue of how best to deal with sensitive information in the CVS archive.

Update: I have procured a new machine named web-cat2.cs.vt.edu. This machine is currently being configured as a linux workstation and will be set up to manage our CVS archive and to operate as a continous integration server. Plus, it will also serve as a "Unix" grading environment for processing assignments that expect to run on that OS.