持续集成
持续集成（Continuous integration，简称CI）是软件的开发和发布标准流程中最重要的部分。
简单来说，就是持续不断地（一天多次）将代码合并（集成）到主干源码仓库，让产品可以快速迭代，同时保持高质量。
代码每次集成到主干之前，必须通过自动化测试，以便快速发现和定位错误。
持续集成并不能消除Bug，而是让它们非常容易发现和改正。
典型的CI流程
通用的CI流程
- 签出代码：
从源码管理系统里签出或者克隆最新的代码到本地开发环境 - 提交（commit）：
基于主干分支创建一个新的功能分支，并在此分支编写代码，并向仓库提交代码 - 测试（第1轮）：
代码仓库对commit操作配置了钩子（hook）， 每一次提交代码都会触发测试
单元测试（针对函数或模块的测试）和功能测试（集成测试）将会被执行、根据需要设置是否执行端对端测试
一般来说，这些测试也会被打包到代码里。 - 构建（build）：
通过测试（第1轮）后，将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源等
实现一个CI流程的唯一必要条件便是得有一个自动构建系统。
源代码一般是自包含构建的，即CI流程所需的构建脚本是放在源码仓库里的。 - 测试（第2轮）：
以自动化为主的全面测试，包括单元测试和集成测试，必要时做端对端测试，确保新版本的每一个更新点都必须测试到 - 合并：
通过测试（第2轮）后，将代码更新集成到主干 - 回滚：
如果当前版本发生问题，就回滚到上一个版本的构建结果
一般来说，CI服务器会配置成在遇到故障时发送邮件相关人员，可以快速知晓故障并且尽快采取更正措施。
注意点
CI流程的触发方式：
- 跟踪触发式：在每次提交到源码版本管理系统时触发
- 计划任务：预配置好的计划，例如一次凌晨的构建
- 手动：无论是通过CI服务器的管理界面还是脚本，用户可以手工执行CI工作流
代码审核：
- 可在持续集成服务器里使用代码分析工具（例如Sonar）来执行自动代码审查
- 自动代码审查通过后，可发起一个人工代码审查，揪出那些自动审查无法找出的问题，即验证业务需求，架构问题，代码是否可读，以及是否易于扩展。
- 可灵活配置代码审核策略，例如：如果某些人没有审查代码便阻止对主干分支的任何提交。
- 最常用的工具是Gerrit
优点
- 自动化验证代码变更的过程
- 在软件开发的早期发现缺陷和与其他代码和组件的集成问题
- 自动化测试代码，提升代码质量的提升
- 缩短开发复杂软件的市场交付时间
- 减少大块内容合并到主干分支的情况，避免代码合并冲突和无法预料的行为
难点
- 迁移遗留代码到现有CI系统，需要的投入通常在预料之外
- 在文化和组织上如果没有采用敏捷原则或DevOps的工作方式，那么很可能没有持续不断的提交，那么CI的存在意义不大
- 随着业务增长、工具的更替、技术的演进，CI系统也必然随之改动，往往会导致阶段性的不稳定和人力物力的耗费
- 如果CI的基本设定不到位，开发流程将会增加特别的开销
参考消息
- 仅需一篇，妥妥吃透“持续集成”
- [持续交付实践] pipeline 使用之快速入门
- 使用gitlab, jenkins搭建CI（持续集成)系统
- 准备环境：https://www.cnblogs.com/brandonli/p/8367251.html
- 配置webhook触发构建：https://www.cnblogs.com/brandonli/p/8395015.html
- 根据不同触发条件执行不同的构建任务：https://www.cnblogs.com/brandonli/p/8395116.html
- 灰度发布publish：https://www.cnblogs.com/brandonli/p/8592867.html
原文地址：https://www.cnblogs.com/anliven/p/10989521.html
时间： 2024-07-31 23:51:23