CI持续集成
CI持续集成
“我的TDD实践”系列之CI持续集成
写在前面：
我的TDD实践这几篇文章主要是围绕测试驱动开发所展开的，其中涵盖了一小部分测试理论，更多的则是关注工具的使用及环境的搭建，做到简单实践先行，后理论专精的目的。
TDD实践系列文章：
1.TDD概念篇
2.CI持续集成
3.SVN架设篇
4.NUint测试框架
5.Mock模拟框架
6.Inject注入框架
7.TestCoverage代码覆盖率工具
8.UMLTool建模工具
9.SandCastle构建文档
简介
CI（Continuous Integration）持续集成，最重要的服务对象是TDD，它是一个集合概念，包括自动构建build项目，自动分析代码，自动测试，自动邮件报告，自动预编译检查，自动发布等等，这些都围绕一个中心词“Auto”，当然它不能帮您自动完成代码 ：）。所有这些操作，直接解放了项目管理者，每日构建集成（Build every day）将会很大程度上提高项目的稳定性，代码的健壮性及随时反馈。
持续集成经典定义：www.martinfowler.com/articles/continuousIntegration.html
持续集成是一种能让团队成员友好“集成”（integrate）工作的软件开发实践，通常每个人最少每日“集成”一次，也就是说每天都要进行大量的“集成”（multiple integrates per day）。每一次集成都被自动构建器（automated build including test）尽可能快的检测集成错误。许多团队开发者发现，这种方法极大的降低了团队简集成的问题，而且能让团队更快的开发出有凝聚力，结合力的软件（cohesive software）。
--- Martin Fowler
持续集成拓扑图：
从实用性角度来说，持续集成避免了因为某人突然发生的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 获取反馈。
2. TeamCity
a) 介绍：简而言之，小项目免费，大项目付费。Web配置代替脚本配置。
官网：http://www.jetbrains.com/teamcity/
拓扑图：
b) 安装步骤：
i. 下载：http://www.jetbrains.com/teamcity/download/download_thanks.jsp
ii. 默认安装。（需更改端口防止冲突，选择user account登录）
iii. Web配置：
1. 配置视频：http://www.jetbrains.com/teamcity/documentation/demos/installation_new/index.html
http://www.jetbrains.com/teamcity/documentation/userguide.jsp
2. TeamCity在线文档：http://confluence.jetbrains.com/display/TCD8/Configuring+General+Settings
3. 登录配置网页进行相关设置，http://localhost:8011/login.html（安装时，更改了端口号为8011防止冲突）
3.1. 点击 Create New Project
3.2. 点击 Create build configuration。（也可先创建一个子项目，然后再新建一个配置）
3.3. 点击左上角的 Create and attach new VCS root, 然后VCS 类型选择SVN，如下配置：
3.4. 保存之后，继续配置：
选择自动构建的方式：选择Microsoft Visual Studio，也可选择其他的构建器，如MSBuild。
3.5. 增加一个Build Feature，这里可暂时不选择，直接跳过此步骤：点击网页右侧的导航栏，选择第4步。
3.6. 在导航中点击第5步：Build trigger
3.7. 这里已经完成了基本配置，更多高级选项请参考TeamCity官方资料。
3.Team Foundation Server(TFS)
a) 介绍：与VS2010集成，一体化解决方案，当然没有免费的午餐。
官网：http://msdn.microsoft.com/zh-cn/vstudio/ff637362.aspx
拓扑图：
b) 安装步骤：
请参见：http://msdn.microsoft.com/zh-cn/vstudio/ff637362.aspx
参考资料：
《Continuous Integration IN .NET》 Marcin Kawalerowicz
版权声明：凡是没有标注[转载]的，在引用文章时，均要加上本博客地址http://www.cnblogs.com/cuiyansong/。