持续集成工具是怎样炼成的？持续集成工具实战

敏捷大师Martin Fowler对持续集成的定义是：持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

每天，程序开发人员将各自开发的代码上传到配置管理工具（如SVN、VSS）中，而配置管理工具会记录下谁在什么时间上传了什么代码文件。随后，持续集成工具会定期（可以是几个小时、半天，或者一天，由使用者自己定义）向配置管理工具询问，从上一周期到现在是否有代码上传。如果有，则下载到持续集成工具中进行集成。之后，持续集成工具会调用构建工具代码编译、自动化测试，以及执行静态代码检查。如果这几项工作执行成功，则打包复制到应用服务器（如Weblogic）上执行重新发布，并形成代码检查与测试等报告；如果执行失败，则及时通过邮件通知管理者，并记录相关日志。

配置管理工具

毫无疑问，配置管理工具对持续集成工具来说是绝顶重要的，它是所有最新代码的来源。持续集成工具会定期向配置管理工具询问代码是否有更新。只有有了更新，持续集成工具才会去完成后续的工作，否则就没有了意义。目前在Java开发项目中，最主流的无疑是Subversion（简称SVN）。SVN是对CVS的升级，它通过插件的形式被集成到开发工具中，并且提供了更加方便的上传下载操作，使开发人员最厌恶的上传下载操作变得简便。SVN的另一个巨大贡献是改变了VSS那样的串行修改模式。众所周之，VSS的版本管理思路就是串行修改模式，即对于同一个文件只能一个人修改，其他人不能修改。这样的模式对应大规模团队开发来说无疑是非常蹩脚的。SVN改变了这种模式，同一个文件可以多人并行操作，但同时SVN又提供了强大的版本冲突处理机制，当并行操作的多人各自提交版本时，通过版本冲突处理机制可以顺利的合并版本，使最终形成统一版本。

当然，所有的持续集成工具都支持VSS，但VSS现在显得过于陈旧，用它的人是越来越少。这其中一个最重要的原因是，它要求服务器端必须以共享文件的形式提供给各个客户端，存在着相当的安全隐患。SAWV（SourceAnyWhere for VSS）是VSS的替代产品，它通过客户端远程接入方案下载代码，很好地解决了这样的安全隐患。但十分遗憾的是，只有SAWV 5.4以上版本才仅仅支持CruiseControl.Net这一个持续集成产品。

构建工具

对于持续集成工具来说另一个重要的工具就是构建工具。构建工具就是对源代码进行自动化编译、测试、代码检查，以及打包程序、发布到应用服务器上的工具。可以说，从配置管理工具上下载最新源代码后，所有的后续工作都是构建工具在完成。目前，主流的构建工具就是Ant与Maven。Ant是老牌的构建工具，几乎成为构建工具的一面旗帜。它通过简单的XML文件的配置，就能定义一个软件项目复杂的构建过程（就是前面描述的那个过程）。许多软件项目在发布源代码的同时都会同时附带一个Ant配置文件。一个不熟悉该项目的人，只要使用Ant运行这个配置文件，软件就被发布到服务器中，十分方便。

但随着时间的推移，人们发现了Ant的弊病。当公司里的软件产品越来越多时，虽然每个产品的构建过程都不一样，但大体过程是相似的。如果每开发一个软件产品都要重新编写一次配置文件，那实在太麻烦了，能不能将构建过程继承下来呢？为此，Maven就诞生了。

对于一个有着丰富产品，并且业务还在不断扩大的软件公司，使用Maven实在太适合他们了。同时，Maven强大的中央库概念令管理者们无比地兴奋。现在的软件项目往往需要使用第三方的软件框架，而第三方的软件框架又要使用其它的软件框架。这样，项目在引入jar包的时候会处于一种绪乱状态。如使用Spring框架的时候需要引入aopalliance.jar；使用Hibernate框架的时候需要使用cglib.jar。当项目引入的框架越来越多时，哪些jar包有用，哪些jar包无用，谁也说不清楚。当我们使用Maven后，只需要告诉Maven我们使用Spring，Maven的中央库就可以完成后续的工作。如果下一个项目与这个项目的架构相同，则我们继承这个项目的配置就可以了，一切是不是就变得很easy？

静态代码检查工具

如何提高代码质量，代码规范无疑是必不可少的一项要求。过去，代码能运行，能满足用户的业务需求，一切就OK了。但是随着软件生命周期越来越长，软件需求变更与功能扩展越来越频繁，以及人员更替的增加，管理者开始意识到代码质量的重要。提高代码质量，就是提供代码的可读性、可维护性和易变更性。话虽然这样说，但真正要做到却并不容易，特别是那些刚刚参加工作的新手。软件项目中的新手常常让管理者无可奈何，使用他们则代码质量无法得到保证，不使用呢又无法保证项目进度，也不利于新人的培养，十分两难。一个比较公认的最佳实践就是制订代码规范。

由比较有经验的开发人员制订的代码规范，可以有效地提高代码可读性，为初学者提供开发指南，避免低劣甚至错误代码的产生。但是，当项目组制订出详尽的代码规范以后，检查开发人员是否按照规范编写代码，成为管理者面临的另一个难题。静态代码检查工具正是这个难题的解。

静态代码检查工具是一种机器自动检查代码编写是否规范的工具软件。它首先有一个代码规范库，它是无数有经验的软件开发专家制订的代码规范。作为使用者，我们可以定义我们到底使用哪些规范，哪些规范不使用。然后定义出一个代码检查的范围，即哪些代码需要检查。之后运行静态代码检查工具，工具就会依次对范围内的所有代码进行规范检查，最后形成检查报告，报告哪些代码，在哪行，不符合哪项规范。

使用持续集成工具以后，静态代码检查工具就会大放异彩。每当开发软件将代码上传配置库以后，不久持续集成工具将下载这些代码，进行自动化的静态代码检查，最后将代码检查报告发布的持续集成控制台，或者发邮件给管理者。随即，管理者就会通知相关人员进行修改。

目前，比较主流的静态代码检查工具包括CodeStyle、PMD、FindBugs，它们都可以有效地集成在构建工具中。同时，它们除了拥有丰富的代码规范库以外，还支持自定义代码规范，以及对已有代码规范的规则调整。

自动化测试过程

在敏捷开发众多的实践原则中，“测试优先设计”无疑是相当重要的一个，但也是比较有争议的一个，后来逐渐形成了“测试驱动开发”方法。测试驱动开发（Test-Driven Development，简称TDD）是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后编写相应的功能代码，通过测试来推动整个开发的进行。测试驱动开发要求开发软件不仅要编写功能代码，也要编写测试代码，这无疑将加大开发人员的工作量，延长开发时间。但是，测试驱动开发提高了代码编写质量，特别是对于频繁业务变更与增量开发更是如此。

前面提到，增量开发要求我们先开发业务功能中最主要的部分，然后再逐渐添加次要的部分，直到最终完成开发。这样一个过程中，代码始终处于变化当中，可能出现的问题就是，后面的代码完成开发了，但前面的代码出现问题了。采用测试驱动开发，每次完成代码开发，都要对所有功能进行测试，可以有效避免以上情况的出现。

同样，在大规模的团队开发中，相互协作和调用是越来越多。当某个人修改了自己的代码，可以导致另一个的代码发生错误。在这样一种风险下，持续集成中的自动化测试过程就变得重要起来。当每个开发软件进行功能开发时，都分别编写各自的测试代码，并与功能代码一起发布到配置库中。当持续集成工具下载最新代码时，同时也下载了测试代码。代码集成以后，它将对所有的测试代码执行测试。这样的过程就相当于对整个项目进行一次完整的测试，只是测试工作是由机器自动执行。通过这样一个过程，以上的集成问题就会马上发现，并及时通知相关人员进行修复。

另外，敏捷开发强调拥抱变化，这就意味着开发团队随时在应对和响应来自客户的变更。这种变更有时会很小，但有时也会很大，以至于开发人员不得不对部分代码进行重构。重构以后会怎样呢？是不是会对其它功能呢？通过自动化测试就可以及时发现并修复问题。

目前，Java开发常用的自动化测试工具就是JUnit，它可以被所有的构建工具所支持。另外值得我们关注的还有一些测试覆盖率统计工具，它们检查测试代码对被测程序的覆盖率，并形成覆盖率报告。一个比较优秀的开源测试覆盖率统计工具就是Cobertura（ http://cobertura.sourceforge.net/ ），它可以统计整个项目的覆盖率、各包的覆盖率、各类的覆盖率，最后展示哪些代码被覆盖，哪些代码没有被覆盖。

持续集成报告

当一个软件项目使用了持续集成工具以后，许多的管理工作由不可靠的人为操作变为了机械自动化操作。作为项目开发成员，特别是项目经理，最关心的就是持续集成报告。进入持续集成控制台，可以看到所有在用的持续集成项目，哪些当前有问题，哪些没有问题，一目了然。进入一个项目后，它的历次持续集成操作被罗列出来，什么时候执行的，执行是否成功，执行失败的问题日志，都可以看到。除了这些，我们还可以看到，每次都有谁在何时提交了什么代码，自动化测试结果及其问题日志，代码检查结果及其问题日志，最后是测试覆盖率报告。