持续集成 Jenkins 简介

持续集成的定义

大师 Martin Fowler 是这样定义持续集成的: 持续集成是一种软件开发实战, 即团队开发成员常常集成他们的工做. 一般, 每一个成员天天至少集成一次, 也就意味着天天可能发生屡次集成.

持续集成并不能消除Bug, 而是让它们很是容易发现和改正.

根据对项目实战的理解, 持续集成中的 "持续" 是指不间断的; "集成" 可分为广义和狭义, 广义的集成指软件各个过程的集成, 包括开发、部署、测试等. 狭义的集成即代码和代码之间的集成, 从而保证代码合并不冲突.

每次集成都经过自动化的构建 (包括编译、发布和自动化测试) 来验证, 从而尽快的发现集成错误. 许多团队都发现这个过程能够大大减小代码集成的问题, 让团队更快的开发内聚的软件. 请注意, 持续集成不等于持续编译.

当前软件开发过程存在的问题

在没有应用持续集成以前，传统的开发模式是这样的：

• 项目一开始是先划分好模块，分配模块给相应的开发人员；
• 开发人员开发好一个模块就进行单元测试；
• 等全部的模块都开发完成以后，由项目经理对全部代码进行集成；
• 集成后的项目由项目经理部署到测试服务器上，被交由测试人员进行集成测试；
• 测试过程当中出现 Bug 就提把问题记录进行 Bug 列表中；
• 项目经理分配 Bug 给相应的责任人进行修改；
• 修改完成后，项目经理再次对项目进行集成，并部署到测试服务器上；
• 测试人员在下一次的集成测试中进行回归测试；
• 经过经过以后就部署到生产环境中；
• 若是测试不经过，则重复上述“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试”工做。

这个过程当中可能会出现以下问题:

Bug 老是在最后才发现

随着软件技术的发展, 软件规模也在扩大, 软件需求愈来愈复杂, 软件已经不能简单地经过划分模块的方式来开发, 每每须要在项目内部互相合做, 模块之间存在必定的依赖关系, 那么早期就存在的 Bug 每每会在最后集成的时候才被发现.

越到项目后期, 问题越难解决

不少开发者须要在集成阶段花费大量的时间来寻找 Bug 的根源, 加上软件的复杂性, 问题的根源很难定位. 并且咱们都清楚, 间隔的时间越久, Bug 修复的成本越高, 由于连开发人员本身都忘了当初写得是什么鬼代码, 从而不得不从头阅读代码、理解代码.

软件交付时机没法保障

正是由于咱们没法及时修复 Bug, 或者是没能在早期就修复 Bug, 从而令整个修复 Bug 的周期拉长了. 无论怎么样, 咱们不可能把明知存在 Bug 的软件交付给客户.

并且, 大量没有在前期预估到的工做量产生了——开发人员不得不花费大把时间在查找 Bug 上; 测试人员不断的须要进行回归测试; 项目经理不得不疲命于该死的代码的集成、部署这些重复性工做——最终致使整个项目的周期拉长, 交付时间点日后拖.

程序常常须要变动

某些项目, 程序会常常须要变动. 因为产品经理在与客户交流过程当中, 每每实际的软件就是最好的原型, 因此软件会被看成原型做为跟客户交流的工具. 固然, 客户最但愿的固然是客户的想法可以立刻反映到原型上, 这会致使程序会常常被修改的. 那么也就意味着“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试”工做无形又爆增了.

无效的等待变多

有可能开发在等集成其余人的模块; 测试人员在等待开发人员修复 Bug; 产品经理在等待新版本上线好给客户作演示; 项目经理在等待其余人提交代码. 无论怎么样, 等待意味低效.

用户的知足度低

这里的用户是广义的, 能够指最终的客户, 也能够是产品经理、公司领导、测试人员, 甚至多是开发人员本身. 你想一想看, 原本三个月作完的项目被拉长到了九个月甚至一年, 用户能满意吗! 产品经理、公司领导常常须要拿项目做为演示的原型, 结果告诉我在演示前一刻发现还有不少 Bug 没有解决, 项目启动不了没法访问, 这叫人情何以堪.

怎么样才算是“持续”

对于一天须要集成多少次数, 并无一个明确的定义. 通常就是按照本身项目的实际须要来设置必定的频率, 少则可能几回, 多则可能达几十次. 能够设置按照代码的变动来触发集成, 或者设置一个固定时间周期来集成, 也能够手工点击集成的按钮来 “一键集成”.

持续集成的工做流程

• 当开始更改代码时，开发人员会从代码库（如 SVN、Git 等）获取当前代码库的副本.
• 当其余开发人员将更改的代码提交到代码库时, 此副本将逐渐中止反映代码库中的代码. 代码分支保持检出的时间越长, 当开发人员分支从新集成到主线时, 多个集成冲突和故障的风险就越大.
• 当开发人员向代码库提交代码时, 他们必须首先更新他们的代码, 以反映代码库中的最新更改.
• 当存储库与开发人员的副本不一样, 他们必需要花时间来先处理冲突.

持续集成的好处

解放了重复性劳动

自动化部署工做能够解放了集成、测试、部署等重复性劳动, 并且机器集成的频率明显能够比手工的高不少.

更快地修复问题

因为持续集成更早的获取变动, 更早的进入测试, 也就能更早的发现问题, 解决问题的成本显著降低.

更快地交付成果

及早集成、及早测试减小了缺陷遗留到部署环节的机会. 在某些状况下, 更早地查找错误还会减小解决错误所需的工做量.

若是集成服务器对代码进行构建过程当中发现错误, 能够及时发送邮件或者短信提供给开发人员进行修复.

若是集成服务器在部署环节发现当前版本有问题不可用, 集成服务器会将部署回退到上一个版本. 这样服务器上始终都会有一个可用的版本.

减小手工的错误

人与机器的一个最大的区别是, 在重复性动做上, 人容易犯错, 而机器犯错的概率几乎为零. 因此, 当咱们搭建完成集成服务器后, 之后的事就交给集成服务器来打理吧.

减小了等待时间

持续集成缩短了从开发、集成、测试、部署各个环节的时间, 从而也就缩短了中间能够出现的等待时间. 持续集成, 意味着开发、集成、测试、部署也得以持续.

更高的产品质量

集成服务器每每提供 Code review、代码质量检测等功能. 对代码不规范或者有错误的地方会进行标识, 也能够设置邮件、短信等进行告警. 而开发人员经过 Code review 也能够持续提升编程的能力.