Gitlab CI/CD 实践

介绍

GitLab CI/CD 是一个内置在 GitLab 中的工具，用于通过持续方法进行软件开发：

Continuous Integration（持续集成）

假设一个应用程序，其代码存储在 GitLab 的 Git 仓库中。开发人员每天都要多次推送代码更改。对于每次向仓库的推送，你都可以创建一组脚本来自动构建和测试你的应用程序，从而减少了向应用程序引入错误的机会。这种做法称为持续集成，对于提交给应用程序（甚至是开发分支）的每项更改，它都会自动连续进行构建和测试，以确保所引入的更改通过你为应用程序建立的所有测试，准则和代码合规性标准。

Continuous Delivery（持续交付）

持续交付是超越持续集成的更进一步的操作。应用程序不仅会在推送到代码库的每次代码更改时进行构建和测试，而且，尽管部署是手动触发的，但作为一个附加步骤，它也可以连续部署。此方法可确保自动检查代码，但需要人工干预才能从策略上手动触发以必输此次变更。

Continuous Deployment（持续部署）

与持续交付类似，但不同之处在于，你无需将其手动部署，而是将其设置为自动部署。完全不需要人工干预即可部署你的应用程序。

工作流程

为了使用 GitLab CI/CD，你需要一个托管在 GitLab 上的应用程序代码库，并且在根目录中的.gitlab-ci.yml 文件中指定构建、测试和部署的脚本。

在这个文件中，你可以定义要运行的脚本，定义包含的依赖项，选择要按顺序运行的命令和要并行运行的命令，定义要在何处部署应用程序，以及指定是否 要自动运行脚本或手动触发脚本。

为了可视化处理过程，假设添加到配置文件中的所有脚本与在计算机的终端上运行的命令相同。

一旦你已经添加了.gitlab-ci.yml 到仓库中，GitLab 将检测到该文件，并使用名为 GitLab Runner 的工具运行你的脚本。该工具的操作与终端类似。

这些脚本被分组到 jobs，它们共同组成一个 pipeline。一个最简单的.gitlab-ci.yml 文件可能是这样的：

before_script:
  - apt-get install rubygems ruby-dev -y

run-test:
  script:
    - ruby --version 6

before_script 属性将在运行任何内容之前为你的应用安装依赖，一个名为 run-test 的 job（作业）将打印当前系统的 Ruby 版本。二者共同构成了在每次推送到仓库的任何分支时都会被触发的 pipeline（管道）。

GitLab CI/CD 不仅可以执行你设置的 job，还可以显示执行期间发生的情况，正如你在终端看到的那样：

通过 GitLab UI 所有的步骤都是可视化的

实践

创建一个.gitlab-ci.yml 文件

stages:
  - lint
  - release
commitlint:
  stage: lint
  rules:
    - if: '$CI_COMMIT_TITLE =~ /^chore\(release\)/'
      when: never
    - if: '$CI_COMMIT_TITLE =~ /^Merge branch/'
      when: never
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # 一般当分支master有 push 或 merge 时才会执行该工作
  script:
    - sh bin/commitlint-gitlab-ci.sh
release:
  stage: release
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script:
    - semantic-release

配置一个 Runner

在 GitLab 中，Runner 运行你定义在.gitlab-ci.yml 中的作业（job）
一个 Runner 可以是一个虚拟机、物理机、docker 容器，或者一个容器集群 GitLab 与 Runner 之间通过 API 进行通信，因此只需要 Runner 所在的机器有网络并且可以访问 GitLab 服务器即可
你可以去 Settings ➔ CI/CD 看是否已经有 Runner 关联到你的项目，设置 Runner 简单又直接

查看 pipeline 和 jobs 状态

小结

团队计划使用 semantic-release 自动管理发布版本，结合 Gitlab CI/CD 是一个很不错的选择，具体的实践过程和心得会在后面分享。