持续集成(Continuous Integration, CI)的基本概念

概述

在传统软件的开发中,代码的集成工作通常是在所有人都将工作完成后在项目即将结束进行时,而这往往会花费大量的时间和精力。而持续集成是一种将集成阶段放在软件开发阶段的做法,以便更加有规律地构建,测试和集成代码。

“持续集成并不能消除 Bug,而是让它们非常容易发现和改正。”

持续集成可以在开发人员提交了新代码后,立刻进行构建、单元测试。从而我们可以根据测试结果以确定新的代码或者环境配置与原来的以及其他开发人员的代码或者环境配置能否正确地集成在一起。

持续交付 & 持续部署#

持续交付(Continuous Delivery):频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。

持续部署(Continuous Deployment):是持续交付的下一步,指的是代码评审以后,自动部署到生产环境。

GitLab 持续集成起步

.gitlab-ci.yml

.gtilab-ci.yml文件存放与项目于仓库的根目录,用以来定义 GitLab CI/CD 中的 Pipeline其实无非是一个配置文件,理解起来挺简单的,我们主要是需要了解 Pipeline 的概念以及如何配置一个 .gitlab-ci.yml

Pipeline & Stages & Jobs

一个 Pipeline 大概相对于一个构建任务,里面可以包含多个流程,如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程,Git 提交时会触发 Pipeline。而一个 Pipeline 中又可以包含一至多个 Stage,即用来定义安装依赖、运行测试之类的流程的。然后,一个 Stage 中又包含了一至多个 Job,Jobs 表示一个 Stage 中具体的构建工作,即某个 Stage 里面执行的工作。我们可以在 Stages 里面定义这些 Job,它们之间的关系如下图所示:

注意:

  • Stages 会按 .gitlab-ci.yml 中配置的顺序执行,当前面的 Stage 执行完毕后才会继续执行后面的 Stage,如果一个 Stage 失败,那么后面的 Stage 不会执行,该构建任务失败。
  • Stage 中的 Jobs 会并行执行,当这个 Stage 中所有的 Job 都执行完毕,该 Stage 才算执行成功。换而言之,只要有一个 Job 执行失败,整个 Pipeline 也就失败了。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Copystages:
- build
- test
- deploy

build:
stage: build
script:
- "execute-script-for-build"
- "do something...""
only:
- master
tags:
- ruby
- postage

test:
stage: test
script:

......

上面配置将一次 pipeline 分成了三个阶段:build、test、deploy。下面介绍配置文件中的节点:

  • stages: 定义构建的阶段;
  • build、test、…:定义 jobs_name,即在 stages 中定义的 stage 阶段,一般在 stage 节点注明所属的 stage;
  • script:Runner 执行的脚本或命令,该节点是必须的。
  • 其他节点:stage 中还有许多其他节点,例如 only、tags 等,但并不是 required ,其具体作用可在文档中了解

pipline

GitLab Runner

当我们理解完上面的概念后,我们还没了解最重要的东西——上面的任务由谁来构建呢?答案就是 Gitlab-runner 了!

为什么不用 GitLab CI 来运行这些构建任务呢?

一般来说,构建任务任务都会占用很多的系统资源(譬如编译代码),而 GitLab CI 又是 GitLab 的一部分,如果由 GitLab CI 来运行构建任务的话,在执行构建任务的时候, GitLab 的性能会大幅下降。

GitLab CI 最大的作用是管理各个项目的构建状态,因此,运行构建任务这种浪费资源的事情就交给 GitLab Runner 来做啦!

因为 GitLab Runner 可以安装到不同的机器上,所以在构建任务运行期间并不会影响到 GitLab 的性能。

Runner安装

1
2
3
4
5
6
7
8
# 添加yum源
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash

# 安装runner
yum install gitlab-ci-multi-runner

# 向GitLab-CI注册runne
gitlab-ci-multi-runner register

向GitLab-CI注册一个Runner需要两样东西:GitLab-CI的url和注册token。
 其中,token是为了确定你这个Runner是所有工程都能够使用的Shared Runner还是具体某一个工程才能使用的Specific Runner。
 如果要注册Shared Runner,你需要到管理界面的Runners页面里面去找注册token。

持续集成的实现

  1. 仓库中添加 .gitlab-ci.yml文件,提交代码
  2. 注册Runner,在项目CI/CD 可以看到 url,和token
  3. 查看项目的 Pipelines
  4. 项目Readme中可以添加标识,查看构建状态

tag

参考文章

https://www.cnblogs.com/jojop/p/11409075.html

https://blog.csdn.net/lizhiqiang1217/article/details/88803783

https://docs.gitlab.com/ee/ci/yaml/