DevOps - 持续集成（Continuous Integration）

最新推荐文章于 2024-09-18 10:01:04 发布

weixin_34362991

最新推荐文章于 2024-09-18 10:01:04 发布

阅读量355

点赞数

文章标签： devops 运维测试

原文链接：http://www.cnblogs.com/anliven/p/10989521.html

版权

持续集成

简介

持续集成（Continuous integration，简称CI）是软件的开发和发布标准流程中最重要的部分。
作为一种开发实践，在CI中可以通过自动化等手段高频率地去获取产品反馈并响应反馈的过程。
简单来说，就是持续不断地（一天多次）将代码合并（集成）到主干源码仓库，让产品可以快速迭代，同时保持高质量。

代码每次集成到主干之前，必须通过自动化测试，以便快速发现和定位错误。
持续集成并不能消除错误，而是让它们非常容易发现和改正。

优点

缩减开发周期，快速迭代版本
　尽早的持续集成，尽快进入迭代之中，就可以尽早的暴露出问题，提早解决，尽量在规定时间内完成任务。
自动化流水线操作带来的高效
CI的精髓在于持续，持续意味着自动化。
　自动化验证代码变更的过程，可以在软件开发的早期发现缺陷和与其他代码和组件的集成问题。
随时可部署
　高频率的集成可以尽可能地保证随时部署上线，缩短开发复杂软件的市场交付时间。
极大程度避免低级错误
　减少大块内容合并到主干分支的情况，避免代码合并冲突和无法预料的行为。
　低级错误：编译错误，安装问题，接口问题，性能问题等。

难点

迁移遗留代码到现有CI系统，需要的投入通常在预料之外
在文化和组织上如果没有采用敏捷原则或DevOps的工作方式，那么很可能没有持续不断的提交，那么CI的存在意义不大
随着业务增长、工具的更替、技术的演进，CI系统也必然随之改动，往往会导致阶段性的不稳定和人力物力的耗费
如果CI的基本设定不到位，开发流程将会增加特别的开销

注意点

CI流程的触发方式：

跟踪触发式：在每次提交到源码版本管理系统时触发
计划任务：预配置好的计划，例如一次凌晨的构建
手动：无论是通过CI服务器的管理界面还是脚本，用户可以手工执行CI工作流

代码审核

可在持续集成服务器里使用代码分析工具（例如Sonar）来执行自动代码审查
自动代码审查通过后，可发起一个人工代码审查，揪出那些自动审查无法找出的问题，即验证业务需求，架构问题，代码是否可读，以及是否易于扩展。
可灵活配置代码审核策略，例如：如果某些人没有审查代码便阻止对主干分支的任何提交。
最常用的工具是Gerrit

CI流程

典型的CI流程

一个完整的CI系统应该包含3个基本模块：

一个可以自动构建的过程，自动编译代码，可以自动分发，部署和测试。
一个代码仓库，例如Git。
一个持续集成的服务器。

通用的CI流程

签出代码：
从源码管理系统里签出或者克隆最新的代码到本地开发环境
提交（commit）：
基于主干分支创建一个新的功能分支，并在此分支编写代码，并向仓库提交代码
测试（第1轮）：
代码仓库对commit操作配置了钩子（hook），每一次提交代码都会触发测试
单元测试（针对函数或模块的测试）和功能测试（集成测试）将会被执行、根据需要设置是否执行端对端测试
一般来说，这些测试也会被打包到代码里。
构建（build）：
通过测试（第1轮）后，将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源等
实现一个CI流程的唯一必要条件便是得有一个自动构建系统。
源代码一般是自包含构建的，即CI流程所需的构建脚本是放在源码仓库里的。
测试（第2轮）：
以自动化为主的全面测试，包括单元测试和集成测试，必要时做端对端测试，确保新版本的每一个更新点都必须测试到
合并：
通过测试（第2轮）后，将代码更新集成到主干
回滚：
如果当前版本发生问题，就回滚到上一个版本的构建结果
一般来说，CI服务器会配置成在遇到故障时发送邮件相关人员，可以快速知晓故障并且尽快采取更正措施。