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 也可以连续进步编程的能力
最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取 【保证100%免费】
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战堆栈，这个堆栈也伴随上万个测试工程师们走过最艰巨的路程，希望也能资助到你！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
