I've just set up TeamCity using SQL Server DB and an instance of our webapp running on Tomcat all on the same Windows VM.
- The TeamCity web server runs on
Tomcat itself, and uses a good deal
of memory (like any Tomcat app).
- The TeamCity Build agents, since they
compile, use a ton of memory.
- SQL Server is a memory hog.
JetBrains mentions that Build agents should not be running on the same server as the web server optimally. I'd suggest that the database be separated as well (onto a physical box, not just a VM), so that the CI setup itself uses 3 systems (TeamCity web server, TeamCity database, TeamCity build agent). If your builds take more than a few minutes, I'd add another build agent server so that developers aren't queued up on commits, especially if you are using TeamCity's remote run/personal build feature from IDEA or Eclipse.
I wouldn't have a problem putting the SVN server on the same system as the TeamCity web server.
Keep in mind that compiling is an activity that is typically CPU-bound or disk access-bound. Build Agents will benefit from being separated onto separate CPUs and/or disks. However, being on separate VMs that are sharing disks and CPUs may be more wasteful than helpful due to the overhead of multiple VMs.
Have you seen/considered Hudson ?
https://hudson.dev.java.net/
If you're building your .NET project with NAnt for example, it has a plugin that may
allow it to serve your needs.
It integrates with most SCM systems, bug trackers, etc. and is extremely extensible.
In my experience, Hudson has been superior to Cruise* on most fronts. Anytime
I've needed to connect it to something else, someone has already created a plugin.
It's easy to configure, has plugins for most aspects of current software engineering
practices. It includes Winstone and can run completely standalone, or within any
Java App/Servlet container. I've had zero issues running it in Tomcat and Glassfish
for example.
Here's the list of its current plugins
http://wiki.hudson-ci.org/display/HUDSON/Plugins
It seems to meet your goals
* Needs to be able to live on the same server as our SCM system (SVN)
no problem
* The Server is (unfortunately) an XP Pro Machine.
I have not personally had any issues running the standalone variant on Win XP,
haven't tried it on other servers/containers on XP though.
* Needs to handle .NET builds.
Assuming NAnt meets your needs or you're already using it, should be good to go here
in short order
* Would like to have some profiling capability. Or the ability to add at a later date.
If existing plugins can't accommodate your needs, plugin framework is excellent and you
could roll your own.
* Budget, free preferred.
Free and actively developed/maintained
* While we're more than capable, configuration would be preferred to be easy.
Config is quick and easy.
* Our SVN web front end is using apache. Would like the CI's front end to do the same, but can deal with IIS otherwise.
This may be a sticking point, but if the included Winstone won't work, it needs an App/Servlet container.
I've converted a few projects to Hudson which were using CruiseControl, and haven't looked back. I also push it for new projects whenever possible.
Regards
Best Answer
Cruise Control.net (ccnet) does everything you are looking for. Its pretty easy to use, just make sure if you are going to run it as a service, you give it an account and don't make it run as network service, that way you can give it rights on intranet boxes and have it do xcopy deploys.
It has all kinds of email modes, on failure, on all, on fix after failure, and many many more.