MSDN Magazine - March 2008 - (Page 76)

status and activity of the build server. It even tries to predict when the build will be complete. Figure 6 shows a successful build report for the guestbook project. The build report includes a summary page and several detailed reports. Notice the unit test summary report and links to detail reports on the left. The MSBuild Output detail report is available on the left, too. The View Build Log link displays the raw XML log file for this build instance. Figure 9 Customizing the CCNet Build Report xsl\header.xsl xsl\modifications.xsl Packages\Deployment\deployment.xsl xsl\compile.xsl Packages\VS.NETCompile\Compile.xsl Packages\MSBuild\compile-msbuild.xsl Packages\DotNetUnitTest\MbUnitDisplaySummary.xsl Packages\NCover\NCoverDisplaySummary.xsl Packages\Simian\SimianDisplaySummary.xsl Packages\nDepend\nDependSummaryDisplay.xsl Packages\FxCop\FxCopSummaryDisplay.xsl Using CI Factory Now I will demonstrate how to accomplish the same thing and more with CI Factory, but with much less effort. After downloading and installing CI Factory, open the solution file CI Factory.sln. Open the Arguments.xml file from the Solution Explorer to configure a new project. First I set the name of the Project to GuestBook: Next I set the names of the folders for the dev tree. Rather than use the default values, I changed these to reflect my develIt is so much more difficult opment tree, as shown in to create malformed XML in Visual Studio; the editor does a great job of bringing errors to your attention. Figure 7. Now set the build master and developer e-mail addresses. CI Factory will configure CCNet to e-mail a build report to developers when a build to which they have contributed modifications completes. It will additionally e-mail the build owner when a build fails, as you can see from this code: There are other options that can be set in this file, though most of the defaults are fine for my purposes here. For example, you can collect coverage statistics on the WatiN tests by setting the following property to true: Finally, I select the tools stack for the build as shown in Figure 8. CI Factory is organized with the concept of packages as a means for extension. The VisualSourceSafe package will provide integration with source control. CSDiff will provide diff reports on the dashboard. Versioning will maintain version information for both the assemblies and files. MSBuild will manage the compilation and reporting. NCover will well, you get the idea. At this point, I am finished configuring the CI Factory installer, so I execute the run batch file C:\Tools\CI Factory\run.bat to create the guestbook project. The script will install required software that is missing and prompt for acceptance to licenses. 76 msdnmagazine Continuous Integration Next, the batch file starts the CCNet server as a console application and opens a Visual Studio solution of all the build files. I have found it convenient to have a project dedicated to managing the build scripts. First, only the files that I need to edit are included in the project. It also saves time to have the assistance of the Visual Studio editor when writing XML. It is so much more difficult to create malformed XML in Visual Studio; the editor does a great job of bringing errors to your attention. You can also take advantage of what an XSD (XML Schema Definition) enables the editor to do: provide IntelliSense®! In contrast, Notepad has never brought an error to my attention. At this point I have a plain installation of CI Factory. The tree it created is very similar to what I created by hand earlier. You may notice the server and dashboard directories in the Build directory. These contain a copy of CCNet dedicated to serving the guestbook project. They are internal dependencies here as opposed to the external and quite possibly shared dependencies in the previous example. The CCNet project configuration file is in the same location as in the previous example: C:\Projects\GuestBook\Trunk\ Build\ccnetproject.xml. The main difference I would draw your attention to is that there are two projects—one to build the guestbook product and one to manage the build scripts. The build scripts project monitors the build directory in source control, simply updating the files on disk from the repository when triggered. The project that builds the product ignores changes made to the build directory. In my previous example, I had to write an MSBuild script, but here most of that has been taken care of during installation and is maintained in large part by the Main.Build.xml script. Like the MSBuild script I wrote, Main.Build.xml contains a target named triggered, but it does not contain a target named Build. The Build target is in a script named Personal.Build.xml and is located in the Source directory. There are more batch files than Build.bat. For example, Test.bat will execute just the test portion of the build script. But Build.bat includes more functionality, such as updating a developer workspace from source control: ..\Build\nant\bin\nant.exe -buildfile:Personal.Build.xml UpdateSource IF NOT %ERRORLEVEL%==0 exit /B %ERRORLEVEL% ..\Build\nant\bin\nant.exe -buildfile:Personal.Build.xml %1 %2 %3 %4 %5 %6 %7 %8 SET /P variable=”Hit Enter to continue.”

Table of Contents Feed for the Digital Edition of MSDN Magazine - March 2008

MSDN Magazine - March 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Introducing ASP.NET MVC Loosen Up CI Server Performance Office Development Test Run Security Briefs Extreme ASP.NET Foundations .NET Matters {End Bracket}

MSDN Magazine - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.