我的TDD实践---CI持续集成

“我的TDD实践”系列之CI持续集成

写在前面：

　　我的TDD实践这几篇文章主要是围绕测试驱动开发所展开的，其中涵盖了一小部分测试理论，更多的则是关注工具的使用及环境的搭建，做到简单实践先行，后理论专精的目的。

TDD实践系列文章：

　　1.TDD概念篇

　　2.CI持续集成

　　3.SVN架设篇

　　4.UnitTest单元测试

简介

　　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分钟左右。