Yesterday and today I spent the better part of the day setting up a Cruise Control server for my dev team to use. This is my second attempt at this task. On the first attempt I made the mistake of trying to piece together our nAnt build files so that they could be called by CCNet and in the end I wouldn’t have to do much work. Well, that was a gong show and by the end of my last release cycle I had quit using CCNet.
This attempt will be different (I hope). One of my biggest concerns during the first attempt was that I didn’t mess with the versioning system that we were using. Our nAnt scripts were setting the software versions to a pattern like this:
The first two sections of the version number were static for each release cycle of the software. The last two section change based on month, day and build attempt. My worry was that, by changing the way the last two sections were generated, I would be doing something awful. The fact is, as long as I change the number sequence between development cycles (i.e. going from version 5.0.x.x to 5.1.x.x) I am preserving the version sequencing. Once I got this all figured out in my puny little head (okay, it’s a big, freakish watermelon with a puny brain) I decide that I would attack the CCNet implementation by starting over from scratch on how we do things when building.
So far I’ve changed our process from nAnt to CCNet for source code gets and cleanup, versioning and build task sequencing. All of this has gone fairly smoothly and I’ve actually had a couple of revelations other than the versioning thing. The way the previous person had configured nAnt was to get the latest version of the source code down into a working folder and then copy the necessary web projects up to the inetpub\wwwroot folder. I’m not sure the exact reason for doing this, but it did allow us to just open the VS IDE and have the solution load up and be in a runable state. In the interest of trying to build multiple different major versions of the application on the same build server, I did away with this and just downloaded the latest version of the source code to a working directory for that development cycle. I can no longer fire up the solution in the IDE, but if I have to do that I should be using a dev box and not the build box. So far this is working great and I’m looking to expand on the idea by moving more of the referenced items into these development cycle areas.
I have run into one problem in this process. The environment that I’m working in has our development/testing servers, including the build boxes, in separate domains from the main company domain (lets call it the DevDom). This is fine until you add in the fact that the source code must reside on a server that is in the company domain (lets call it ProdDom). My CCNet build server has to talk from the DevDom domain to the ProdDom domain to pull down the latest version of the source code. When I’m logged in interactively on the build server and I’ve provided the correct credentials to manually establish a connection to the share holding the source code I can manually start the CCNet server (not the service) and everything runs smoothly. When I start the service all I get is an error saying that the sourcesafe.ini (yes I’m using VSS) file doesn’t exist because it can’t authenticate to the server and share that it resides on. So whats a good looking lad like me to do?
I can beg with the networking folks to give permissions to the VSS location for my service account, but I can almost guarantee that won’t happen. Does anyone have any ideas?
I’m the Igloo Coder and Continuous Integration isn’t all that continuous if I have to kick the build server off every time someone checks something in.
Update: The build server is not in a domain it is in a workgroup all by itself (the workgroup name is the same as the server name) and I have no ability to log onto this server with any of the ProdDom user accounts. Instead I use accounts that are local to the build server. I am a full administrator on that server though and can add and modify any accounts that I want if they are needed.