CI Factory - my final setup

Liam Westley — Mon, 23 Apr 2007 21:08:39 GMT

Here's the culmination of my research into CI Factory and how I'm not using it to develop my open source RapidDB libraries. This is a fairly personal setup, as it only has a single developer (me), two development machines (currently an office desktop PC and a roaming laptop) and a build server which is not publicly accessible via the Internet. An MSDN and Microsoft Partner Action Pack subscription are busy covering my software license requirements.

Summary:

Development PC 1 : Desktop, XP Pro SP2, Program Files on D: drive, C:\Projects for CI Factory tree.
Development PC 2 : Laptop, XP Pro SP2, Program Files on C: drive, C:\Projects for CI Factory tree.
Build Server : Virtual PC 2004 image, XP Pro SP2, C:\Projects for CI Factory tree.
Source code repository : www.hosted-projects.com.

By using Microsoft Virtual PC 2004 (or VPC), which is a free download now, I have the VPC disk image (6.3Gb currently) which is on a portable laptop hard drive, running over USB 2.0. When in the office this connects to my desktop, when out of the office this connects to my laptop. That way, I always have the build server available, where ever I am working. And when my build server finally settles down and I require external access, I can easily install it under Virtual Server on my main Windows Server 2003 box and setup suitable port forwarding on my broadband connection.

Both development PCs and the build server have Microsoft SQL Server 2000 Developer and Microsoft SQL Server 2005 Developer installed. To aid with unit testing, I have created aliases to the servers on all machines as NUnit-Sql2000 and NUnit-Sql2005. This ensures that whatever machine name and instance name I might have used when installing SQL Server, unit tests can use the same alias names across all machines (and please don't flame me that unit tests should not really include database access, I have my reasons).

Build server o/s and tools installation

Windows XP Professional SP2
.NET framework 1.1, .NET framework 2.0, .NET framework 3.0
Microsoft SQL Server 2000 Developer Edition, Microsoft SQL Server 2005 Developer Edition
NCover v1.5.5 (beta)
SubVersion 1.4.3, TortoiseSVN 1.4.3
.NET Framework 1.1 SDK, .NET Framework 2.0 SDK [blog update, 6 June 2007]

CI Factory installation on VPC build server image

.\Install Scripts\Arguments.xml;

Change ProjectName; testproject.
Change the portname number (really important for multiple installations!)
Email details; VPC-Build, vpc.build@yourdomain.co.uk
Developer lists; your.name@yourdomain.co.uk
SVN URI Root; https://svn1.hosted-projects.com/youraccountname
SVN URI ProjectName, Shared Repo; ProjectName" value="${SVN.URI.Root}/${ProjectName}"
SVN.WebRepoURL; https://svn1.hosted-projects.com/youraccountname/${ProjectName}
SVN.Credentials.SafeStorage; true
SVN.Username / SVN.Password; <set to your username/password>

\Packages;

Install NCover 1.5.5 Beta to prog files; C:\Program Files\NCover
Install SubVersion 1.4.3 to prog files; C:\Program Files\Subversion
(optional) Install TortoiseSVN 1.4.3 to prog files; C:\Program Files\TortoiseSVN

CI Factory Installation

Create repository/project for testproject in SubVersion, edit ACL list to include user permissions RW.
Run C:\Tools\CI Factory\run.bat to install.
After install Visual Studio will not start as it doesn't exist on the build server; instead use
   Notepad to edit c:\Projects\testproject\Current\Build\Main.build.xml
   --> look for warnings about first call/last call and move (as in Jay Flower screencast)
   --> (SourceModificationReport.PublishOldSource to first item)
   --> (SourceModificationReport.PublishNewSource to last item)
Commit, Main.build.xml to SubVersion.
Run C:\Projects\testproject\Current\Build\Packages\CSDiff\bin\CSDiff.exe once to store path to CSDiff in registry (used in later scripts).

Post installation configuration; c:\Projects\testproject\Current\Build\ccnetproject.xml

Locate <!ENTITY email line (at top of file)
Edit the from attribute to a suitable 'from' address
Edit the mailhost attribute to by your SMTP server
For authenticated logins add the mailhostUsername and mailhostPassword attributes and enter the login and password used to send e-mails.

Afterwards, it should look something like;
<!ENTITY email '<email from="testproject.build@yourdomain.co.uk" mailhost="mail.yourdomain.co.uk" mailhostUsername="testproject.build@yourdomain.co.uk" mailhostPassword="testprojectbuild" includeDetails="true">

Developer PC 2 - C:\Program Files (99% of users)

You can just check out the tree from SubVersion to C:\Projects\testproject and run C:\Projects\testproject\Current\Build\OpenSolution.bat to load the project into Visual Studio 2005. If you want to run unit tests you will need to have installed the appropriate tools (NUnit for myself, or feel free to use MbUnit which comes with CI Factory).

Developer PC 1 - D:\Program Files

Check out the tree from SubVersion to C:\Projects\testproject.

Copy C:\Projects\testproject\Current\Build\OpenSolution.bat to C:\Projects\testproject\Current\Build\OpenSolutionVSOnD.bat
Edit OpenSolutionVSOnD.bat in Notepad, and edit the path C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat to be on the D: drive.
Repeat with C:\Projects\testproject\Current\Product\OpenSolution.bat.

Adding your projects

Now you continue with the normal CI Factory process of adding your existing projects into C:\projects\testproject\Current\Product\Production as detailed in the Jay Flowers/CI Factory screen cast.

Conclusion

For those thinking that all this sounds like a whole heap of work to 'reproduce' your existing setup, this is really is not the case. I cannot tell you the relief to have CruiseControl.NET setup for me automatically and have it branching versions seamlessly in the background. It also encourages you down the unit testing path which is not a bad thing at all (although I may be breaking it with database reliant testing).

I have also been impressed by the range of default packages installed by CI Factory. This provides an immediate wake up call to how you might improve the quality of your software by using automated tools, instead of just hoping you have written reliable code that you have tested properly. I have yet to use all the default packages properly, but then, even programmers I know who have in depth experience of Test Driven Development (TDD) and CI have found new tools that CI Factory includes, such as Simian.

Technorati tags: ci factory, Continuous Integration

Update log
6 June 2007 : Updated to include installation of .NET Framework SDK to prevent Unable to load DLL 'svn_client-1' error in build log (as in CI Factory FAQ, here).

RapidDB

CI Factory - my final setup

RapidDB development system