There are a lot of challenges in getting someone else to write your code, both in communicating what you want up front and in making sure that what gets written is what you wanted. This is hard enough when you have a clear requirement like duplicating an existing system, and we are trying to produce something that hasn’t been done before. Working with someone 4500 miles away who we haven’t worked with before isn’t going to make things any easier either.


All this means that it is especially important to get the development environment right from the start. The key requirement is being able to see what progress everyone is making easily, which means a good source control and continuous integration server.


Fortunately, that has become a lot easier since last time I tried to set up something similar. Last time I was using SourceSafe, which isn’t the most intuitive product to get set up to run over the web.


First, the simple part - client side setup.

  • Visual Studio 2008

  • TortoiseSVN

  • VisualSVN



This is easy enough, just a matter of running the installers, though of course with a Visual Studio install it still takes most of the day to set up. At least using VS2008 improves things a bit as it is too new to have the excessive number of service packs and extensions you have to install to get VS2005 working.


The server takes a little more work, though not too much. For the most part I was following Rob Conery’s excellent post Source Control and Continuous Integration On The Cheap.


Since I already had a windows server available, I just had to connect with remote desktop and run the installers.


  • VisualSVN Server



Visual SVN gives you a simple desktop app to create a repository and add users. TeamCity lets you do everything after the install through a webapp.


Adding the project configuration to TeamCity was easy enough, though it did take me a couple of attempts to work out where everything was supposed to go. Where I started running into problems was with getting nunit running. Nunit turns out to be quite sensitive to the version used, which I didn’t seem to be able to get the same on both the server and client. The solution I ended up with was including nunit.framework in a solution items folder rather than expecting it to be installed on the build server.


After getting the unit tests working I added ncover integration as well (Integration of NCover into Team City for Tech Head Brothers), but I wouldn’t recommend trying that. Getting it working took about 4 hours (longer than setting up everything else). Not only was the end result not really worth it, I ended up turning it off because it was interfering with building locally as soon as I added a failing test. It would probably have worked if I set up a separate build script to run on the server, but I didn’t want to have to deal with multiple configurations.


Aside from that, the setup has been quite successful - while actual remote development won’t start until tomorrow, I’ve been using it for a couple of weeks and it’s running a lot better than the SourceSafe setup I’ve been using on another project.