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.
Here's what I did, for stamping the AssemblyFileVersion attribute.
Removed the AssemblyFileVersion from AssemblyInfo.cs
Add a new, empty, file called AssemblyFileInfo.cs to the project.
Install the MSBuild community tasks toolset on the hudson build machine or as a NuGet dependency in your project.
Edit the project (csproj) file , it's just an msbuild file, and add the following.
Somewhere there'll be a <PropertyGroup>
stating the version. Change that so it reads e.g.
<Major>1</Major>
<Minor>0</Minor>
<!--Hudson sets BUILD_NUMBER and SVN_REVISION -->
<Build>$(BUILD_NUMBER)</Build>
<Revision>$(SVN_REVISION)</Revision>
Hudson provides those env variables you see there when the project is built on hudson (assuming it's fetched from subversion).
At the bottom of the project file, add
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')" />
<Target Name="BeforeBuild" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')">
<Message Text="Version: $(Major).$(Minor).$(Build).$(Revision)" />
<AssemblyInfo CodeLanguage="CS" OutputFile="AssemblyFileInfo.cs" AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)" AssemblyConfiguration="$(Configuration)" Condition="$(Revision) != '' " />
</Target>
This uses the MSBuildCommunityTasks to generate the AssemblyFileVersion.cs to include an AssemblyFileVersion attribute before the project is built. You could do this for any/all of the version attributes if you want.
The result is, whenever you issue a hudson build, the resulting assembly gets an AssemblyFileVersion of 1.0.HUDSON_BUILD_NR.SVN_REVISION e.g. 1.0.6.2632 , which means the 6'th build # in hudson, buit from the subversion revision 2632.
Best Answer
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
no problem
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.
Assuming NAnt meets your needs or you're already using it, should be good to go here in short order
If existing plugins can't accommodate your needs, plugin framework is excellent and you could roll your own.
Free and actively developed/maintained
Config is quick and easy.
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