Jenkins持续集成 解决的是什么问题？

01、持续集成的定义

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

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

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

每次集成都通过自动化的构建 (包括编译、发布和自动化测试) 来验证, 从而尽快的发现集成错误. 许多团队都发现这个过程可以大大减少代码集成的问题, 让团队更快的开发内聚的软件.

请注意, 持续集成不等于持续编译.

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

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

• 项目一开始是先划分好模块，分配模块给相应的开发人员；

• 开发人员开发好一个模块就进行单元测试；

• 等所有的模块都开发完成之后，由项目经理对所有代码进行集成；

• 集成后的项目由项目经理部署到测试服务器上，被交由测试人员进行集成测试；

• 测试过程中出现 Bug 就提把问题记录进行 Bug 列表中；

• 项目经理分配 Bug 给相应的责任人进行修改；

• 修改完成后，项目经理再次对项目进行集成，并部署到测试服务器上；

• 测试人员在下一次的集成测试中进行回归测试；

• 通过通过之后就部署到生产环境中；

• 如果测试不通过，则重复上述“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试”工作。

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

• Bug 总是在最后才发现

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

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

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

• 软件交付时机无法保障

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

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

• 程序经常需要变更

某些项目, 程序会经常需要变更. 由于产品经理在与客户交流过程中, 往往实际的软件就是最好的原型, 所以软件会被当作原型作为跟客户交流的工具. 当然, 客户最希望的当然是客户的想法能够马上反映到原型上, 这会导致程序会经常被修改的. 那么也就意味着“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试”工作无形又爆增了.

• 无效的等待变多

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

• 用户的满足度低

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

03、怎么样才算是“持续”

对于一天需要集成多少次数, 并没有一个明确的定义. 一般就是按照自己项目的实际需要来设置一定的频率, 少则可能几次, 多则可能达几十次. 可以设置按照代码的变更来触发集成, 或者设置一个固定时间周期来集成, 也可以手工点击集成的按钮来 “一键集成”.

持续集成的工作流程

• 当开始更改代码时，开发人员会从代码库（如 SVN、Git 等）获取当前代码库的副本.

• 当其他开发人员将更改的代码提交到代码库时, 此副本将逐渐停止反映代码库中的代码. 代码分支保持检出的时间越长, 当开发人员分支重新集成到主线时, 多个集成冲突和故障的风险就越大.

• 当开发人员向代码库提交代码时, 他们必须首先更新他们的代码, 以反映代码库中的最新更改.

• 当存储库与开发人员的副本不同, 他们必须要花时间来先处理冲突.

04、持续集成的好处

• 解放了重复性劳动

自动化部署工作可以解放了集成、测试、部署等重复性劳动, 而且机器集成的频率明显可以比手工的高很多.

• 更快地修复问题

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

• 更快地交付成果

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

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

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

• 减少手工的错误

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

• 减少了等待时间

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

• 更高的产品质量

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

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走！ 

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。