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.
Comments [0]