持续集成 vs 持续检查
Keywords: 持续集成 持续检查 Contineous Integration Contineous Inspection Sonar Software Quality
蓝锋博客：http://bluesfeng.javaeye.com
本文系翻译文章，英文原文参见：
http://www.sonarsource.org/continuous-inspection-practice-emerges-with-sonar/
自从Kent Beck和Martin Fowler提出持续集成的概念来已经将近十年了。在当时很难想像这个概念会对开发人员的日常工作产生如此巨大的影响，也没有想到这个概念会被软件界如此广泛地接受。在今天我们难以想象如果没有持续集成，软件开发会是什么样。
持续集成的终极目标就是想要在软件开发的任何阶段，无论是Milestone，RC，还是GA，都能够以最低的风险发布软件的不同版本。让我们来总结一下持续集成能够做到什么：
- 任何人在任何地点，任何时间可以构建整个项目。
- 在持续集成构建过程中，每一个单元测试都必须被执行。
- 在持续集成构建过程中，每一个单元测试都必须通过。
- 持续集成构建的结果是可以发布的软件包。
- 当以上任何一点不能满足时，整个团队的主要任务就是去解决这个问题。
这确实是一个非常好的起点但对整个软件的质量来说确是不够的。那么还有哪些对源代码质量的要求呢？
- 任何新的代码必须和相应的单元测试代码一同进入系统。
- 新方法的复杂度不能超过定义的界限。
- 不允许包之间的循环性依赖关系。
- 不予许重复性代码。
- 不允许和已经定义的编码规范冲突。
- 不允许调用已经声明为过时的方法。
- 。。。
总而言之，以上这些需求的目的就是要控制整个“技术负债 ”并且意识到它的存在。这就是“持续检查”。 这个概念在5年前就出现了（IBM文章 ）。只不过近期又被进一步描述和定义了。但就向十年前的“持续集成”概念一样，持续检查仍然是一个很新的概念。
Sonar就是支持“持续检查”的最优秀的架构之一。关于Sonar的使用，请参考我相关的博客文章。
Keywords: 持续集成 持续检查 Contineous Integration Contineous Inspection Sonar Software Quality
蓝锋博客：http://bluesfeng.javaeye.com