Rob’s Mind Flow

Okay, it's only been 2 months since my last post. I've been twiddling my fingers a lot. I have made some progress in my CI endeavors and I've changed my tools around a good bit here in the last few weeks.

I got really tired really fast of editing the XML configuration files for CC.NET. I'm not all that much of a fan of the MSBuild XML files either. I was having to change both a good bit when creating a new project.

Of course, not all my projects get put into the CI cycle. Small little apps just don't make it there. No need. Like I've said before I typically work alone. CI (I’m sure) has more advantages when on a team, but I'm hooked as an independent developer too.

So now for the update

I've switched from Cruise Control.NET to TeamCity. I think they are both really good products. I think TeamCity rocks with the configuration in the browser and no more editing of the XML files. TeamCity also has more polish in the UI itself. Its more pleasing to the eye.

I've also switched my testing frameworks around a bit. I'm still using xUnit. But I'm also using mSpec. I really like the BDD approach. I've tried to do that when I write xUnit tests, but it just isn't the same as using a framework that is built for BDD. Some say that the code style of mSpec is just too wacky and is foreign to c#. Personally, I like it. But that’s just me.

Subversion is still awesome and I don’t anticipate changing that. I’ve got TortioseSVN installed and also using the VisualSVN plugin fro Visual Studio.

Note: Take a look here for a good BDD overview and here for some more information about setting up mSpec within Visual Studio (both from Rob Connery). It is definitely possible to use TD.NET and ReSharper to run mSpec tests.

A bit more detail

Since TeamCity can’t run xUnit or mSpec tests natively there are some configuration changes to make and one XML file to configure.

Here’s how I’ve set it up. In TeamCity I set by build runner to be MSBuild. I created one MSBuild file (that is stored in my VCS with the project of course). The MSBuild script is pretty simple and should work for most of my projects. Take a look below and then I’ll walk you through it.

What I basically do is set up a list of solutions by doing a search of my Source directory for any file with an .sln extension. Typically there will be only one of these. I do a search for the Specs and the Tests as well just using simple wildcard searches. The “debug” in there should probably be removed and replace with a setting variable, but I haven’t done that yet.

This can be run from the command line locally or from within TeamCity. When in TeamCity I added “/p:SpecsForTeamCity=--teamcity” to the Command line parameters field. That way when running locally I just get the basic console output from mSpec but when in TeamCity I get the right content there too.

I expect this build script will work for just about all of the projects I’ve got going now. That wasn’t the case with my previous CC.NET files.

What are the benefits of CI

Feedback. It nice to see the dev project working. Compile. Pass test/specs.

Next steps

Release management. Tag a successful build and then release it. Post to the server as a site or as a downloadable installer or .zip of the exe and related files.

So I've decided on my toolset. It became rather obvious as to what I was going to use as soon as I started looked. I have to also admit that I had looked into CI before so I had a bit of an idea as to what I was going to use. Here's my list:

• CruiseControl.Net
• Subversion
• NAnt
• NUnit (would prefer xUnit, but I’m going to get setup with NUnit first).

So this is where I’m starting and will be the base set of tools. I’m going to probably add NDoc, FxCop and some other tools to the list soon, but wanted to get up and going quickly and the above list is the bare minimum I think.

Subversion and CruiseControl.Net are already installed and working just fine. NAnt, NUnit are on the CI server and ready to go. That was the easy part.

Like I’ve mentioned before I’ve mostly worked alone and inside Visual Studio so the biggest learning curve is coming from writing the build scripts. The XML configuration file for CruiseControl.Net is fairly straight forward. It isn’t the easiest thing I’ve ever done, but I’ve almost got my head around it. The biggest hurdle is writing the NAnt build files. Just a matter of getting my head around it. I’ll try to get some thoughts together as I learn it and post them here. It’s hard to say much while I’m still in the learning process myself.

Let’s talk a bit about CruiseControl.Net Configuration

I’m running cc.net as a Service. I’ve move the ccnet.config into a config subdirectory and added that directory to svn. My first project in the ccnet.config is one that watches the config svn repository for changes. The ccnet.config file is also simplified a bit. I’m putting projects in separate XML files and using entity definitions to include them in the ccnet.config file.

Here’s a sample of what my ccnet.config file looks like:

The cc-config project is used for watching for updates to the config file. I know that cc.net watches for changes to the ccnet.config file itself, but it was ignoring changes to the projectName.xml file. Adding this project seemed to overcome that and will refresh all the projectName.xml files whenever a change is committed to svn.

I’ll get into more detail in the project configuration files in a later post.

Ok. Things are changing around here. I have typically worked on projects solo and to some degree in a vacuum. I’m now working on larger projects with more stakeholders involved. This requires a change in my programming practices.

I learned a while about the importance of a version control. I’ve been using Dynamsoft’s SourceAnywhere (http://www.dynamsoft.com/) for about 3 years now. I like it and it has served me well. It was very easy to setup and get going for the newbie. All wasn’t perfect, but very good and easy. Everything was on my development machine which isn’t ideal, I know, but it worked for me. Now I’m changing my workflow a bit and my tools are changing to fit that workflow as well.

I’ve just started using CollabNet’s Subversion (http://www.open.collab.net/products/subversion/) and TortoiseSVN (http://tortoisesvn.net/) for versioning and SCM. It was fairly easy to set up and get started. Not as easy as SourceAnwhere, but not like painting the Mona Lisa either. Here’s a fairly good tutorial on the setup process http://www.west-wind.com/presentations/subversion/, but the Subversion and Tortoise documentation is incredibly helpful and well (and that’s saying something for free software).

As a side note: using TortoiseSVN and Subversion allows me to put anything under versioning control: Design files, Word docs, planning documents, anything. TortoiseSVN integrates with the explorer in Windows and with a right-click anything can be put into a Subversion repository.

I did miss the Visual Studio integration so the addition of one more piece of free software fixed that: AnkhSVN (http://ankhsvn.open.collab.net/).

Now instead of my versioning repository being on my development machine it is on a separate server for all of us developers to access.

The next step is continuous integration. I’ve got another developer or two that will need access to files as well as other stakeholders (and myself) who would like to know the status of the latest commits. Having a tool to build, test and generate reports when new code is checked in will be a great improvement to what I’ve been doing.

Over the next few posts I will outline what software and tools I’m using and how things are going. I don’t anticipate this being a lengthy process – nor do I see these posts being great tutorials – just pretty good information.

As I post other articles I’ll try to remember to update this one with links. If I don’t, well, just say something a bit mean under your breath and forgive me.