持续集成(Continuous integration,简称CI)是软件的开发和发布标准流程中最重要的部分。
做为一种开发实践,在CI中能够经过自动化等手段高频率地去获取产品反馈并响应反馈的过程。
简单来讲,就是持续不断地(一天屡次)将代码合并(集成)到主干源码仓库,让产品能够快速迭代,同时保持高质量。html
代码每次集成到主干以前,必须经过自动化测试,以便快速发现和定位错误。
持续集成并不能消除错误,而是让它们很是容易发现和改正。git
缩减开发周期,快速迭代版本
尽早的持续集成,尽快进入迭代之中,就能够尽早的暴露出问题,提前解决,尽可能在规定时间内完成任务。web
自动化流水线操做带来的高效
CI的精髓在于持续,持续意味着自动化。
自动化验证代码变动的过程,能够在软件开发的早期发现缺陷和与其余代码和组件的集成问题。服务器
随时可部署
高频率的集成能够尽量地保证随时部署上线,缩短开发复杂软件的市场交付时间。架构
极大程度避免低级错误
减小大块内容合并到主干分支的状况,避免代码合并冲突和没法预料的行为。
低级错误:编译错误,安装问题,接口问题,性能问题等。函数
一个完整的CI系统应该包含3个基本模块:工具
签出代码:
从源码管理系统里签出或者克隆最新的代码到本地开发环境gitlab
提交(commit):
基于主干分支建立一个新的功能分支,并在此分支编写代码,并向仓库提交代码性能
测试(第1轮):
代码仓库对commit操做配置了钩子(hook), 每一次提交代码都会触发测试
单元测试(针对函数或模块的测试)和功能测试(集成测试)将会被执行、根据须要设置是否执行端对端测试
通常来讲,这些测试也会被打包到代码里。单元测试
构建(build):
经过测试(第1轮)后,将源码转换为能够运行的实际代码,好比安装依赖,配置各类资源等
实现一个CI流程的惟一必要条件即是得有一个自动构建系统。
源代码通常是自包含构建的,即CI流程所需的构建脚本是放在源码仓库里的。
测试(第2轮):
以自动化为主的全面测试,包括单元测试和集成测试,必要时作端对端测试,确保新版本的每个更新点都必须测试到
合并:
经过测试(第2轮)后,将代码更新集成到主干
回滚:
若是当前版本发生问题,就回滚到上一个版本的构建结果
通常来讲,CI服务器会配置成在遇到故障时发送邮件相关人员,能够快速知晓故障而且尽快采起更正措施。
Continuous integration (CI) 与test-driven development (TDD)结合,分红了12个步骤: