1. 持续集成基础
持续集成:就其最简单的形式来讲，就是一个能监控版本控制系统变化的工具。无论任何时候，只要检测到有变化，这个工具就会自动编译和测试你的应用程序。如果出现问题，它就会马上通知开发人员，以便他们可以立即着手解决这个问题。
当然持续集成可以做的事情还能更多，比如
- 密切监视代码库的健康
- 自动监控代码质量和代码覆盖率
- 降低技术债务和减少维护成本
- 还可以结合插件完成自动化部署等
自动化部署的想法很重要。事实上，理论上来讲自动化部署的过程可以使你能够推送每一个带有必要的自动化测试构建到生产环境中去，这种实践就叫做持续部署。
2.Jenkins简介
Jenkins，最开始被称为Hudson，是一个Java语言编写的开源的持续集成工具。
它拥有以下的好处：
- 首先，Jenkins易于使用。用户界面非常的简单、直观。
- 其次，Jenkins拥有良好的扩展性，能够极其灵活地迎合你的想法。（它拥有很多的插件）
- 最后，Jenkins的社区规模庞大，活跃度也非常的高。
3.引进持续集成到公司的阶段
阶段一：无构建服务器
期初，团队没有任何形式的中央构建服务器。软件实在开发人员的机器上手工进行触发构建的，尽管这个构建可能使用了Maven或者Ant等构件工具。源代码可能存储在一个中央源代码仓库（Git，Svn等）中,但是开发人员不需要定期提交其代码变更。在计划发布一个新的版本之前的那段时间里，开发人员需要手动集成他的代码改动，这个过程非常的痛苦。
阶段二：夜间构建
这个阶段，团体有一个构建服务器，并且会定期（通常是夜间）的按照计划触发自动化构建。但是这个过程只是简单的代码编译，没有可靠的或可重复的单元测试。即使有自动化测试，它也不是强制地要作为构建的一部分，并很可能运行的不正确。在这个阶段开发人员至少会在每天结束后提交代码更新。加入一个开发人员的代码和另一个开发人员的代码发生冲突，构建服务器会在第二天早上通过发送邮件的方式向团队报警。但是这个阶段，开发人员不会立即的修改错误的构建，所以有些构建会一直坏在构建服务器上没人处理。
阶段三：夜间构建加自动化测试
在这个阶段，无论任何时候，只要有代码更新提交到版本控制系统中，构建服务器就会触发一个构建，团队成员可以轻易的看到那些源码变化触发了这个特定的构建。此外，构建运行脚本去编译和运行应用的一系列自动化的测试、集成测试。除了发送邮件，构建服务器也会使用更积极的沟通渠道（比如即使通信）来提醒团队成员在集成的过程中出现的问题。运行失败的构建的构建在这个阶段一般都可以很快地得到修复。
阶段四：加入度量指标
在这个阶段，构建中会运行自动化的代码质量和代码覆盖率检查，来帮助我们检查代码库的质量和测试相关性以及有效性。质量构建也会自动为程序生成API文档。如果代码质量发生下降也会进行警报。同时团队还会建立一个“构建展示器”。
阶段五：更认真的对待测试
持续集成的好处是可以和可靠的测试实践紧密结合。
阶段六：自动化验收测试和自动化部署
这个阶段，测试人员进行测试验收，当测试人员认为可以的时候，就可以手工触发构建来部署一个新的版本去进行用户测试或直接交付到生产环境。如果当前版本出现严重问题，团队还可以使用构建服务器把当前版本回滚到上个版本。