我的TDD实践(4)

　　从实用性角度来说，持续集成避免了因为某人突然发生的Bug，导致团队的人员必须等待这个Bug被修复，持续集成每日集成则大大降低了这种事情发生的概率或者控制在一个合理发生Bug的时间内(一个工作日)。

　　1. 什么样的集成“频率”才是合理的?

　　2. 持续集成具体的优势和劣质在哪里?

　　2.1. 可能出现的问题：

　　2.1.1. 增加了维护CI的成本：起初可能是要在配置环境上花费些功夫，但比起使用效率上以及代码健壮性控制上，则CI更有意义。

　　2.1.2. 需求更改过于频繁，功能复杂：TDD开发的一个原则是“尽可能用最简单的代码完成一个需求，不添加额外的功能，如果需求改变，则让测试部通过，然后重构，即不要一次完成将来可能的任务，只注重当前”。

　　2.1.3. 增加软硬件成本和团队学习曲线(Study Curve)：同第一条定律，学习曲线则可根据团队情况逐渐深化。

　　2.1.4. 团队成员将不得不编写测试和构建项目：有了这些团队成员可以只关注编写代码和调试代码，比起修复那些被测试人员发现的bug，更多的利用了Coder的个人才能。(啰嗦一句，本人曾深受过那些莫名其妙的bug所带来的危害，有些还是由于其他人的改动导致的，这样不得不F11跟踪代码来理解Bug产生的流程，绝大多数时刻是极其痛苦的。)

　　2.1.5. 旧项目是否能用CI: 即使旧项目中没有单元测试，也可以用CI中的源代码管理等诸多功能。这里除非有绝对的意义，否则也不建议在旧代码的基础上补充单元测试。

　　2.2. 应用CI的优势：

　　2.2.1. 降低软件风险提高软件的质量：测试代码覆盖率越高，提供的稳定性就越高，建议代码覆盖率80%以上，所谓的二八原则?!

　　2.2.2. 增强项目的透明度：集成服务器持续的反馈集成信息，包括集成是否成功，Bug修复的时间，修复Bug的时间等。

　　2.2.3. 迅速构建：更快的发现问题，以及要求构建时间平均在1.9分钟左右。

　　3. 持续集成相关工具介绍：

　　3.1. 源文件管理系统(Source file control system)：SVN ，TFS(VSS)，Github。。。。

　　具体内容请参考，本系列的其他文章：请返回文章前言

　　3.2. 持续集成服务端(平台)：

　　3.2.1. TFS Server：微软一体化解决方案。

　　3.2.2. TeamCity：近些年流行起来的CI集成平台，由JetBrains维护。

　　3.2.3. CruiseControl.Net: 老旧的平台，脚本配置，06年更新过一回。

　　3.3. 单元测试工具：

　　MSTest，NUnit

　　具体内容请参考，本系列的其他文章：请返回文章前言

　　3.4. 代码分析工具：

　　FxCop，StyleCop，Ncover

　　具体内容请参考，本系列的其他文章：请返回文章前言

　　3.5. 其他工具：

　　SandCastle文档构建，Mock框架，Inject框架

　　具体内容请参考，本系列的其他文章：请返回文章前言

　　持续集成服务端搭建

　　本节主要叙述几种持续集成服务端的搭建及其中一些小的细节上的说明，由于时间原因，没有更深层次的说明更多的功能特性，这确实是不足之处，待今后有时间补充。

　　1. CruiseControl.Net(CC.net)：

　　a) 介绍：Thoughtworks旗下产品，免费，需配置脚本文件。

　　官网：http://confluence.public.thoughtworks.org/display/CC/Understanding+the+alternatives+to+CruiseControl

　　b) 安装步骤：

　　i. 下载CCnet：http://sourceforge.net/projects/ccnet/?source=dlp

　　ii. 点击安装包，进行默认安装。

　　iii. 安装完之后，如果是默认安装的话，在%Program Files%\CruiseControl.NET\server，找到文件ccnet.config并用记事本打开并编辑。

　　iv. 网上有很多配置文件，如下是我的配置文件，

　　c) 手动运行：在安装程序中启动CruiseControl.Net，验证是否成功。

　　d) 日志文件在：D:\CI\ArtifactWork\buildlogs目录下。

　　e) 查看相关记录：http://localhost/ccnet(前提是请安装IIS)

　　f) 客户端使用CCTry 获取反馈。

原文转自：http://www.uml.org.cn/Test/201308201.asp