前言
CI/CD 是一种持续开发软件的方法，可以不断的进行构建、测试和部署代码迭代更改。这种迭代有助于减少基于错误或失败的版本进行开发新代码的可能性。使用这种方法，从新代码开发到部署，可以减少人工干预甚至不用干预。
达到持续的方法主要是：持续集成，持续交付，持续部署。
Gitlab CI/CD
Gitlab CI/CD 也就是 Gitlab 提供了上面的 CI/CD 能力，可以进行持续集成，持续交付和持续部署。
上面 Gitlab CI/CD 工作流程图，展示了主要的步骤。在实际项目中，CI 主要是提交或合并代码的时候触发，负责一些基本规则的检查，如果检查遇到失败，那么回滚或修改代码后再提交或合并，降低代码风险；CD 主要手动的触发，在CI的基础上，还负责功能检查，如果功能符合验收标准，那么就可以交付或部署。
如果更进一步看这个工作流程，可以看到 GitLab 在 DevOps 生命周期的每个阶段提供的功能：
Pipelines
Pipeline 是 CI/CD 重要组成之一。 也就是流水线，包括：
- Jobs：也就是任务，定义了该做什么，比如：编译和测试代码；
- Stages：也就是阶段，定义什么时候执行 Jobs，比如：在编译代码的阶段之后进入运行测试的阶段。
Job 是由 Runner 来执行，如果有足够多的并发 Runner，同一个 Stage 的 Job 可以并行执行。
如果同一个 Stage 中的所有 Job 都执行成功，Pipeline 就会进入下一个 Stage；如果一个 Stage 中的 任何一个 Job之 执行失败，Pipeline 就不会进入下一个 Stage，提前结束。
通常，Pipeline 是自动执行的，一旦创建就不需要干预。但是，有时也可以手动与 Pipeline 交互。
一般 Pipeline 包含四个 Stage（阶段），按照以下顺序执行：
- 一个 build（构建） 阶段，包含一个 compile 的 job；
- 一个 test（测试）阶段，包含两个 test1 和 test2 的 job；
- 一个 staging（预发） 阶段，包含一个 deploy to stage 的 job；
- 一个 production（生产）阶段，包含一个 deploy-to-prod 的 job。
Jobs
Job 其实就是任务，是 GitLab CI 系统中可以独立控制并运行的最小单位：
- 用约束来定义，说明在什么条件下应该执行这些约束；
- 可以有任意名称，但是至少包含 script 元素；
- 对定义多少没有限制。
Variables
为job执行提供的环境变量，主要分两类：
- CI/CD 提供了预定义好的环境变量
- 自定义环境变量
Cache and artifacts
cache 是 Job 下载并保存的一个或多个文件。使用相同 cahce 的后续 Job 不必再次下载文件，因此执行速度更快。即保留job结果
cache：
- 使用 cache 来定义每个 Job 的缓存；
- 后续的 Pipeline 可以使用缓存；
- 如果依赖相同的，同一个 Pipeline 的后续 Job 可以使用缓存；
- 不同的项目不能共用缓存。
artifacts：
- 定义每个 Job 的产物；
- 同一个 Pipeline 的后面 Stage 中 的后续 Job 可以使用前面 Job 的产物；
- 不同的项目不能共享产物；
- 默认情况下，产物在30天后过期。可以自定义过期时间；
- 如果启用了“保留最新产物”，则最新产物不会过期；
- 使用依赖项来控制哪些 Job 获取 产物。
cache 和 artifacts 的区别：
- 对依赖项使用 cache，比如从网络上下载的包。缓存存储在安装 GitLab Runner的地方，如果启用了分布式缓存，则将其安装并上传载到S3；
- 使用 artifacts 在 stage 之间传递中间构建结果。artifacts 由 Job 生成，存储在GitLab中，可以下载；
- artifacts 和 cache 都定义了它们相对于项目目录的路径，并且不能链接到项目目录之外的文件。
gitlab环境搭建
gitlab环境，主要分成两个部份，gitlab-ce（管理器）和gitlab-runner（执行器）。
## gitlab-ce安装
sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo apt-get install gitlab-ce
## 修改配置文件, 将external_url改成你可访问的地址
sudo vim /etc/gitlab/gitlab.rb
> external_url 'http://192.168.xx.xxx:6001'
## 重新加载配置，并重启动
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
## 查看运行状态
sudo gitlab-ctl status
## 查看运行日志
sudo gitlab-ctl tail
现在可以通过刚配置好的http://192.168.xx.xxx:6001进行访问了。
GitLab初次安装后，登录GitLab网页的管理员账号和密码各是什么？
- 管理员账号的账号名为 root，
- 密码在一个自动生成的文件 /etc/gitlab/initial_root_password 中（密码不会含空格），且会在 24 小时后自动被删除。
## 安装runner
sudo curl --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-arm64"
## 授权
sudo chmod +x /usr/local/bin/gitlab-runner
## 使用root,安装并启动
sudo su
cd ~
gitlab-runner install --user root
gitlab-runner start
## 启动完后注册服务
## 通过 Gitlab项目首页=> setting => CI/CD => Runners => Project runners 获取token
## 填写之前gitlab-ce设置的external_url
sudo gitlab-runner register
## 激活
sudo gitlab-runner verify
编写.gitlab-ci.yml配置文件
stages: # List of stages for jobs, and their order of execution
- build
- test
- deploy
build-job: # This job runs in the build stage, which runs first.
stage: build
tags: ## 加上tag
- sss
script:
- echo "Compiling the code..."
- echo "Compile complete."
unit-test-job: # This job runs in the test stage.
stage: test # It only starts when the job in the build stage completes successfully.
tags:
- sss
script:
- echo "Running unit tests... This will take about 60 seconds."
- sleep 60
- echo "Code coverage is 90%"
lint-test-job: # This job also runs in the test stage.
stage: test # It can run at the same time as unit-test-job (in parallel).
tags:
- sss
script:
- echo "Linting code... This will take about 10 seconds."
- sleep 10
- echo "No lint issues found."
deploy-job: # This job runs in the deploy stage.
stage: deploy # It only runs when *both* jobs in the test stage complete successfully.
tags:
- sss
environment: production
script:
- echo "Deploying application..."
- echo "Application successfully deployed."
主要参考
《Gitlab CI/CD 简单介绍》
《ubuntu 安装 gitlab》
《Gitlab-ci:从零开始的前端自动化部署》