CruiseControl.NET学习总结（转载）

前些日子，总结了一个NAnt的学习总结。后来就放下了，松散了一阵子。CruiseControl.NET(以下称CC.NET)，是我在学习完NAnt以后才开始看的，当时学起来就是在网上疯狂的找资料。现在就做一个关于CC.NET的总结吧。

CC.NET是一个开源软件，用它来做日构建实在是在好不过了。而且很方便，只需要配置一个配置文件就可以了。

CruiseControl.NET-1.4.1-Setup.exe（服务器端）

CruiseControl.NET-CCTray-1.4.1-Setup.exe（客户端）

首先，确保你的电脑上已经安装了IIS（因为CC.NET会在IIS里面建立一个虚拟目录作为Web服务）。

其次，是安装.Net framework 2.0(后面会用到，例如MSBuild)

OK，现在可以安装CruiseControl.NET-1.4.1-Setup.exe（服务器端）了，基本上一路回车就好了。

然后，接着安装CruiseControl.NET-CCTray-1.4.1-Setup.exe（客户端）同上。

安装成功，不要高兴太早。你打开IIS看看你的默认的web站点下面有名为ccnet的虚拟目录吗？

如果有，右键浏览，如图所示：

下面我们来看看解决方法：

控制面板->Component Services,展开树形结构：Computers->my computer->COM+ Applications,有问题的话，会弹出出错信息。

msdtc –install

可能是安装顺序有问题，强烈建议按照建议的顺序安装

2.检查IIS下虚拟目录ccnet的default页面，如果有冗余，只保留一个，其他的删除。

3.可能是COM+组件的权限问题。展开上面提到的COM+组件属性结构，查看IIS OUT-of-process pooled Applications 的属性，查看他的identity标签页，勾选为 Ssystem Account

IIS的默认权限应设勾选集成WINDOWS验证模式

如果页面出现：failed to access the iis metabase

在此基础上我先配置，然后卸载过之前安装的版本，在重新安装，OK，问题解决。

是什么也没有的。这时，我们可以通过File=》Setting=》Build Projects,弹出窗体：

默认是选择“Connection directly using .NET remoting”,点击OK，显示窗体：

这时，我们注意到，在左边的Build Server里面显示了我们的服务器，在右面的Available Projects确实空白。别着急，因为，我们还没有建立Project。

我们所有的对CC.NET进行的控制，都是通过修改一个配置文件（位于安装目录下的Server里面：C:\Program Files\CruiseControl.NET\server\ccnet.config）进行的。

<cruisecontrol>

<project >

</project>

</cruisecontrol>

只是，我们通过CCTray进行添加，就会出现

点击OK，这是CCTray显示如图：

这时，我们可以去强制编译，点击“Force Build”，这时，CCTray会有变化，但是，我们的操作是没有意义的。因为，我们还什么都没有做。

到现在为止，我们就添加了一个Project，以下我们的操作都是在这个Project基础上进行的。

配置文件中的内容：

<cruisecontrol>

<project >

<webURL>http://127.0.0.1/ccnet</webURL>

<artifactDirectory>F:\Test\CITest\Code\Log</artifactDirectory>

<workingDirectory>F:\Test\CITest\Code</workingDirectory>

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

<ssdir>D:\SourceSafe6.0d\TEST1\</ssdir>

<executable>D:\SourceSafe6.0d\VSS\win32\SS.EXE</executable>

<project>$/</project>

<username>cf</username>

<password>****</password>

</sourcecontrol>

</project>

</cruisecontrol>

说明：

webURL:通过web方式访问ccnet项目的地址<webURL>，ccnet提供的dashboard，下文中的dashboard就指用浏览器访问ccnet），远程就把localhost换成装了ccnet的主机地址，目前可以用http://10.0.3.146/ccnet访问这两个测试项目

workingDirectory：是下载的源码将会被保存的目录，如果没有设置，则会自动被保存在安装目录下server子目录下以project name为名称的目录下。当Project和sourcecontrol都含有workingDirectory时，以Project下面的为主。

artifactDirectory：对这个项目的监控过程的日志记录目录。（具体不知是做什么）

autoGetSource：为True时，CC.Net会通过监视VSS中代码的版本变化，自动从版本管理器中获取源代码

　　个人认为：服务器所在的路径，srcsafe.ini所在的文件夹，此例为本机，一般都是形式，为网络路径

　　网络：在ccnet服务器上的一个路径，可以是相对于该ccnet项目的主目录的路径，在需要执行持续集成的时候，用于存放ccnet从版本库中取出的版本，进行编译并执行持续集成

配置完成后，我们要重新启动服务。方法：打开”运行”，输入“Services.msc”，回车即可。

启动这个服务“CruiseControl.NET Server”。

有时候在启动这个服务的时候会出现一些奇怪的问题，我现在就我遇到的问题给大家总结一下。

我们可以通过右键点击这个服务，然后选择属性弹出窗体如下：

看Log On这个Tab，有两种登陆方式，一个是Local System account和This account。当我没有联机的情况下，我选择默认的方式就可以，也就是Local System account。但是当我在公司，以域的方式登陆的情况下，就必须选择This account，然后，选择我的域账号，登陆才可以。具体原因不清楚，大家遇到问题可以试一下。（了解的人，希望帮忙解释一下）。

当CC.NET中的一些语法错误时，同样会产生错误。

如图：

这时，我们就需要通过事件查看器来看看发生了什么错误。

打开控制面板=>管理工具=>事件查看器。然后选择左面事件查看器下面的Application，在右面的详细列表里面，可以看的一个“Error”，双击，可以查看错误描述。

如图：

从上图，很容易的就看出，我们的配置文件的第2行有问题（我特意将Project写成了Project1）。一般的问题都可以从这里看到并解决。

如果启动服务没有问题，我们打开CCTray，点击强制Build，过一会就会出现下图所示，说明已经编译成功。

同样，我们获取了代码，接下来的任务就是编译解决方案。在CC.NET里面，我们还是通过MSBuild来编译我们的解决方案的。脚本如下：

<tasks>

<msbuild>

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

<workingDirectory>F:\Test\CITest\Code\TestProject</workingDirectory>

<projectFile>test.sln</projectFile>

<buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs>

<targets>Build;Test</targets>

<timeout>900</timeout>

<logger>F:\Test\CITest\ThoughtWorks.CruiseControl.MSBuild.dll</logger>

</msbuild>

</tasks>

说明：

executable:msbuild所在的路径，一般为系统目录下的Microsoft.NET\Framework\v2.0.50727此例是.net framework 2.0，可能有更高的版本，是你的实际情况而定。

workingDirectory：我们要编译的解决方案所在的路径

projectFile:我们要编译的解决方案名

logger: 记录编译的详细日志，需要单独下载这个程序集，放在工作目录(workingDirectory)下，下载路径 http://ccnetlive.thoughtworks.com/MSBuildXmlLogger-Builds实验：我们可以先将解决方案中bin\debug中生成的dll删除，然后强制build，就会重新生成一个dll。

这里我们可以在写一个<msbuild/>去编译另一个解决方案，也可以将所有要编译的解决方案放入一个文件夹下面。然后修改projectFile节点如下：<projectFile>Solution"*.sln</projectFile>这样的形式（我没有试过，网上有这样的示例，大家可以试试）。

编译成功后，当然是进行单元测试了。

脚本如下：

<nunit>

<path>F:\Test\CITest\NUnit-2.4.8-net-2.0\bin\nunit-console.exe</path>

<outputfile>F:\Test\CITest\nunit-results.xml</outputfile>

<assemblies>

<assembly>F:\Test\CITest\Code\TestProject\bin\Debug\test.dll</assembly>

</assemblies>

</nunit>

将脚本添加到tasks节点中，位于msbuild的下面。

说明：

path：nunit-console.exe的路径，位于NUnit文件夹下的bin目录中。

Outputfile：单元测试输出的结果文件（文件名可以修改）

Assembly:要进行单元测试的dll或者exe文件的路径。

脚本编写完后，重启服务，然后强制build，当成功后，会在F:\Test\CITest目录下产生一个名 “nunit-results.xml”的文件。同时，我们双击CCTray右面的Project,就会打开webdashboard，通过它我们就可以浏览刚刚的编译成果。如图：

双击后，弹出窗体：

然后点击here，

这就是，我们刚刚进行过单元测试的结果。请看框选的部分。如果没有进行单元测试，结果是这样的,如图：

这样结果就很显然了。

现在我们已经在tasks节点下配置项目编译工具如msbuild，nunit，我们还可以用nant

脚本如下：

<nant>

<executable>F:\Test\CITest\nant-0.85\bin\nant.exe</executable>

<baseDirectory>F:\Test\CITest</baseDirectory>

<buildArgs></buildArgs>

<nologo>false</nologo>

<buildFile>default.build</buildFile>

<logger></logger>

<targetList>

<target>run</target>

</targetList>

<buildTimeoutSeconds>1200</buildTimeoutSeconds>

</nant>

说明：

baseDirectory：default.build文件所在的路径

buildArgs

nolog

logger

targetargetList名称

buildTimeoutSeconds

这样，我们就成功的用CC.NET调用了NAnt。我们可以在NAnt去做另外的操作。有关NAnt的使用请参阅““。

使用方法：

<exec>

<executable>C:\Program Files\NCover\NCover.Console.exe</executable>

<baseDirectory>F:\Test\CITest</baseDirectory>

<buildArgs>F:\Test\CITest\NUnit-2.4.8-net-2.0\bin\nunit-console.exe /noshadow F:\Test\CITest\Code\TestProject\bin\Debug\test.dll</buildArgs>

</exec>

说明：

本例就是通过外部的NCover.Console.exe去调用了NUnit-console.exe，然后对test.dll，进行了代码覆盖率的检查。

前面我们都是通过强制build对项目进行的build，现在我们介绍一下触发器。

触发器必须配置在<triggers>中，并且它可以嵌套。

可以屏蔽其它触发器，使其它触发器不执行。

<filtertrigger startTime=”7:30” endTime=”12:00”表示在每天的上午7:30到12:00都不执行持续集成。

注：嵌套在触发器里面的触发器，格式一定要是这样：<trigger type=”intervaltrigger”/>

例如：

<filterTrigger startTime="23:30" endTime="23:45">

<trigger type="intervalTrigger" seconds="60" />

<weekDay>Sunday</weekDay>

</filterTrigger>

说明：

weekDays：可以显式指定在一周的哪些天该触发器有效，默认是一周七天

<intervaltrigger seconds=”30” buildCondition=”ForeBuild”/>

说明：

Seconds：两次执行之间的间隔，默认为60秒

buildCondition：可以指定什么条件下该触发器才有效

IfModificationExists:指当CC.NET请求版本库中有修改的时候才执行。

定期触发器，可以设置一天中的一个时间定期的去执行持续集成

<scheduleTrigger time="23:30" buildCondition="ForceBuild" >

<weekDay>Monday</weekDay>

</scheduleTrigger>

说明：

并列定义多个触发器，用逻辑关系去设定它们。

<multiTrigger operator="And">

<intervalTrigger />

<filteredTrigger startTime="23:30" endTime="23:45" />

</multiTrigger>

说明：

有兴趣的朋友可以分别试试这些。

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

如果设置成<labeller type="defaultlabeller">

<prefix>Foo-1-</prefix>

<incrementOnFailure>true</incrementOnFailure>

<labelFormat>00000</labelFormat>

</labeller>

mailhostUsername="smtpuser" mailhostPassword="smtppassword" useSSL="FALSE">

<group notification="change"/>

<group notification="always"/>

<modifierNotificationTypes>

<NotificationType>Failed</NotificationType>

<NotificationType>Fixed</NotificationType>

</modifierNotificationTypes>

</email>

说明：

mailhost:CC.NET将要连接的SMTP服务器进行发送邮件

mailport: SMTP服务器的端口

includeDetails：是否发送一个完整的信息，true发送完整的信息。False，仅发送一个简单的状态信息

mailhostUsername这个邮件地址的用户名。

mailhostPassword：提供SMTP服务器的密码.

useSSL:是否用SSL发送邮件

users：定义一系列的user元素，用来发送邮件给他们

user：

groups：定义一系列的group，根据不同的通知策略进行通知

group：

name：group的名字，与user中的group相对应

notification：但某种情况下发送邮件

type：

Always：只要有build发生就发送

Change：当build的状态发成改变时发送（从“成功”到“失败”）

Failed：当build失败时发送

Success：当build成功是发送

Fixed: 当build的状态发成改变时发送（从“失败”到“成功”）

converters: 一套包含的内容规则创造的电子邮件地址基础上修饰的名称。

转换时将使用的名称修饰是没有设置的用户一节。(不是很了解)

modifierNotificationTypes：同group中的notification一样，但是用法不知道是做什么用的?有知道的朋友告诉我一下。

资料不全，随时补充！
作者：冰碟
出处：http://www.cnblogs.com/icebutterfly/
版权：本文版权归作者和博客园共有
转载：欢迎转载，为了保存作者的创作热情，请按要求【转载】，谢谢
要求：未经作者同意，必须保留此段声明；必须在文章中给出原文连接；否则必究法律责任