敏捷开发 -- 持续集成

        软件集成并非一个新的问题或者概念，当一我的独立开发一个产品的时候，好比作毕业设计的时候，根本就不存在软件集成，更不用去考虑持续集成！可到了三五我的、七八条枪，进行团队开发的时候，这个问题就不得不去考虑了！特别是在传统的瀑布式开发中，模块开发是独立进行，当各个模块都完整开发完了以后，再进行模块间的整合，不少噩梦都发生在这个时候：接口不统一，模块间对需求的理解不一致 …… 每每要磨上十天半个月才能搞定！
       Martin Fowler （ ThoughtWorks 公司的那个“大胡子”）对持续集成的注解以下：
      Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
    我以为能够这样简单理解：及早地将开发人员的代码集成起来，经过各类工具来及时地发现代码中存在的问题，以确保代码质量的稳定性和准确性，让 Agile 第二宣言 Working Software 得以实现！
  下面咱们按照 Martin Fowler 的思路来介绍持续集成：
     1）Maintain a Single Source Repository
　　通常来讲，工程都是以团队的形式进行开发的。一个工程的文件都是以千百计算的，若是须要手工去跟踪、同步这些文件，那无疑是天方夜谭。因而源代码管理工具应运而生。开源的源代码管理工具备 CSV ， Subversion 等，我的感受 Subversion 比较好用，另外由 IBM Rational 出品的 Clearcase 功能更是强大，不过不是很便宜。咱们能够在这些源代码管理工具上面建立一个工程的 Stream ，而后你们即可以在这个 Stream 上面创建本身的 Child Stream, 在代码进行改动以后，咱们就将这些代码 Deliver 到代码库，代码的管理工具会为咱们作代码的同步工做。这样你们就能够基于最新的代码进行开发。
　　2)Automate the Build 　　
　　从拿到源代码到变成一个可运行的系统，这中间要通过一个复杂的过程。一个简单的过程大概有：编译 / 打包源代码，将打包好的包拷贝到服务器下面，而后启动或者重启服务器，这是简单到有点“ HelloWorld ”的感受。即便在这么简单的过程当中，还得开启 IDE 才能让编译源代码方便些，可在集成的服务器中，通常是不会使用 IDE 的。开发人员“懒惰”的特性迫使他们开发新工具来完成这一烦人的过程。 Java 社区开发出 Ant ， .NET 社区开发出 Nant ，如今还有 MSBuild 。经过这些工具，咱们能够将这些复杂、重复、单调、无聊的工做经过一些配置交由工具去完成。因为 Ant 的功能确实很强大，之后再找时间补充 Ant 的使用。
　　3)Make Your Build Self-Testing 　　
　　在传统的开发模式中，当 build 一个版本出来以后，咱们每每须要叫上全部的人（由于是分模块开发），花上几个钟头，在系统上进行人工测试。而郁闷的是：即便进行了人工测试，表面上看似没有问题了，可保证不了后台逻辑的正确性。咱们不是有 Automake the Build 吗，那咱们就能够往里面加进一些自动化测试的任务。这些自动化测试在 build 的过程当中，检测代码的逻辑的正确性、分析代码的复杂度、指出代码潜在的危险性，测试系统功能的完整性和准确性，测试系统的行为等等。固然，不是说咱们往 Ant 脚本里面加进几条命令就能够完成这些功能，而是须要咱们在写功能代码的同时或者以前，编写相应的测试代码，这就是前面说的 Test Driven Development （ TDD ，测试驱动开发） , 先写测试，再写实现！通常来讲，测试包括了后台逻辑测试 ( 通常用 NUnit), 测试前台脚本逻辑（ Javascript 的脚本通常用 JsUnit ），测试页面功能行为正确性（通常用 Selenium ），分析代码的复杂度（能够用 PMD ），分析代码潜在的危险性（用 FindBugs ）。
　　4)Everyone Commits Every Day 　　
　　集成不少时候是为了沟通，告诉其余开发人员本身已经作了那些代码的改动。及时的沟通在团队开发中的重要性是无可置疑的。因此咱们要尽快地将本身代码的改动提交。但代码提交以前，必定要确保本身代码的正确性，至少让系统能够跑起来。而不是说代码一有改动，就无论三七二十一，把代码弄上去就好了，这样对整个团队来讲， cost 会更大！因此是否每一天都要提交代码呢，我以为要具体问题具体分析！
　　5)Every Commit Should Build the Mainline on an Integration Machine 　　
　　前面说到天天都提交代码，这就会带来一个问题：在提交代码以前，未必有去拿到最新代码，即便拿到最新代码，因为开发环境的不一样，也可能没发现什么问题。因而代码上去了，另外一位同事去拿最新代码，有可能整个系统都跑不起来。因此，咱们还须要一个集成的机器，它负责在每次代码提交以后，去获取最新的代码，而后根据设置去运行相应的测试，看看此次提交的代码有没有什么问题。这样，即可以在下一个同事拿到新代码以前发现问题，并相应的 owner 去处理，减小更多额外的工做。 CruiseControl （由 Thoughworks 公司开发的，并贡献给开源社区）这个工具即可以作到这一点：它可以监听代码库有没有代码变动，若是有的话，即可以拿到最新代码，而后去运行相应的测试任务。关于 CruiseControl 的使用，能够看看官网上面的说明，后面可能会独立介绍一下。
　　6)Keep the Build Fast 　　
　　前面咱们说了，持续集成就是为了更快、及早地发现问题。因此若是一次集成须要耗费几个小时，甚至一天（据说 Microsoft 一个 build 就要一天，仍是分布式的），那就失去了持续集成的意义了。因此要让每次提交代码触发的集成动做越快越好， XP （极限编程）的大纲说每次 build 在 10 分钟之内是最理想的。但其实不少时候很难作到的，一个 UAT 都每每要占据几分钟的时间，重启服务器的时间也是不可或缺的，因此我以为这个快得根据不一样的项目而论。
　　7)Test in a Clone of the Production environment 　　
　　测试就是为了检查产品的使用状况，因此集成机器的环境搭建最好是跟最终产品的环境一致，好比说：相同的数据库，相同的服务器，相同的操做系统等等。
　　8)Everyone can see what’s happening 　　
　　持续集成就是一种沟通，那咱们应该让全部的人实时地、方便地看到持续集成的状况。一种比较简便的办法是安装一个 JCCTray( http://jcctray.sourceforge.net/ ) , 配置响应的参数，启动它以后，能够在桌面的右下方看到一个圆球的图标，当图标是绿色的，说明最近一次的持续集成是成功的，当图标是红色的，说明最近一次的集成是失败的，而当它是×××的时候，说明持续集成正在进行中。下面的图标显示最近一次的集成是有问题的：

还有一种就是用一盏灯来显示，红绿黄的意思跟上面同样，具体能够看 http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/Devices/BubbleBubbleBuildsInTrouble.rdoc
　　9)Automate Deployment 　　
　　当拿到新代码，通过测试，发现没有问题，这时应该进行自动部署。好比自动部署到 QA 环境等，不少服务器的自动部署均可以用 Ant 任务来完成的，因此具体的服务器得去查看相应的 Ant 任务。

    前面按照 Martin Fowler 的思路，介绍了持续集成的整个过程。我的以为持续集成不只仅在 Agile 是必须的，在传统的开发模式中，有了持续集成，也是对整个开发有不少的帮助，特别是提升代码的稳定性和正确性。     后面应该会陆续就本身在使用持续集成的一些工具过程当中的一些想法记录下来。