第一章 GitLab CI/CD 核心概念

GitLab CI/CD 系列

第一章 GitLab CI/CD 核心概念

---

前言

传统应用发布模式介绍：

开发团队：在开发环境中完成软件的开发，单元测试，测试通过后将代码提交到代码版本管理库。
运维团队：将应用部署于测试环境，供QA团队测试，测试完成之后应用部署于正式环境。
QA团队（测试）：主要负责项目测试工作，测试通过之后通知部署人员更新发布应用到正式环境

传统应用发布模式存在的问题：

错误发现不及时：很多错误项目中早期可能就存在一些问题，到最后集成的时候才被发现。
人工低级错误易发生：产品和服务交付过程中全部采用人工手动进行操作，难免会出现低级错误。
团队工作效率低：需要等待他人完成工作之后才能进行自己的工作。
开发运维对立：开发人员追求的是快速更新，而运维人员是要保障平台的稳定运行，各自针对的方向不同。

所以 CI/CD 应运而生。

一、CI/CD 概念

通过软件开发的持续方法，从而实现持续构建、测试和部署迭代代码更改。这个迭代过程减少了基于错误或失败的先前版本开发新代码的机会。使用这种方法，从开发新代码到部署，减少人为干预，甚至完全不干预。

1、持续集成（CI）

一个应用程序，它的代码部署在 GitLab 存储库。开发每天会多次推送代码更改。对于每次推到存储库的动作，我们可以创建一组脚本来自动完成代码的构建和测试工作。这种方式减少了在应用程序中引入错误的机会。
这就是持续集成，项目代码的每次提交更改，甚至是提交给开发分支的更改。都会自动触发自动构建和测试。

2、持续交付、持续部署（CD）

每次提交代码触发持续集成，这个只是完成了代码的构建和测试工作，下一步还会触发持续部署应用程序，通过持续交付，可以手动触发部署。持续部署跟持续交付类似，不同之处在于无需手动部署应用，而将其设置为自动部署，不需要人为干预。

二、 GitLab CI/CD 与 Jenkins

1、Jenkins

Jenkins是一款开源 CI&CD 软件，用于自动化各种任务，包括构建、测试和部署软件，可以很好的支持各种语言的项目构建。经过这么多年的技术积累，Jenkins 目前是市场上主流的持续集成软件，大部分公司都在使用。

2、GitLab CI/CD

GitLab-CI 是 Gitlab8.0之后自带的一个持续集成系统，中心思想是当每一次 push (提交代码)到 GitLab 的时候，都会触发一次脚本运行，脚本内容包括了测试、编译、部署等一系列的自定义内容。在所有用于测试的 CI/CD 工具中，GitLab CI/CD 毫无疑问是最新且最受赞赏的选择。

3、GitLab CI 与 Jenkins 优缺点

（1）Jenkins

优点

大量插件库
自托管，例如对工作空间的完全控制
容易调试运行，由于对工作空间的绝对控制
容易搭建节点
容易部署代码
非常好的凭证管理
非常灵活多样的功能
支持不同的语言
非常直观

缺点

插件集成复杂，体量较大，不适合小型团体
对于比较小的项目开销比较大，因为需要自己搭建
缺少对整个 pipeline 跟踪的分析

（2）GitLab CI/CD

优点

轻量级，不需要复杂的安装手段
配置简单，与 GitLab 直接适
更好的 Docker 集成
运行程序扩展或收缩比较简单
实时构建日志十分情绪，UI 交互体验感好
使用 YAML 进行配置，任何时候都可以方便使用
阶段内的作业并行执行
有向无环图 pipeline 的机会
由于并发运行程序而非常易于扩展收缩
合并请求集成
容易添加作业
容易处理冲突问题
良好的安全和隐私政策

缺点

需要为每个作业定义构建并上传 / 下载
在实际合并发生之前测试合并状态是不可能的
还不支持细分阶段
没有统一的管理界面，无法统筹管理所有项目

（3）GitLab CI/CD vs Jenkins 如何选择

Jenkins 与 GitLab CI/CD 都有各自的优缺点，两个工具目前都是市场上主流的，最终的选择要取决于项目的需求和规格。其中每一个 CI/CD 工具都有它自身的优势和劣势，发布也都实现了完全相同的需求：自动化 CI/CD（持续集成和交付）的过程。Jenkins 用于持续集成，而 GitLab CI/CD 用于代码协作和版本控制。在选择最佳的用于 DevOps 测试的 CI/CD 工具时，GitLab CI/CD 是最好的选择。

三、GitLab CI/CD 组件介绍

1、GitLab CI/CD

• GitLab 的一部分，GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的Web服务。简单理解 GitLab 就是一个代码版本管理库，用于存放和管理代码。 除了 GitLab的所有功能之外，可用于所有持续方法（持续集成、交付和部署）。
• 使用GitLab CI/CD，可以测试、构建和发布应用程序，而无需第三方应用程序或集成。

2、GitLab Runner

• GitLab Runner 是一个与开源项目，与 GitLab CI/CD 一起使用以在管道中运行作业的应用程序。
• GitLab Runner 类似于 Jenkins 的 agnet，执行 CI 持续集成、构建的脚本任务。

四、GitLab CI/CD 工作流程

简单的描述一下 CI/CD 的工作流程

1、准备工作

注册GitLab Runner：主要用于运行流水线作业，并将结果返回给 GitLab。
创建流水线作业文件：默认为一般存放在项目的根目录下，取名为.gitlab-ci.yml文件，主要用于定义需要运行的作业任务。

2、工作流程

开发人员提交代码到 GitLab 项目仓库，Gitlab 根据项目中的 .gitlab-ci.yml 配置文件要求触发 Runner 流水线任务。一般在.gitlab-ci.yml 文件中会定义一个完整的作业流程：build (构建应用程序)–>test (测试运行程序)–> deploy (部署应用程序) 。这样，我们一个简单的 Gitlab CI/CD 流水线就已经运行完毕。

总结

GitLab CI/CD 是最受欢迎的用于 DevOps 测试的 CI/CD 工具之一。GitLab CI/CD 文档丰富、易于控制且用户体验好。GitLabCI有助于DevOps人员，例如敏捷开发中，开发与运维是同一个人，这是最便捷的开发方式。目前我一直在有针对学习 GitLab CI/CD ，后期会有序的将此功能引用到公司的测试环境和正式环境中去，从而优化现有的工作流程，提高工作效率。