[原创]如何用CruiseControl.Net来进行持续化集成

注：本文属jillzhang  原创，转载请注明出处 ，欢迎访问http://jillzhang.cnblogs.com/来获取最新更新

1. 本文的目的：

本文总结了过去一年中使用CruiseControl.Net来对工作流程进行持续化集成的经验教训，详细地讲述安装，配置，使用CruiseControl.Net的具体步骤，希望通过阅读本文，能理解和掌握使用CruiseControl.Net的基本使用技巧，用工具来改善工作流程和提高工作效率。

1. 什么是持续化集成

首先，我们先搞清楚什么是持续化集成？它对我们的日常工作有什么样的帮助？在过去几年中，敏捷已经是一个非常热门的话题，它高效的工作方式和快速的需求应对能力，赢得了很多中小软件厂商的关注。那么敏捷除了一些经常谈论到编程思维和迭代的开发模式等，其实还部分依赖于好的改善工作流程的工具。持续化集成工具便是服务于敏捷软件开发的一个系列。它主要将原本分散，无序的工作流程，通过工具软件有机的组织起来，并且在组织的过程中，参与开发设计测试的各个部门的人员都能从中获取到自动化方面的优惠。使得团队的工作效率大大提升。

1. CruiseControl.Net是什么？

上面讲解了什么是持续化集成，那CruiseControl.Net就是一款由ThoughtWorks公司提供给我们的轻量级的持续化集成工具。它能够将代码版本控制，单元测试，代码规范检查，项目的发布部署等工作步骤有机的组织起来，并且利用其调度性可作自动化处理，它还有强大的日志记录功能，能将集成结果及时地反馈给项目管理人员和项目开发人员。在下文中凡是用到CruiseControl.Net均用CC.Net来代替。下面是CC.Net的工作流程图

 

注：本文属jillzhang  原创，转载请注明出处 ，欢迎访问http://jillzhang.cnblogs.com/来获取最新更新

1. 如何安装CC.Net

CC.Net是一款开源软件，它的官方主页是： http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET

打开它的主页，便能看出他的官方采用另外一款非常出色的团队协作平台:Confluence,用它结合jira Bug管理系统，也能极大限度的提高团队协作能力，有关他们的介绍请访问：http://www.jira.com/ 。好了，返回来继续介绍CC.Net，当前官方已经发布了最新的CruiseControl.NET-1.3.0.2918，在首页的release栏中，便可以找到下载最新版CC.Net的连接，它是一款开源软件，你也可以在http://www.sf.net中找到它的源码和安装文件。如果你就是想使用CC.Net直接下载exe文件即可。下载后,在本地的安装过程如下：

1. 双击CruiseControl.NET-1.3-Setup.exe程序，打开软件安装界面，如下：

   

2. 一直点击Next，选择软件安装路径，等待软件安装完成，界面如下：

   

3. 软件安装完成之后，在系统windows服务中将增加名为CruiseControl.Net Server的系统服务，如下：

   

   注意，默认情况该服务是出于未启动状态的。

    

因为CC.Net是一个集成持续工具在部署CC.Net之前，单独靠它自己是没有实际意义的，所以在部署配置CC.Net之前，您需要事先准备好并且安装下述 软件：

1. 代码版本管理工具如VSS
2. 代码构建工具，如果您是vs.net的用户，强烈建议不要使用NAnt，配置起来比较麻烦，建议使用MsBuild来做构建工具。MsBuild是随.Net FrameWork 2.0一起安装的，所您需要在CC.Net服务器上安装.Net FrameWork 2.0或者以上版本。
3. 代码规范检查工具,.Net用户推荐使用FxCop.exe，下载地址：http://www.microsoft.com/downloads/details.aspx?FamilyID=3389f7e4-0e55-4a4d-bc74-4aeabb17997b&displaylang=en，很不幸的是，它原来的官方主页 http://code.msdn.microsoft.com/GotDotNet.aspx 关闭了，在新的站点中，我没有搜索到它。
4. 单元测试工具：Nunit,官方主页：http://sourceforge.net/projects/nunit
5. 发布部署工具，如果是asp.net网站，可以使用ASP.NET 编译工具 (Aspnet_compiler.exe)，但我感觉它不好用，于是我自己实现了一系列的代码发布，FTP上传，XCopy安装等组件，在后面会提到。

除了上述，CC.Net还支持NCover，Simian和Fitness,我没有具体应用，便不多讲。 

 注：本文属jillzhang  原创，转载请注明出处 ，欢迎访问http://jillzhang.cnblogs.com/来获取最新更新

1. 如何配置和部署  

假定上述的几个工具已经成功安装，下面就用一个项目来演示一下如何实现自动化构建，单元测试，代码规范检测，自动发布部署。并且可以演示项目管理和开发人员通过什么样的手段能及时了解持续集成化的结果。

在演示制作之前，我们先来看一下当前的持续集成环境。

工具	地址和路径
Visual Studio SouceSafe	本局域网下一台服务器,IP地址192.168.1.200,共享目录:VSS,所以其根路径为: \\192.168.1.200\\VSS ,用户名user,密码pwd
CC.Net	CC.Net安装在IP地址为:192.168.1.10的服务器上。
单元测试工具NUnit	和CC.Net安装在同一主机
代码规范工具FxCop	和CC.Net安装在同一主机
发布服务器	位于公网的一台服务器，IP假设为200.100.11.15

 

首先，我们创建用于演示的解决方案Jillzhang.DailyBuild，其中包括四个项目：

项目	项目描述
Jillzhang.DailyBuild.Core	这个是一个公共类库项目，目的是测试类似这样的项目也在构建范围之内。
Jillzhang.DailyBuild.Test	单元测试项目
Jillzhang.DailyBuild.Web	网站项目一
Jillzhang.DailyBuild.Web2	网站项目二

建立好解决方案之后，将其添加到VSS项目管理器中。层次结构如下：

下面我让我们看一下，如何配置CC.Net使其工作起来。

1. 在CC.Net服务器上，点击开始菜单，在所有程序中选择CruiseControl.Net，打开CruiseControl.NET Config配置文件。
2. CC.Net支持同时监控和集成多个解决方案，每个解决方案在CC.Net中被称为1个Project.,在CruiseControl.NET Config中1个Project被一个<project>元素来描述。当然我们还要为每个Project指定名称和工作目录和日志存放目录。阅读CC.Net的文档，你可以了解<project>元素的一些属性和子元素。这里我只讲述一些我用到的。

   name ，如<project name="Project1">表示1个名称为Project1的新工程，这个名称在日后会作为项目的标识显示给查看报告的用户。比如显示在cctray上或者在网站doashboard上进行显示。还有一个比较重要的子元素<workingDirectory>这个元素非常类似于WCF配置中的<baseAddress>，用它来指示工程的工作目录，也就是从版本管理器上下载文件的根目录。除了这些我们还需要设定子元素<artifactDirectory >它用来指示日志记录的保存位置。CC.Net为我们提供了几种版本管理方式，可以用<labeler>

   来指定使用哪种类型的版本标签，如Date Labeller，Default Labeller等，具体也可以查阅文档。我们这里使用Date Laberller，所以设置为<labeler type="dateLabeller"/>。下面可以设置源代码管理器，CC.Net支持目前绝大多数主流的版本控制工具，如CVS,VSS,Rational ClearCase,VSTS, Alienbrain等十几种。我们这里使用VSS,根据上文VSS和解决方案的配置，我们这里设置为：  

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

<project>$/Jillzhang.DailyBuild.root/Jillzhang.DailyBuild</project> 

<username>user</username> 

<password>pwd</password> 

<ssdir>\\192.168.1.200\vss\</ssdir> 

<cleanCopy>false</cleanCopy> 

</sourcecontrol> 

 将autoGetSource设置为true，CC.Net会通过监视VSS中代码的版本变化，自动从版本管理器中获取源代码。Project是要使用的解决方案在vss中的路径，值为如下：

 

Username为访问vss的用户名,password为访问vss的密码。ssdir是 vss代码库的共享路径，我这里为\\192.168.1.200\vss\ 。如果将cleanCopy设置为true，那么CC.Net每次获取最新文件的时候是否完全覆盖更新文件。

当前，我们的配置文件为：

<cruisecontrol> 

<project name="TestProject" webURL="http://127.0.0.1/ccnet/"> 

<workingDirectory >E:\DailyBuild</workingDirectory> 

<artifactDirectory>E:\DailyBuild\Log</artifactDirectory> 

<labeller type="dateLabeller"></labeller> 

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

<project>$/Jillzhang.DailyBuild.root/Jillzhang.DailyBuild</project> 

<username>user</username> 

<password>pwd</password> 

<ssdir>\\192.168.1.200\vss\</ssdir> 

<cleanCopy>false</cleanCopy> 

</sourcecontrol> 

</project> 

</cruisecontrol> 

设置好VSS后，我们可以启动CC.Net了，方法如下，打开Services.Msc，找到CruismControl.Net Server服务，在启动之前，需要先解决一下可能最影响情绪的问题：我们知道windows services默认情况下是用本地系统账户运行的，可一般情况下我们会在当前操作用户下设置对vss共享目录的访问权限，比如当前windows运行账户为administrator，那么我们在administrator中通过net use设置对\\192.168.1.200\vss\的访问，也可以通过Source Safe Client打开该代码库，可这往往是一个烟雾弹，当我们在CC.Net中试图用服务来访问\\192.168.1.200\vss\ 的时候，系统服务账户并没有与该共享目录建立会话，所以会拒绝访问\\192.168.1.200\vss\，连访问权限都没有，更不用说获取代码了。所以首先要注意的是启动前，先设置服务的运行账户：

只有这样，我们才能进行下面的工作：

启动CruismControl.Net Server服务，重新签出，嵌入一下解决方案，稍等一段时间，我们便会在工作目录E:\DailyBuild中看到自动获取过来的文件。还要值得注意的一点是在log目录中最好事先创建好buildlogs，如果您在启动CrusimControl.Net Server服务的时候有错误出现，比如在启动的时候总是出现：

很可能得情况就是上面的配置有错误，您可以通过下面两种方式来确定服务到底出现了什么样的问题：

1. 按照提示，在事件查看器中查看错误，如：

   

2. 您还可以到CrusimControl.Net Server的应用程序目录查找名为ccnet.log的文件，里面有CC.Net详细的操作步骤。

如果没有启动错误并且在ccnet.log中没有明显的异常，可以打开监视网站来查看集成结果，监视网站的地址是在<project>元素上通过设置webURL属性来完成的，我们打开这个网址，如图：

当Last Build Status为Success的时候表示项目集成成功，此时点击项目名，可以查看具体的集成结果：

如果调用MsBuild来对代码进行生成，调用FxCop进行代码规范检查，和调用NUnit进行单元测试集成，还需要对CC.Net进行下一步的配置。

代码规范检侧工具FxCop不能被CC.Net直接使用，它必须附加到MsBuild.Exe的命令行中，有关如何使用MSBuild，可以参考msdn,不做具体介绍。为此我们创建一个用于生成并检查代码规范的任务，CC.Net支持自定义任务，方法是：使用Task中的Executable Task。

首先在工作目录，创建一个用于msbuild参数的DailyBuild.msbuild文件，文件内容如下：

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 

<Target Name="Build"> 

<!-- Clean, then rebuild entire solution --> 

<MSBuild Projects="Jillzhang.DailyBuild.sln" Targets="Clean;Rebuild"/> 

<!-- Run FxCop analysis --> 

<Exec Command="exeu.bat" /> 

</Target> 

</Project> 

这个MsBuild选项会使得msbuild.exe在生成完成之后调用工作目录中的exeu.bat文件，exeu.bat中是关于使用FxCop方法的，内容如下：

cd D:\Program Files\Microsoft FxCop 1.36 

d: 

FxCopCmd /project:E:\DailyBuild\Jillzhang.DailyBuild.FxCop /out:E:\DailyBuild\log\DailyBuild.FxCop.xml 

目的就是通过调用FxCop安装目录下的FxCopCmd命令行工具，对指定的程序集进行规范性检查，上述代码中，E:\DailyBuild\Jillzhang.DailyBuild.FxCop是事先生成好的FxCop项目文件，生成办法是打开FxCop 可视化界面，添加target，并保存到此为位置即可，如图：

并保存到E:\DailyBuild\Jillzhang.DailyBuild.FxCop

添加能生成代码并且检测代码规范性的配置如下：

<tasks> 

<exec> <executable>D:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> <baseDirectory>E:\DailyBuild</baseDirectory> 

<buildArgs>DailyBuild.msbuild /p:Configuration=Release</buildArgs> 

<buildTimeoutSeconds>1200</buildTimeoutSeconds> 

</exec > 

<merge> 

<files> 

<file>E:\DailyBuild\log\Build.FxCop.xml</file> 

</files> 

</merge> 

</tasks> 

注意，buildTimeoutSeconds是生成操作的超时时间,还有最好设置/p:Configuration=Release，因为这样有利于以后发布。而Merge是将上面各个任务中生成的日志进行合并。

下面重新签出嵌入，观察集成结果：

可以看到，已经release成功。

下面就看一下生成的DailyBuild.FxCop.xml，

打开看里面的内容便可以发现代码检测结果。

 注：本文属jillzhang  原创，转载请注明出处 ，欢迎访问http://jillzhang.cnblogs.com/来获取最新更新

篇幅太长，本篇先介绍到这里，剩下来的自动化单元测试，自动化发布部署留作下篇。