Continuous Integration and MSBuild In An Enterprise Environment

andyhock@ewriters.org — Thu, 17 Apr 2008 10:36:00 GMT

I'd been tasked with creating a one-click continuous build, using CruiseControl.NET for a client's DotNetNuke applications. Since it's a Microsoft shop, I decided to architect the solution using MSBuild instead of NAnt. Since the client has an enterprise license for Sourcegear Vault, we didn't have a choice for source-control. Personally, I consider Subversion a better product.

First thing to do: buy a book! There aren't many choices available. The best reviewed of them is www.amazon.com/Deploying .NET Applications Using MSBuild, which I would rate highly except for the pathetic index. Why people publish what are essentially reference books and make it impossible to find anything is a question for the publishing gods. Suffice to say that if you ever get a book published, demand to see the index before you allow it to go to print, because in our world, a good index is the difference between an five-star and a two-star review.

Then, the google research. There is a paucity of information available on the web for enterprise-based continuous integration (CI). And I found no information at all on dealing with CI for web application frameworks like DotNetNuke. More imposing was this lack in the MSBuild world. It seems that most published MSBuild CI implementations are for desktop-based applications. In an enterprise world, one would have to multiple this 'one application MSBuild' task by a hundred or more, never mind the added complexity of web-based applications.

There were a number of issues to resolve in creating our one-click build work for a framework-based web application:

We considered it imperative that the build include Unit Testing, intensive Code Analysis and also automated API document publishing, using the comments we ask our programmers to include in their objects. To accomplish this, we decided on FxCop, NCover and NDepend for code analysis and metrics, and Sandcastle Help File Builder.
The elegant way to create one-click DotNetNuke deployment builds meant our DotNetNuke module build process needed to:
- automatically update the version info,
- create the .dnn file,
- zip up both the dnn module and the source,
- deploy the modules to the website on a successful build (Compile -> Unit Test -> Code Metrics and Analysis -> API Document Publishing),
- and automatic installation of the modules onto the web application.
To accomplish this, I needed to create a custom Visual Studio Project Template. The template would be used when compiling our DNN modules, and also when building and deploying them on our build server.
While Sourcegear claims to be 'highly committed' to Visual Studio, in the three plus years since Microsoft announced MSBuild, they have yet to release any MSBuild tasks for Vault. In fact, though there are requests for this feature on their support forums for this feature, they refer people to an unsupported third party site's MSBuild conversion of their NAnt customt tasks--a zip file which no longer exists. If we wanted a Microsoft solution, we'd have to write any custom MSBuild tasks for Vault ourselves.
Since we've committed to using MSBuild, we needed to decide if we would implement a solution-based, or a project-based build. We decided on a process that used Visual Studio solutions (an 'all' solution, a 'notests' solution and a 'unittest' solution). While this required our buildmaster to maintain three solutions for each web application, if we'd gone with a project-based solution, the buildmaster would still have to be informed of new projects to update the build.

Because the client wanted control over new DotNetNuke modules, the buildmaster is informed of a need for a new module, creates the module using the custom Visual Studio template, and adds it to source-control. Programmers can then check out the module project and complete the coding and unit tests.

To implement the CruiseControl script, since we didn't want to write a different build script for each CC.NET project, we used the client enterprise naming conventions to create solution names from the company name, subsystem name, application name and framework. Assuming the following:

Company Acronym = "LCS",

Subsystem Acronym = "SIS",

Application Name = "Store", and

Framework Name = "DNN",

then the solutions to use in the build script (dependent on if we wanted to build the modules or the unit tests), would result in the MSBuild script building the LCS.SIS.Store.DNN.NoTests.sln and LCS.SIS.Store.DNN.UnitTests.sln solutions.

What I want to do is walk next-generation buildmasters through the design steps of how we architected continuous integration of web applications in an enterprise environment, so you can understand the design considerations and thus make an informed decision on how you would implement CI in your enterprise. In our next article we'll start by discussing how we divided up the CruiseControl.NET projects.

We welcome any comments you have concerning CI in an enterprise, especially any experiences you've had.

How to add a DotNetKicks KickIt icon to the DotNetNuke open-source Blog module.

andyhock@ewriters.org — Fri, 04 Apr 2008 20:03:00 GMT

How to add a KickIt icon to the DotNetNuke Blog module tutorial, examples, DNN

Two excellent DNN sites, DNN Creative for tutorials and Ventrian for modules

andyhock@ewriters.org — Fri, 23 Feb 2007 06:54:00 GMT

We are very careful about recommmending pay-based sites. Heck, it's the internet and there're tons of free code and things to download.

But if you want to learn DotNetNuke, or keep up with what is going on, or have questions about how to use it, DNN Magazine by DNN Creative is the place you should subscribe to. It's less than 50 dollars a year (and no, I don't get a cut for recommending it, nor would I accept it), and there are already almost 200 videos, tons of tutorials and non-moderated forums for you to ask questions of other DNN users.

It's a steal, IMO. And as someone who has created interactive magazines, I know how much work must go into creating one that is successful and offers good value. Lee Sykes, the editor at DNN Creative has created an interactive magazine with video tutorials, written tutorials, module reviews and informative forums that passes this test with flying colors. So if you're interested in DNN, you need to subscribe.

One other subscription site, which is also less than 50 USD per year to join is Scott McCulloch's Ventrian Systems site. There are a number of handy modules here, and Scott has a great blog with lots of good information. Scott is also a member of the core team of DotNetNuke, so you know his modules avail themselves of the same excellent design that is evident in most of the DNN core.

Downloading just one of the modules, like the Articles module, or the Private Messages module, or any of the other modules Scott offers, all for either a 3 month subscription or a 1 year subscription (the last I checked, the one year subscription is 35 USD a year, of which one module, including source, is worth that amount). If you want to be able to inspect code, see how a DNN module should be built, Scott's site is the best place to go.

I promise, you won't be disappointed if you spend the money.

Fingerfuel's Technology Blogs

Continuous Integration and MSBuild In An Enterprise Environment

How to add a DotNetKicks KickIt icon to the DotNetNuke open-source Blog module.

Two excellent DNN sites, DNN Creative for tutorials and Ventrian for modules