Wednesday, September 29, 2010

Book Review–Continuous Integration in .NET

Disclosure: I received a review copy of Continuous Integration in .NET from Manning.

I don’t normally blog book reviews – mostly because it requires a specific skillset that I do not necessarily possess. However, due to some fortuitous timing I jumped on the chance to receive a review copy of Manning’s new title - Continuous Integration in .NET by Marcin Kawalerowicz and Craig Berntson.


One of my many hats right now is version control manager of our team – a role I inherited rather than requested but one that nevertheless led to a deep interest in all things VC and build related. Due to the restructuring of MSDN’s licensing tiers our team is finally in the position to utilize Team Foundation Server as our version control repository. Having successfully sold the migration to the powers-that-be, and having previously started the team down the path to TDD, I’m interested in leveraging a number of incorporated technologies – at the very front of the pack is Continuous Integration. Our shop has never had a CI process, but that is about to change.


The version of this book I read is a MEAP (Manning Early Access Preview) meaning that it is not the finished product. Specifically, and sadly, the final chapter Scaling Continuous Integration is not complete at this time. My review is of what is available as of 9/20/2010

My Expectations

· Explain why we need Continuous Integration

· Define the basics

· Go through full setup and lifecycle

· Provide tips and tricks for advanced scenarios

· Provide advice based on real world experience

The Book

Continuous Integration in .NET as expected starts out with an introduction to Continuous Integration, explaining in simple terms why it is needed and how it can be used. The notion of source control is introduced and then a manual automated build is illustrated showing how one, if they so desired, could do the grunt work to set up a trivial automated build. The 4th chapter, Choosing the Right CI Server, is where the real meat begins and the rest of the book deals with integrating commonly used technologies – unit testing frameworks, deployment tools, documentation generators, etc. – with the CI tools of choice.

After reading this book for a little while it hit me that the Continuous Integration itself is little more than an aggregation of other technologies and mechanisms, bundled together towards the common goal of automating tasks that may not otherwise receive the attention they deserve. The book acts as a 100 foot view of Continuous Integration in .NET environments. The authors do not choose a specific CI tool, but instead use Team Foundation Server, TeamCity and CruiseControl.NET, evolving their CI process by adding new steps as the book progresses. I really enjoyed the comparison of these CI servers and, while concise, it highlighted well the reasons to choose one over another. I’d like to have seen a few more thrown in for good measure but, frankly, these seems to be the big players anyway so I’m probably being picky.

The book’s greatest strength is probably also its greatest weakness – the huge scope of CI, coupled with the use of 3 CI servers, means that generalization is preferred to specialization and the book covers MANY of the basic tenets of CI, but does not delve very deep into any one topic. This is not a criticism of the title – it appears to be an explicit tradeoff that the writers made and was not unexpected. By the end of the book a novice should know exactly what CI is, the different types of automated builds available to them and integrate everything from email notifications to unit testing to code analysis…and then some. The book is easy to read and never feels overly technical (perhaps because of the content material) and I found it very accessible. If, despite my grogginess, I can read a technical book on my morning train ride to work, then it deserves some credit!

Because I am already very familiar with Version Control, Unit Testing, WiX, Clickonce and a number of other technologies in the book I felt myself skimming over a lot of material that would have been useful earlier in my career. I speed-read my way through the sections on unit testing and found that there while the authors did a good job of explaining how to integrate such testing into one’s CI process and have the results displayed through the CI GUIs, most of chapters 6 & 7 were wasted on me. I’d like to have seen more real world information and definitely some gotchas based on industry experience. Unfortunately such information was not contained in the MEAP version I read.

Interestingly I would love to give a copy of this book to (junior) newcomers on our team. Not only does the book provide an excellent description of the ins and outs of CI but it also explains in detail a large number of best practices in the software industry today and illustrates practical approaches to implementing them.

All-in-all this was a good book, definitely worth reading. It hit about 3 of 5 of my expectations (listed above) and as a precursor to my first foray into the world of CI it was useful to get a lowdown on the CI options available to me and guides to hook up other technologies to these CI servers. I’d definitely recommend the title to newcomers to CI and also to those interested in related technologies. However, if you’ve already leveraged CI, or are proficient with Unit Testing/Code Analysis/etc. the value you derive from this book may be a little more limited.

Sunday, September 19, 2010

TFS – XSLT to transform VSSConverter to Project Creation Settings File

September 19, 2010 Posted by Jason , , , 4 comments

For the last few weeks I’ve been spending a decent portion of my time (jointly) planning and testing my team’s migration from VSS to TFS. While I’m a big fan of Microsoft’s development platform I’ve been pleasantly surprised at the simplicity of the migration process. Visual Studio 2010 brings with it a command line application called VSSConverter which takes an XML file and completes transfer of code and history with almost no input…almost! The file looks like this:

<?xml version="1.0" encoding="utf-8"?>
<Source name="VSS">
<VSSDatabase name="C:\TFSMigration\vss_database"></VSSDatabase>
<UserMap name="c:\UserMap.xml"></UserMap>
<Project Source="$/BillingProject/BillingProject/Client" Destination="$/BillingProject/Client"></Project>
<Project Source="$/BillingProject/BillingProject/Server" Destination="$/BillingProject/Server"></Project>
<TeamFoundationServer name="" port="8080" protocol="http" collection="tfs/MyProjectCollection">

One frustration I have with the tool is that, while you must define your VSS-to-TFS project mapping, TFS projects are not automatically created – they must be created one-by-one using Visual Studio prior to migration. If you have a large number of projects (which we do) this can be quite frustrating (increasing exponentially with every test iteration run).

Fortunately, TFS’s powertools provide a mechanism to create projects based on a setting file. The command is as follows:

TFPT createteamproject /settingsfile:1.xml

Unfortunately a) it cannot use the existing information in the TFS conversion scripts and b) a separate setting file is required for each project to be created.

To save some time I wrote the following XSLT file. Applied to a VSS-to-TFS conversion file it will output an individual xml file for each project defined therein (filenames are incremented – 1.xml, 2.xml, etc.). Obviously some settings (TFS server/process template/etc.) are hard-coded and may need to be modified.

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:output method="xml" indent="yes"/>
<xsl:template match="ProjectMap">

<xsl:for-each select="Project">
<xsl:variable name="filename" select="concat('output/',position(),'.xml')" />
<xsl:value-of select="$filename" />
<xsl:result-document href="{$filename}">
<Project xmlns="ProjectCreationSettingsFileSchema.xsd">
<ProjectName><xsl:value-of select="substring-before(substring-after(@Destination,'$/'),'/')"/></ProjectName>
<ProjectSiteTitle><xsl:value-of select="@Destination"/></ProjectSiteTitle>
<ProcessTemplateName>MSF for Agile Software Development v5.0</ProcessTemplateName>

I personally use Saxon to transform my conversion file – both because it is quick and easy and because, unlike MSXSL it supports XSL 2.0). Afterwards I can use the TFPT createteamproject command to create my projects. The commands used are as follows:

Saxon\Transform.exe -s:conversion.xml -xsl:transformer.xslt

TFPT createteamproject /settingsfile:1.xml

TFPT createteamproject /settingsfile:2.xml

On a side, it should be straightforward to create a batch/powershell script to loop through the XML files and invoke the TFPT createteamproject command, but I’ll leave that to you, dear readers. Let me know if this is useful or if there is a quicker and easier way to achieve the same goal. Until next time…