思路梳理

下图是GitLab-ci的实现结构图：

(实际结构会有出入，画成这样只是便于理解)

GitLab:是一个基于 Git 的代码托管平台，提供了代码仓库管理、问题跟踪、CI/CD 等功能。它可以用于团队协作开发、版本控制、代码审查等场景。
GitLab-runner:是一个 GitLab 的插件，用于在多个服务器上运行 CI/CD 任务。它可以将 GitLab 中的 CI/CD 任务分配到不同的服务器上执行，从而提高构建速度和可靠性。
Git:是一个分布式版本控制系统，用于管理代码的版本和变更。它支持分支管理、合并、提交等功能，可以帮助开发者协同工作和管理代码库。

一、前期准备

搭建GitLab

1、下载并安装Gitlab社区版软件：gitlab-ce-11.2.0-ce.0.el7.x86_64.rpm

[root@server1 ~]# ls
gitlab-ce-11.2.0-ce.0.el7.x86_64.rpm
[root@server1 ~]# yum install gitlab-ce-11.2.0-ce.0.el7.x86_64.rpm -y   
#安装GitLab社区版。ce表示社区版,ee表示企业版

2、编辑配置文件/etc.gitlab/gitlab.rb

[root@server1 ~]# vim /etc/gitlab/gitlab.rb 13 external_url 'http://xx.xx.xx.xx'   #访问gitlab的地址
[root@server1 ~]# gitlab-ctl reconfigure   #重载服务,过程较长耐心等待

下图是一个安装好的GitLab示意图：

建立一个新项目：

点击new Project建立新项目我这里建立了一个项目叫test-CI/CD

查看项目详情页的Settings->CI/CD->Runners 记录下Runner的配置

这里的Runner分为两种，一种是Specific Runner 另一种是Shared Runner

Specific Runner只能被当前项目使用，在这里就是只能被我刚才创建的test-CICD项目使用

Shared Runner 可以在这个项目所在的GitLab示例上共享。

这里我们主要需要复制下url（标记了GitLab的地址）和token (确定是哪个项目)

搭建GitLab-Runner

首先 GItLab-Runner要依赖Git

我们先 Git -v查看Git的版本号，如果低于2.30.1 建议升级为2.30.1以上的版本，不然执行中可能报错。

确保Git版本号已经达到要求后，可以开始GItlab-Runner的搭建：

现在服务器上安装GitLab-Runner

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
sudo yum install gitlab-runner

接下来需要在服务器上注册Runner，Runner将作为CI/CD中流水线的执行节点，下面给出部分配置:

#开始注册runner
gitlab-runner register
# 输入需要注册到的 gitlab URL，即在上一步项目详情页里Runner配置里的url地址
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
http://xx.xx.xx.xx/
# 输入 Token，即在上一步项目详情页里Runner配置里的token
Please enter the gitlab-ci token for this runner
your_token
# 输入 tag, tag作为runner的唯一标志，在流水线运行时通过制定tag 决定让哪个runner来执行。
Please enter the gitlab-ci tags for this runner (comma separated):
my-tag
# 选择执行器,有docker选dokcer，没有选shell,这里因为我需要使用服务器的控制台输入指令因此选择了shell 
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
shell

如果返回success！回到GitLab，可以看到刚才创建的Runner：

二、流水线的编辑与运行

回到项目的详情页->CI/CD->Editor 可以为项目建立一条流水线。

流水线基本结构：

下面我给一条基本的流水线：

stages:- build- test- deployvariables:GIT_DEPTH: 1CI_JOB_NAME: "${CI_JOB_NAME}"BUILD_DIR: "${CI_PROJECT_DIR}/build"TEST_DIR: "${CI_PROJECT_DIR}/test"APP_URL: "https://your-app-url.com"cache:paths:- "${CI_PROJECT_DIR}/**/*"before_script:- apt-get update && apt-get install -y git curl jqbuild_job:stage: buildscript:- echo "Building the application..."- cd ${BUILD_DIR}- git clone https://github.com/yourusername/your-app.git- cd your-app- npm install- npm run buildartifacts:paths:- ${BUILD_DIR}/dist/*only:- mastertags: test-runnertest_job:stage: testscript:- echo "Testing the application..."- cd ${TEST_DIR}- npm test --coverage=lcov --reporter=html > coverage.htmlonly:- mastertags: test-runnerdeploy_job:stage: deployscript:- echo "Deploying the application..."- cd ${BUILD_DIR}- git add . && git commit -m "Build ${CI_COMMIT_REF_SLUG}" && git push origin master --tags || true # 如果有冲突，使用 git merge --strategy=ours --no-ff 将本地分支合并到远程分支上，然后再次推送。only:- mastertags: test-runner

流水线常见参数：

stages:定义了 CI/CD 流程中的各个阶段，如构建、测试和部署。
variables:定义了一些全局变量，如 GitLab CI/CD 的默认仓库地址、构建目录、测试目录等。这些变量可以在后续的 job 中使用。
cache:配置缓存，用于存储 GitLab CI/CD 在执行过程中生成的临时文件。这里配置了缓存路径为 ${CI_PROJECT_DIR}/**/*,表示缓存所有 CI_PROJECT_DIR 目录下的文件。
before_script:在每个 job 执行前运行的脚本，这里安装了 Git、curl 和 jq。
build_job:定义了一个名为 build 的 job,用于构建应用程序。它会在 build stage 执行，并将构建产物(如 dist 目录下的文件)保存到缓存中。只有当当前分支是 master 时才会执行此 job。
test_job:定义了一个名为 test 的 job,用于测试应用程序。它会在 test stage 执行，并生成一个 HTML 格式的代码覆盖率报告。只有当当前分支是 master 时才会执行此 job。
deploy_job:定义了一个名为 deploy 的 job,用于部署应用程序。它会在 deploy stage 执行，将构建产物推送到远程仓库。只有当当前分支是 master 且没有冲突时才会执行此 job。
tags: 指定使用哪个runner来执行，必须和建立的runner的tag匹配。

流水线的执行：

当流水线编辑完成后，语法校验通过，点击commit changes 会自动进行流水线的执行：

在执行界面可以查看流水线的Stages，点击可以查看执行日志：

三、经验技巧总结及拓展

常用技巧：

1.1 如果某个Stage不需要进行Git操作拉取代码，可以通过variables指定Git_Strategy来skip:

git-strategy默认为fetch 而非clone(复制整个仓库)，在每个stage的过程中，默认的操作是：git fetch 来重新初始化gitlab-runner维护的本地仓库(如果.git文件不存在，说明这个仓库之前就么有，会退回执行git clone) 这样做是为了保持仓库始终和gitlab上同步，保证是最新的。

如果我们有一个Stage，只需要对制品文件进行操作，比如一个部署的操作，复制文件的操作，我们可以通过Variable里设置GIT_STRATEGY:none来跳过Git操作：

1.2 通过并行阶段提高执行效率：

假设我们有一个需要进行多个步骤的CI/CD流程，例如构建、测试和部署。如果我们使用串行阶段，那么每个步骤都需要等待前一个步骤完成后才能开始执行下一个步骤，这会导致整个流程变得非常缓慢。

为了提高效率，我们可以使用GitLab CI/CD的并行阶段。并行阶段允许我们在不同的时间点同时运行多个任务，从而加快整个流程的速度。

stages:- build- testbuild:stage: buildscript:- echo "Building the project..."test:stage: testscript:- echo "Running tests..."parallel:count: 2matrix:- TEST_SUITE: unit- TEST_SUITE: integration

在这个示例中，我们定义了两个作业：build 和 test。test 作业使用 parallel 关键字来指定要并行运行的作业数量。count 关键字用于指定要并行运行的作业数量。在这个示例中，我们将同时运行两个测试套件：unit 和 integration。这意味着 test 作业将会运行两次，每次运行一个测试套件。