Book review: Continuous integration in .NET.

I’ve been lazy to write anything here. I’ll try to write more from now on.

I’ve been reading quite many books lately, and I have even completed few of them. Thus I’ve set myself a goal: write a review on all software related books I’ve read (or almost read) during the last year. Here you have the first review:

Marcin Kawalerowicz and Craig Berntson (2011): Continuous integration in .NET


Overall estimate: 4/5. Good overview on the topic but doesn’t dive deep into the background and the theory.

The authors start and end by summarizing the idea of continuous integration. They won’t go deep in the theory or the motivation to do continuous integration. It ‘s okey as the main goal of the book seems to be to write good overview on how to implement continuous integration in .NET. The authors also succeed in that. Book introduces tens of different tools. Many of the tools I knew and had used already, but there were few new ones. They also succeeded to deepen my knowledge on some of the tools.

Since the overview of various different tools is the best part of the books, here you have listing of tools and areas of continuous integration with my personal short comments. (If the concept of ‘continuous integration’ (abbr. CI) is new to you, please check the basics from Wikipedia. I chose to be lazy and not explain them.)

(1) Source code repository. The authors discuss mostly SVN and TFVC (Team Foundation Server version control). Before the chapter on the source control tools, they the point out the significance of properly organized source code and the tools for CI. They mention distributed version control systems (DVCS) like Git but find DVCS systems a bit more difficult form CI point of view.

Personally, personally I’m really glad that now Git is now fully supported in Visual studio and TFS. (Or actually, not quite yet: you have to install Visual Studio 2012 Update 2 CTP (Community technology preview). So, you still need to wait for RTM versions, if you don’t want to use beta. In addition, Git is not yet available for in-premises installation of TFS.) 

I see distributed version control systems as an big opportunity e.g. in following cases: (1) simultaneous and geographically distributed maintenance of released code and development of new features and (2) multi-vendor environments. Of course, you have to do design decisions you need not do with centralized system – and, yes, DVCS it is slightly more difficult concept than centralized version control system. Great power comes with great responsibility.

(2) Build process. According the authors MSBuild is superior tool, however, they shortly discuss NAnt also. I haven’t ever used NAnt, but it’s easy to believe that MSBuild is better. By the way, I was not aware of MSBuild Community Task project. E.g. build task that zips certain files as a part of build sounds good.

(3) Build server and build agents. The book compares nicely Team Foundation Server, CruiseControl.NET and TeamCity. I’ve used CC.NET in one project and TFS in several. However, TeamCity is definitely something I need to study more. The main reason is following: if not everyone using build servers and version control have MSDN Professional/Premium/Ultimate subscription TFS is rather expensive (as far as I know).

Also the tool you need to use to modify the TFS build process is – well, not that good. Guys who designed TFS build workflow user interface should check out how neatly SQL Server Integration Services (SSIS) visualizes the workflows. Yes, I know that TFS uses Windows Workflow Foundation but that’s no excuse: if workflow is poorly visualized and the designer is difficult to use, the workflow is poorly visualized and the designer difficult to use; the workflow framework makes it no better. SSIS is good example that it need not be so.

(4) Test automation. Following tools were discussed: NUnit, MSTest, White, Selenium, FitNess, Visual Studio inbuilt UI test framework. Unfortunately, currently the biggest pain I have with unit testing relates faking framework APIs with acceptable amount of work.

(5)Statistic code analysis. The tools: FXCop, StyleCop, NDepend and TeamCity code analysis tool.

As a side note: Learning is the main challenge in software industry. The tools listed here may and – and in some extend – will accelerate learning, but automating code analysis and relying on only it, is not enough. The code must make sense within the problem domain, and no tool can ensure that. The danger I see here, is more or less the same than with the “best practices”. If you don’t understand the problem, focus in it, and keep it simple, the formally perfect code is worth of nothing. The “best practices” are not the goal nor are they the staring point, they should be seen as initial but potentially obsolete baseline and never anything more. Thus, always seek for something better and simpler. The same applies to these tools. Probably, no-one claims that automated statistic code analysis is enough. No-one claims that they are bad either. They are good as long as you understand what they are able to do and what not. I just wanted to underline the limits of automation on this area.

(6) Documentation generation. Just one tool was covered: Sandcastle.

Personally I’m slightly skeptical on the usefulness of XML documentation, since you easily end up having more comment than code (or comment that add no value) and thus code readability is severed. I’m waiting for a great, out-of-the-box innovation on the area of code documentation. If anyone happen to know a visual studio plugin that automatically hides XML documentation but let me easily check and write them when needed, please, let me know.

With no doubt, the code need to be well documented. However, XML documentation is a good solution only if you need not write, read and maintain code yourself. Otherwise they are too verbose and distracting. The smallest possible improvement to this: Chance XML documentation so that they could be placed also at the beginning or the end of method body like in PowerShell v.2. The goal: once you collapse the method also the XML documentation would be hidden.

Currently, I’m seeking the answer from BDD (or something alike): You first write description and examples for you APIs in more or less behavior driven way. The API’s behavior description and the examples will compile into the abstraction layers (abstract base classes and interfaces + something more like enums and constants) and test containers. Then your write the tests and the code (side by side). In theory, F#’s custom type provider could do that job but that’s completely different story.

(7) Deploying code. In the book, Microsoft Installer (incl. WiX and ClickOnce) and MSDeploy were covered. I definitely need to learn to use MSDeploy better than I currently do.

(8) Continuous integration with databases. Authors start by RoundhousE and end up praising Visual studio in-build database tools.

I have used some of Visual Studios database tools in small scale demos only and they seem to be good. However they won’t make databases open for extensions and closed for modifications (Strictly speaking, you cannot apply principles of object oriented programming to databases, but you get the idea). So, the root cause that makes SQL-database CI difficult and laborious remains.

Anyway, if I needed to develop software with extensive custom database Visual Studio in build tools would be my initial choice.


As I mentioned, they won’t go deep. I.e. if you are expecting solid arguments you can use to justify build automation to customer or management, choose another book. Unfortunately, you cannot either find proper references literacy discussing the subject more deeply. This book is good starter and overview on the subject, that’s all. Actually, let me correct myself a bit, it is also well written and edited overview and starter.