持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中
持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。
集成：是指软件个人研发的部分向软件整体部分交付，以便尽早发现个人开发部分的问题；
部署：是代码尽快向可运行的开发/测试节交付，以便尽早测试；
交付：是指研发尽快向客户交付，以便尽早发现生产环境中存在的问题。
如果说等到所有东西都完成了才向下个环节交付，导致所有的问题只能再最后才爆发出来，解决成本巨大甚至无法解决。
而所谓的持续，就是说每完成一个完整的部分，就向下个环节交付，发现问题可以马上调整。是的问题不会放大到其他部分和后面的环节。
这种做法的核心思想在于：既然事实上难以做到事先完全了解完整的、正确的需求，那么就干脆一小块一小块的做，并且加快交付的速度和频率，使得交付物尽早在下个环节得到验证。早发现问题早返工。
举个例子，你家装修厨房，其中一项是铺地砖，边角地砖要切割大小。如果一次全切割完再铺上去，发现尺寸有误的话浪费和返工时间就大了，不如切一块铺一块。这就是持续集成。
装修厨房有很多部分，每个部分都有检测手段，如地砖铺完了要测试漏水与否，线路铺完了要通电测试电路通顺，水管装好了也要测试冷水热水。如果全部装完了再测，出现问题可能会互相影响，比如电路不行可能要把地砖给挖开……。那么每完成一部分就测试，这是持续部署。
全部装修完了，你去验收，发现地砖颜色不合意，水池太小，灶台位置不对，返工吗？所以不如没完成一部分，你就去用一下试用验收，这就是持续交付。
CI（continuous integration）持续集成
一次构建：可能包含编译，测试，审查和部署，以及其他一些事情，一次构建就是将源代码放在一起，并验证软件是否可以作为一个一致的单元运行的过程。可以理解为频繁的在多个团队的工作中集成，并且给与反馈的过程。团队开发成员经常集成它们的工作，每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
CI场景如下：
（1）开发人员向版本控制库提交代码，同时，集成构建计算机上的CI服务器正在轮询检查版本控制库中的变更
（2）在提交发生之后，CI服务器检测到版本控制库中发生了变更，所以CI服务器会从库中取得最新的代码副本，执行构建脚本，该脚本将对软件进行集成
（3）CI服务器向指定的项目成员发成电子邮件，提供构建结果的反馈信息。
（4）CI服务器继续轮询版本控制库中的变更。
CI持续集成周期
一个典型的持续集成周期包括以下几个步骤：
（1）持续集成服务器不断从版本控制服务器上检查代码状态，看代码是否有更新。
（2）如果发现代码有最新的提交，那么就从版本控制服务器下载最新的代码。
（3）等代码完全更新以后，调用自动化编译脚本，进行代码编译。
（4）运行所有的自动化测试。
（5）进行代码分析。
（6）产生可执行的软件，能够提供给测试人员进行测试。
CI系统
在CI中您需要一个版本控制库，比如（CVS或者SVN，subversion）来执行CI。版本控制库，大家都知道SVN，可以方便的管理源代码，可以沿着时间轴取得不同同版本的代码。CI服务器在变更提交到版本库后执行的集成构建，他会每个一段时间去检查版本库中的变更，所以我们需要对CI服务器进行配置。CI服务器还需要提供一个方便的显示板来显示构建的结果。但是CI服务器并不是必须的，也可以通过执行构建脚本来执行构建。
从上面我们知道CI的4个基本特征：与版本控制库链接，构建脚本，某种类型的反馈机制，集成源代码变更的过程。这也是CI系统的4个基本功能。一个好的CI系统的关键特征就是速度，这个系统的本质就及时向开发者和项目风险承担者提供反馈信息。
既然CI这么好，但还是有些团队并没有选择使用，其实这是一个综合考虑的结果。使用CI会增加一些成本的，比如增加了维护CI系统的开销，变化太多尤其是对于老项目需要改变很多才能实现CI。失败的构建太多，如果在提交代码之前没有私有构建一次，就会造成在使用ci的时候变更变得频繁。存在额外的硬件和软件成本，使用ci就需要一台独立的集成服务器。
一些需要考虑到的问题
测试能达到多少代码覆盖率？
执行构建需要多长的时间？
平均的代码复杂度如何？有多少代码重复？
在版本控制系统中对构建版本打上标签了吗？
已部署的软件存放在哪里?
是否使用测试覆盖率工具？
如何做好code review？
CI工具
持续集成工具：jenkins、CruiseControl、Hudson、gauntlet
构建工具：Maven、Ant、groovy
CDBI：持续数据库集成，即每次项目的版本控制库中发生变更时，重建数据库和测试数据。
Jenkins
Jenkins 是一个开源项目，提供了一种易于使用的持续集成系统，使开发者从繁杂的集成中解脱出来，专注于更为重要的业务逻辑实现上。同时 Jenkins 能实施监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性。Jenkins 还提供了非常丰富的插件支持，这使得 Jenkins 变得越来越强大。我们可以方便的安装各种第三方插件，从而方便快捷的集成第三方的应用。
PMD
静态代码分析工具，通过扫描Java源代码，发现隐藏在其中的各种问题，包括重复代码，日志记录不规范，异常处理不规范，未使用引入的包，支持ant集成。
这里有关于PMD的一些介绍：http://blog.csdn.net/sadamdiyi/article/details/6073694
Checkstyle
提供了一个帮助JAVA开发人员遵守某些编码规范的工具。它能够自动化代码规范检查过程。相比于PMD会更加侧重于编码标准（语法）方面的检查，而PMD是侧重于语义bug。
基于Jenkins快速搭建CI环境
首先要知道一个持续集成环境需要包括三个方面要素：代码存储库、构建过程和持续集成服务器。
?代码存储库一般使用SVN，
1、开始新建一个 Jenkins 项目， 由于我们需要连接 SVN 的代码存储器， 我们选择 Build a free-style software project。
2、然后配置这个 JenkinsTest 项目了，根据实际的 SVN 服务器服务器信息配置 Source Code Management，这能让 Jenkins 知道如何从哪里获取最新的代码。
3、根据开发需要，隔一段时间需要重新构建一次。选择 Build periodically，在 Schedule 中填写 0 * * * *对应的构建时间。
4、添加 build 的步骤了。Jenkins 提供了四个选项供我们选择，可以根据需要执行或调用外部命令和脚本，例如ant、shell、maven等等。这些脚本都是根据需要自己配置的。
5、可以在 Jenkins 中观察构建的进度和最终的状态——成功或者失败。太阳代表之前的构建没有任何失败，蓝色的小球代表构建成功。也可以在JenkinsTest 查看单次构建的 Console 的输出结果。从中能看到构建的第一步是从 SVN 服务器上 check out 代码，然后在build。
具体的可以参考：http://www.ibm.com/developerworks/cn/java/j-lo-jenkins/
后话：其实这就是我在公司实习时所谓的CBD，他们没有使用集成工具，而是直接在服务器上执行CBD脚本，check代码，build构建，deploy部署。