小编说：持续集成，就其最简单的形式来讲，就是一个能监控你版本控制系统变化的工具。无论任何时候，只要检测到有变化，这个工具就会自动编译和测试你的应用程序。如果出现问题，它就马上通知开发人员，以便他们可以立即着手解决这个问题。
本文选自《Jenkins权威指南》，在书中我们将探讨如何使用Jenkins 或者Hudson 来实现一个健壮的和全面的持续集成解决方案
持续集成，也就是通常所说的CI（Continuous Integration），可以说是现代软件开发技术的基础。事实上，它是真正的游戏规则改变者——引进持续集成到公司，能从根本上改变一个团队对于整个软件开发过程的思考方式。它绝对有潜力去启用和触发一系列的增量式的过程改进，从简单的、有计划的、自动化的构建逐渐改进为可以持续交付投入生产中。一个好的持续集成基础设施可以简化开发过程直到部署，可以帮助开发人员更快地检测和修复bug，为所有开发和非开发人员提供一个有用的项目仪表盘，最后帮助团队交付更真实的业务价值给最终用户。每一个专业的开发团队，无论多小，都应该且有必要学习和实践持续集成。
- 持续集成基础
回想在使用持续集成之前的那些充满瀑布项目和甘特图的日子，开发团队的时间和精力都耗费在发布一个版本之前的那段时期里，也就是所谓的集成阶段。在这个阶段，某些开发人员或者小团队做出的代码改动，都会零零散散地整合进最终产品。这可是件有难度的工作，有时甚至仅集成一些冲突性的变更都会消耗数月之久的时间。而且不仅很难去预期会突然出现什么类型的问题，更难的是去修复它们，因为它可能会使你不得不去重写之前已经写了几周或者几个月的代码。这个过程不仅痛苦，而且充满了风险和危险，且往往会导致延迟重要交付、额外开销的后果，最终引来客户的不满。持续集成的出现就是为了定位和解决这些问题。
持续集成，就其最简单的形式来讲，就是一个能监控你版本控制系统变化的工具。无论任何时候，只要检测到有变化，这个工具就会自动编译和测试你的应用程序。如果出现问题，它就马上通知开发人员，以便他们可以立即着手解决这个问题。
持续集成可以做的事情当然还能更多。持续集成能帮你密切监视代码库的健康，自动监控代码质量和代码覆盖率度量，还能帮助你降低技术债务和减少维护成本。这些公开可见的代码质量度量可以使得开发人员为自己开发的高质量代码而自豪，并且激励他们继续努力去改善。结合自动化的端到端的验收测试，持续集成也可以作为一种沟通工具，清晰地发布和展现总体开发工作的当前状态。通过构建自动化部署过程，持续集成能大大简化和加速你的交付过程，自动化和一键部署应用程序的最新版本。
从本质上讲，持续集成是通过提供更快的反馈来降低风险的。首先，它被设计成用来更快地识别和修复集成以及回归相关的问题，目的是更平滑、更快的交付和更少的bug。通过更好地为技术和非技术团队成员提供项目状态的可视化，持续集成打开并改善了团队成员间的沟通渠道，同时鼓励他们协作解决问题和过程改进。通过把部署过程自动化，持续集成可以帮助你更快、更可靠、更轻松地把软件交付到测试人员和最终用户的手上。
自动化部署的想法设计是很重要的。事实上，理论上来讲自动化部署的过程可以使你能够推送每一个带有必要的自动化测试的构建到生产当中去。这种直接自动化部署每个成功的构建到生产当中的实践，就是所谓的持续部署。
单一的持续部署方式并不总是适合每个人。比如，很多用户并不喜欢一周内接二连三地部署新的版本，他们更喜欢一个可预见的（透明的）发布周期。除此之外，在真正部署一个新版本的时候，商业和市场营销也是需要考虑的重要方面。
上述这些持续部署需要考虑的东西，基本也是持续交付所需要考虑的，只是略有不同而已。使用持续交付，任何通过了相关自动化测试和质量关的构建，都能通过完全自动化且一键部署的方式被部署到生产中，并且在几分钟内交付给最终用户。当然，这整个过程并不是自动进行的：它是业务，而不是信息技术，需要决定一个最佳时机来交付最新的变化。
因此，持续集成技术，特别是持续部署和持续交付，就是为了更快地给最终用户提供价值。你的团队从一个小的代码改动到投入生产需要多长时间？这个过程会涉及多少可以提早修复的问题？你了解任何一个团队成员做出的代码修改吗？会让劳动密集型手工测试的QA 团队花费多少时间？会涉及多少手动部署的步骤？大概只有少数人能真正了解上述全部问题。持续集成不是无所不能的，不过它确实能帮助你简化许多这样的问题。
持续集成可以说是一种思维工具集。想要充分地利用好持续集成，你的团队必须要先进入持续集成的思维方式中。例如，你的项目必须有一个可靠的、可重复的、自动化的构建过程，并且不涉及人工干预。能保证优先修复有问题的构建，而不是停滞不前、不管不理。这个部署过程应该是自动化的，不应该有任何的人工干预。由于持续集成服务器可信度的好坏在很大程度上取决于你测试的质量，所以团队需要设计强健的、高质量的测试和测试实践。
- Jenkins（née Hudson）
Jenkins，最开始被称作Hudson，是一个Java 语言编写的开源的持续集成工具。Jenkins在持续集成领域的市场份额居于主导地位，其被各种规模的团队用于各种语言和技术的项目中，比如.NET、Ruby、Groovy、Grails、PHP 等，当然还有Java。是什么使Jenkins 如此成功呢？又为什么你的持续集成基础设施中要使用Jenkins 呢？
首先，Jenkins 是易于使用的。用户界面非常简单、直观，增加了视觉上的吸引力，而且Jenkins 作为一个整体，具有平滑的学习曲线。在其次，Jenkins 拥有良好的扩展性，能够极其灵活和方便地迎合你的想法。它有数以百计的开源插件可供使用，而且每周会有更多的开源插件贡献进来。这些开源插件覆盖系统版本控制、构建工具、代码质量度量、构建通知、外部系统集成、用户界面定制化、游戏等。而且这些插件的安装都非常快捷和简单。
最后，Jenkins 之所以受大众喜欢，得益于其开源社区的规模和活跃度。Jenkins 社区包含一个有规模的、流动的、响应式且开放态的讨论群，活跃的邮件列表，IRC 频道，有知名度的博客区和Twitter 账户。Jenkins 社区的发展速度非常快，每周都会有新功能、新特性，以及bug 修复和插件更新发布出来。
当然，Jenkins 也满足那些不想每周都进行产品升级的用户的需求。对于那些更喜欢尽量减少版本改动的需求，Jenkins 提供一个长期支持的版本，也就是所谓的LTS，这个版本落后于最新发布的Jenkins 版本，却提供更加稳定的功能和较慢的更新变化。LTS 版本每三个月发布一次新版本，新版本主要包含重要的bug 修复和关键补丁。这个概念类似于Ubuntu LTS 版本。
- 应该使用Jenkins 还是Hudson
应该使用Jenkins 还是Hudson 呢？因为这是一篇关于Jenkins 的文章，下面列出一些你可能会选择Jenkins 的原因。
---Jenkins 就是新版的Hudson。事实上，Jenkins 只是简单地给以前的Hudson 换了个新名字，所以如果你喜欢Hudson，那你就应该也喜欢Jenkins ！ Jenkins 使用Hudson 的代码库，开发团队和项目管理保持不变。简而言之，最开始编写了Hudson 核心部分的绝大部分开发人员，只是重新像以前那样在Jenkins 上恢复了他们的工作。
--- Jenkins 社区。就像很多其他成功的开源项目一样，Hudson 的力量来源于它有一个规模庞大的、有流动性的社区以及大规模的应用。bug 的认定（修复）非常快，并且如果你遇到一些问题，别人也可能会遇到和你同样的问题。如果你遇到了自己解决不了的问题，你可以把这个问题发到邮件列表里或者IRC 频道上——一定会有人能帮助你。
---开发速度快。和Hudson一样，Jenkins延续使用众多开发人员喜欢的快速发布周期。每周都会发布新功能、新特性，以及新插件和bug 修复；bug 修复的周转期实际上是非常短的。如果你喜欢更稳定，可以使用LTS 版本。
为了公平起见，下面列出一些你可能更喜欢坚持使用Hudson 的原因。
---除非它坏了，否则你根本不用去修复它。你已经安装部署了一套令你满意的Hudson，并且觉得没有必要升级到最新的版本。
---企业集成以及Sonatype 产品自带工具。Hudson 可能非常看重跟企业级工具的集成，比如LDAP/Active Directory，还有Sonatype 公司的产品，比如Maven 3、Nexus 和 M2Ecipse ；而Jenkins 相对于那些与其有竞争的工具来说却更加开放，比如Artifactor---和Gradle。
---插件体系架构。假如你打算编写自己的Jenkins/Hudson 插件，你要意识到Sonatype 公司正在为Hudson 插件提供JSR-330 依赖项注入。尽管这将来会在Jenkins 和Hudson 之间产生插件兼容性的一系列问题，但对于新的开发人员来讲却是非常易用的。
好消息是，无论你正在使用Jenkins 还是Hudson，它们仍然非常类似，绝大多数在《Jenkins权威指南》中讨论的技术和技巧都适用于两者。事实上，为了说明这一点，本书中的很多截图引用的是Hudson 而不是Jenkins。
