For the past several months, we've been using a build server on our project for continuous integration. I've been involved with teams, in the past, that used build servers, but this particular setup has proved to to be a real asset and the experience of using it day-to-day has been a pleasure.
I'd like to share how we built the server. I'll make several posts over the next few days to address the various parts that work together. Along the way, I'll discuss version control (subversion in our case), Cruise Control .Net, NAnt and StatSvn.
What We're Trying to Accomplish
Why would you want a build server, anyway? The primary benefits of a build server are continuous integration and automation. Let's say you have a team of five and all are working on the same project. Each has a piece of the application that they're working on. As they develop, they test the code they're responsible for. Who, though, is responsible for making sure that all the pieces work together? The reality is that at any given time each developer's machine has a unique version of the application that's different everyone else's. The purpose of the build server is to periodically take the code that exists in the source repository and process is to verify the code all works together. In other words, the health of the code (how well all the parts integrate) is always known.
There are many functions the build server can perform. It can do a compile, execute test suites, generate an installer or even a CD image. Crucial to the whole process is source control, so let's look at getting started with Subversion.
Subversion
All source code repositories have their own take on how best to solve the problem of keeping up with all the changes made to to the code base. Some require the developer to lock a file while it's being worked on, while others allow changes to be made by anyone at any time. Subversion falls into the latter category. Basically, a developer grabs a snapshot of the current version in the repository, makes his changes and then pushes them back up. Committing of changes happens in a transaction so the commits are always stable. Subversion takes the version being committed and merges it into the current version in the repository. This means that manual merging is greatly reduced. On the occasions when Subversion can't figure out how to merge the changes, the developer is notified and is give an opportunity to manually do the merge.
Installation
You can obtain the subversion installer here. I downloaded the installer, svn-1.4.6-setup.exe, and executed it taking all the defaults. At this point, all the binaries are installed on your system, but Subversion hasn't been configured to run as a Windows Service. To set it up to run this way, execute the following from a command line.
C:\>sc create svn binPath= "\"c:\program files\subversion\bin\svnserve.exe\" --service -r c:\repos" DisplayName= "Subversion Server" depend= Tcpip
This command will create a Windows service named "Subversion Server" that runs svnserve.exe when it's started.
Subversion Client
Regarding a client that you'll use for interacting with your Subversion server, you'll need to decide whether you prefer to have the client integrated into Visual Studio or not. If having everything available within the IDE is you bent, then you'll likely prefer something like AnkhSVN. Personally, I'd rather do my source repository work outside the IDE and prefer to use TortoiseSVN which installs as a shell extension. Either way, you'll need to create a repository and then connect to it with your client.
Creating and Configuring a Repository
On the machine on which the Subversion service is running, create a folder in which you'll be storing your code repository. Then, go to a command line and execute the following.
svnadmin create c:\path-to-repos
This will create a repository for you in the directory you created. Now, we need to configure access to the repository. Go to the folder you created, before, and you'll find that three files have been created there. First, open the svnserve file. All the lines in the file are currently commented out. You'll need to modify at lease three of these lines. Find the line that contains "anon-access". This line controls what access users connecting to the repository anonymously have. Your options are "read", "write" and "none". In my case, I set this value to "none". Next, find the line that contains "auth-access" and set its value to either "read", "write" or "none". this line controls what access authenticated users will have. For the last change, find the line that contains "password-db" and remove the "#" character and the space that follows it to un-comment the line. This tell Subversion to look in the passwd file to find a list if valid users of the repository. Save your changes to this file.
Now, open the passwd file. All lines in this file are commented out, as well. Beneath the line "[users]", you will need to create a list of valid users for the repository in the form "username = password". Save your changes.
Accessing the Repository From a Client
Whichever client you choose, you'll need to specify a URL and your credentials. URL's for subversion are of the form svn://server-name. For credentials, you'll need to use one of the user-name / password combinations you created in the passwd file, earlier. At this point, you should be able to check out (get a copy of the current version) and commit (check in) to and from your repository. If, however, you're having problems reaching the server you'll want to check that the Subversion service is running and you also may need to configure svnserve.exe as an exception in windows firewall.
That's it for Subversion. Next time, we'll set up CruiseControl.Net.
Subscribe