MSDN Magazine - March 2008 - (Page 73)

ing. However, it is possible to pass parameters to an installer package with msiexec. The entry target for the CI server looks like this: I now have a build script that can perform a personal build on a developer’s machine as well as a public build on a CI server. I use CruiseControl.Net, better known as CCNet, to kick off this new build script. CCNet installs to the Program Files directory and can be shared by many different projects. There are two files that are used to configure CCNet: the server’s ccnet.config and the dashboard’s dashboard.config. The dashboard configuration is simply for display purposes and does not play a part in creation of the product, in this case guestbook. As such, its .config file will not be kept in source control. The server .config file is a different story and is critical to the build process. In order to manage the .config for guestbook in source control, I will create a new XML file and define the configuration using a Document Type Definition (DTD) referenced from the CCNet server’s .config file: C:\Program Files\CruiseControl.NET\server\ccnet.config <!DOCTYPE cruisecontrol [ ]> &GuestBook; Besides performing a clean get at the beginning of the build, it will also create a label at the end of the build, provided that the build is successful. The label is applied to the project node—Trunk in this case. Remember that Trunk contains everything needed to build this version of the product. So if you needed to come back to this version six months from now, pulling from this label will provide everything you need to successfully build the application. This is something that I have seen many teams neglect. Many teams fail to see the CI system as part of their product. It may not be something that you deliver to the customer, yet it still plays a critical role in your ability to deliver. Treat it with the respect it deserves and include it in source control, labeling it with your product’s source. Another benefit of this A CI server should be able setup is that it lessens the to perform a clean build, need for anyone to make changes from the build deleting the compiled server. Changes to the MSartifacts, the source files, Build script are easily made and the test execution from your workstation, environment. checked into source control, and then pulled to the build server by CCNet. This allows you to avoid the troublesome practice of making changes on the build server and then forgetting to check those changes in. The CCNet MSBuild task compiles the solution like so: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe C:\Projects\GuestBook\Trunk\Source C:\Projects\GuestBook\Trunk\Build\GuestBook.msbuild /noconsolelogger /p:Configuration=Debug /v:diag C:\ \ThoughtWorks.CruiseControl.MSBuild.dll Source Control Let’s add a new dimension and introduce source control. A CI server should be able to perform a clean build, deleting not only the compiled artifacts, but also the source files and test execution environment. It is a bad practice to perform dirty builds. It is even worse to perform a “sourdough” build. This is where you require a previous build be present in order to successfully build. Notice in the source control block that a fresh copy of the program source is pulled for every build. Cleancopy is set to true, like so: $/GuestBook/Trunk Build password c:\projects\GuestBook\Trunk C:\Program Files\Microsoft Visual Studio\VSS\win32\SS.EXE c:\Source Safe Databases\GuestBook true Most source control systems require the same type of configuration information: location of the repository, credentials, path to the root folder of the project, and the working folder on disk. And while the sample for this article uses Visual SourceSafe® (VSS), all the source control blocks in CCNet look similar for different source control providers (Visual Studio Team Foundation Server, Subversion, Perforce, Vault, and so on). MSBuild does not ship with an XML logger, nor does CCNet. You can download one from the CCNet wiki. It is referenced here from the Build directory. XML logs are important to CCNet, as the dashboard UI applies XSLT against the XML output from the build to produce HTML. The MSBuild task will collect the XML and include it in the CCNet XML log file for each build. To see a nicely formatted MSBuild report on the dashboard, you will need to add a configuration entry to the dashboard.config file, located at C:\Program Files\CruiseControl.NET\webdashboard\dashboard.config. Add this node at the location /dashboard/plugins/ buildPlugins, as in the code here: Logging and Reports Look back at the build script target RunTests and notice that the Continuous Integration march2008 73

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.