标签：源码   验证   部分   版本   pip   集成测试   开发流程   搭建   相关   

持续集成

持续集成（Continuous integration，简称CI）是软件的开发和发布标准流程中最重要的部分。
简单来说，就是持续不断地（一天多次）将代码合并（集成）到主干源码仓库，让产品可以快速迭代，同时保持高质量。

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

典型的CI流程

通用的CI流程

1. 签出代码：
   从源码管理系统里签出或者克隆最新的代码到本地开发环境

2. 提交（commit）：
   基于主干分支创建一个新的功能分支，并在此分支编写代码，并向仓库提交代码

3. 测试（第1轮）：
   代码仓库对commit操作配置了钩子（hook）， 每一次提交代码都会触发测试
   单元测试（针对函数或模块的测试）和功能测试（集成测试）将会被执行、根据需要设置是否执行端对端测试
   一般来说，这些测试也会被打包到代码里。

4. 构建（build）：
   通过测试（第1轮）后，将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源等
   实现一个CI流程的唯一必要条件便是得有一个自动构建系统。
   源代码一般是自包含构建的，即CI流程所需的构建脚本是放在源码仓库里的。

5. 测试（第2轮）：
   以自动化为主的全面测试，包括单元测试和集成测试，必要时做端对端测试，确保新版本的每一个更新点都必须测试到

6. 合并：
   通过测试（第2轮）后，将代码更新集成到主干

7. 回滚：
   如果当前版本发生问题，就回滚到上一个版本的构建结果
   一般来说，CI服务器会配置成在遇到故障时发送邮件相关人员，可以快速知晓故障并且尽快采取更正措施。

注意点

CI流程的触发方式：

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

代码审核：

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

优点

• 自动化验证代码变更的过程
• 在软件开发的早期发现缺陷和与其他代码和组件的集成问题
• 自动化测试代码，提升代码质量的提升
• 缩短开发复杂软件的市场交付时间
• 减少大块内容合并到主干分支的情况，避免代码合并冲突和无法预料的行为

难点

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

参考消息

• 仅需一篇，妥妥吃透“持续集成”
• [持续交付实践] pipeline 使用之快速入门
• 使用gitlab, jenkins搭建CI（持续集成)系统
  1. 准备环境：https://www.cnblogs.com/brandonli/p/8367251.html
  2. 配置webhook触发构建：https://www.cnblogs.com/brandonli/p/8395015.html
  3. 根据不同触发条件执行不同的构建任务：https://www.cnblogs.com/brandonli/p/8395116.html
  4. 灰度发布publish：https://www.cnblogs.com/brandonli/p/8592867.html

DevOps - 持续集成（Continuous Integration）

标签：源码   验证   部分   版本   pip   集成测试   开发流程   搭建   相关   

原文地址：https://www.cnblogs.com/anliven/p/10989521.html