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.