您的位置:首页 > 产品设计 > UI/UE

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

2008-03-03 18:18 501 查看
注:本文属jillzhang 原创,转载请注明出处 ,欢迎访问http://jillzhang.cnblogs.com/来获取最新更新

本文的目的:

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

什么是持续化集成

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

CruiseControl.Net是什么?

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

<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中的路径,值为如下:


<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\,连访问权限都没有,更不用说获取代码了。所以首先要注意的是启动前,先设置服务的运行账户:

<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,并保存到此为位置即可,如图:

<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/来获取最新更新

篇幅太长,本篇先介绍到这里,剩下来的自动化单元测试,自动化发布部署留作下篇。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: