CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案,CI/CD 主要针对在集成新代码时所引发的问题(亦称: 集成地狱
)。持续交付的目的就是确保尽可能减少部署新代码时所需的工作量
集成地狱是指交付团队中的成员集成其各自的代码时的生产点。在传统的软件开发环境中,这种集成过程很少是平滑且无缝的,而是需要花费数小时甚至数天的时间来修复代码,以便最终进行集成。持续集成(CI)旨在通过鼓励和鼓励团队成员进行频繁集成(例如每小时或至少每天一次)来完全避免这种情况。
GitLab CI/CD
GitLab CI/CD(后简称 GitLab CI)是一套基于 GitLab 的 CI/CD 系统,可以让开发人员通过 .gitlab-ci.yml
在项目中配置 CI/CD 流程,在提交后,系统可以自动/手动地执行任务,完成 CI/CD 操作。而且,它的配置非常简单,CI Runner 由 Go 语言编写,最终打包成单文件,所以只需要一个 Runner 程序、以及一个用于运行 jobs 的执行平台( 如裸机+SSH ,Docker 或 Kubernetes 等,我推荐用 Docker,因为搭建相当容易 )即可运行一套完整的 CI/CD 系统。
基本概念:
- Job
- Job 为任务,是 GitLab CI 系统中可以独立控制并运行的最小单位。
- 在提交代码后,开发者可以针对特定的 commit 完成一个或多个 job,从而进行 CI/CD 操作。
- Pipeline
- Pipeline 即流水线,可以像流水线一样执行多个 Job.
- 在代码提交或 MR 被合并时,GitLab 可以在最新生成的 commit 上建立一个 pipeline,在同一个 pipeline 上产生的多个任务中,所用到的代码版本是一致的。
- Stage
- 一般的流水线通常会分为几段;在 pipeline 中,可以将多个任务划分在多个阶段中,只有当前一阶段的所有任务都执行成功后,下一阶段的任务才可被执行。
注:如果某一阶段的任务均被设定为“允许失败”,那这个阶段的任务执行情况,不会影响到下一阶段的执行。
流程配置
文件配置
GitLab 允许在项目中编写 .gitlab-ci.yml
文件,来配置 CI/CD 流程。
我们来编写一个简单的测试→构建→部署的 CI/CD 流程。
首先,可以定义流程所包含的阶段。我们的流程包含三个阶段:测试、构建和部署。
在 .gitlab-ci.yml
的开头,定义好所有阶段、以及执行每个任务之前所需要的环境变量以及准备工作,然后定义整个流程中包含的所有任务:
在每个任务中,通常会包含 image
, stage
,services
, script
等字段。
dingtalk:ok:
stage: notification
image: python:3.6
script:
- export PIP_INDEX_URL='https://www.example.com'
- pip install requests
- wget https://www.example.com/dingtalk.py
- export PIPELINE_RESULT=OK
- python dingtalk.py
when: on_success
only:
- /^dev\/.*$/
- /^test\/.*$/
- /^staging$/
dingtalk:error:
stage: notification
image: python:3.6
script:
- export PIP_INDEX_URL='https://pypi.tuna.tsinghua.edu.cn/simple'
- pip install requests
- wget https://www.example.com/dingtalk.py
- export PIPELINE_RESULT=ERROR
- python dingtalk.py
when: on_failure
only:
- /^dev\/.*$/
- /^test\/.*$/
- /^staging$/
stage
定义了任务所属的阶段;image
字段指定了执行任务时所需要的 docker 镜像;services
指定了执行任务时所需的依赖服务 (如数据库、Docker 服务器等)script
直接定义了任务所需执行的命令。
困了,暂时太监了