每日构建，对我们团队来说一个全新的概念。随着项目开发的进展，在开发过程需要及时反馈一些BUG和功能要求的处理情况。而在这种情况下每天或隔一段时间Build一个版本，工作量还是比较大的，所以就特别有必要引入每日构建。关于每日构建，在园里有已经有很多的文章了，特别是摩诘的《在.NET环境中实现每日构建(Daily Build)--NAnt篇》更是从概念上和实践上手把手地介绍如果在.NET环境下实现每日构建。但很遗憾，在我实现每日构建之前没有看到这篇文章，错失了一次快速入门的机会，不过感到庆幸的是，经过一天的研究和学习，把自己在学习配置过程中遇到的一些问题总结一下，算是对每日构建实现方法的一个补充吧。

我是在Windows 2003中做每日构建的，使用CruiseControl.Net自动从VSS服务器中检测并下载最新的源代码，然后用MsBuild对解决方案自动编译。利用CCTray可以对每日构建的情况进行监控，了解CruiseControl.Net的工作情况。

下载安装完ccnet后，最重要的工作就是配置ccnet.config了。在安装目录下的server子目录里可以找到这个文件。虽然有帮助文件的支持，并且在Examples目录下有一个示例的配置文件，但是要想正确地配置这个文件也不是很容易的。在Ccnet.config里可以创建多个要监控项目的配置信息配置信息。包括：每个版本的标识方式，使用的源码库类型和登录信息，项目状态管理，每次构建要执行的任务，执行周期。以下是我的一个配置文件：

<cruisecontrol>

<project name="ccnetProject" webURL="Http://192.168.1.1/ccnet" publishExceptions="true">

<!--工作目录，下载的源码将会被保存在这个目录下，如没有设置则会自被保存在安装目录下server子目录以project name为名称的目录下-->

<workingDirectory>e:\ccnet</workingDirectory>

<!--对这个项目的监控过程的日志记录目录-->

<artifactDirectory>e:\ccnet</artifactDirectory>

<!--使用什么样的方式标识每一个自动生成的版本，可以有多种不同的方式。Labeller Blocks -->

<labeller type="dateLabeller" />

<!--使用的源码控制器类型，我算了一下，它支持18种的源码控制器，强吧？这里使用的是VSS-->

<sourcecontrol type="vss" autoGetSource="true">

<!--源码库中的项目名称-->

<project>$/ </project>

<!--vss用户名-->

<username>ccnet</username>

<!--vss密码-->

<password>dailybuild</password>

<!--vss服务器所在的路径-->

<ssdir>\\192.168.*.*\Vss Server</ssdir>

<!--工作目录，可以使用相对目录，以上面的workingDirectory为准-->

<workingDirectory>e:\ccnet</workingDirectory>

</sourcecontrol>

<!--执行周期-->

<triggers>

<!--定时任务，可以设置在哪天的那个时间执行构建计划-->

<scheduleTrigger time="14:00" buildCondition="ForceBuild">

<!--以下配置节有指定，则会在指定的时间日期内执行，没有则每天执行-->

<!--<weekDays>

<weekDay>Monday</weekDay>

</weekDays>-->

</scheduleTrigger>

<!--每隔多少时间执行一次-->

<!--<intervalTrigger seconds="30" buildCondition="ForceBuild"/>-->

</triggers>

<!--每次下载完代码后要执行的任务,可以有

* Build Publisher

* Email Publisher

* Executable Task

* File Merge Task

* ForceBuildPublisher

* Modification Writer Task

* MsBuild Task

* NAnt Task

* Null Task

* NUnit Task

* Visual Studio Task

* Xml Log Publisher

-->

<tasks>

<!--msbuild 自动编译任务-->

<msbuild>

<!--msbuild的路径，一般在系统目录下-->

<executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>

<workingDirectory></workingDirectory>

<!--解决方案文件，相对project 的workingDirectory，MSBuild会找到这个文件，并对它进行编译-->

<projectFile>code\*.sln</projectFile>

<!--编译参数-->

<buildArgs></buildArgs>

<!--编译的目录类型-->

<targets></targets>

<!--过期时间-->

<timeout>60</timeout>

<!--记录编译的详细日志，需要单独下载这个程序集，放在工作目录(workingDirectory)下，下载路径 http://ccnetlive.thoughtworks.com/MSBuildXmlLogger%2DBuilds/-->

<logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,ThoughtWorks.CruiseControl.MsBuild.dll</logger>

</msbuild>

</tasks>

<!--发布和部署配置-->

<publishers>

<!--下面的配置，会自将我源文件夹下的文件copy到指定的目录的版本标识(上面配置的labeller)的子目录下 如：e:\ccnet\publish\Shop\1\ e:\ccnet\publish\Shop\2\ 每一次生成都会递增-->

<buildpublisher>

<sourceDir>e:\ccnet\code\Shop</sourceDir>

<publishDir>e:\ccnet\publish\Shop</publishDir>

</buildpublisher>

<buildpublisher>

<sourceDir>e:\ccnet\code\Manager</sourceDir>

<publishDir>e:\ccnet\publish\Manager</publishDir>

</buildpublisher>

</publishers>

</project>

</cruisecontrol>

以上是对一个项目的进行监控的配置，当然也可以创建多个不同的项目。然后运行ccnet.exe每日构建就开始工作了，ccnet.exe.config文件是对当前的ccnet服务器工作环境的配置，不用进行修改就可以工作了，如果愿意可以配置监听端口号等等。

在webdashboard目录，通过WEB的方式对当前的ccnet的工作情况进行反馈。不知道是不是我配置的问题，我只看到了一条错误信息。但是通过CCTray可以更加方便的监视和管理构建过程。安装完CCTray后，打开Setting配置卡File>Settings

<!--[if !vml]-->
<!--[endif]-->

单击右边的Add按钮，添加一个要监视的服务器。在这里可以设置构建，成功，失败等各种声音。

<!--[if !vml]-->
<!--[endif]-->

在下边的文本框中输入要监视的服务器，如果是默认端口号则不用输入端口号，否则需要“:”隔开输入端口号。如果添加成功，则会在右边的Project列表框中出现在当前ccnet服务器中存在的项目。OK返回到主窗口。

<!--[if !vml]-->
<!--[endif]-->

在主窗体中有显示当前的服务器状态，最后一个编译时间，最后一次版本号，下一次生成时间等。点下面的Force Build按钮还可以强制马上进行生成。

最后说明一点，MsBuild会根据当前的项目文件或解决方案文件对项目自动进行编译，而不需要写任何的配置文件。而在asp.net 2.0中Web工程默认是一种新的Web Site模式，这样可能就会对编译造成Web工程产生一定的影响。所以推荐使用VS 2005的Web Application Project Web工程模型。

CruiseControl.Net官方地址：

http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET

Web Application Web 请参阅：http://dflying.cnblogs.com/archive/2006/04/06/368203.html

关于MSBuild的更多介绍请查阅相关资料，或查看MSDN。

from:http://www.cnblogs.com/hjf1223/archive/2006/04/13/374655.html