Gitlab CICD

本文将概述持续集成、持续交付和持续部署的概念，并介绍GitLab CI / CD，最后将Gitlab CI/CD与Jenkins做简单的对比。

一、CI/CD简介

软件开发的连续方法是建立在自动执行脚本的基础上的，以最小化在开发应用程序时引入错误的机会。从新代码的开发到部署，它们需要的人工干预更少，甚至根本不需要干预。

它涉及在每个小的迭代中不断地构建、测试和部署代码更改，从而减少了基于有缺陷的或失败的以前版本开发新代码的机会。

CI/CD主要包含以下三种。

1.1 持续集成（Continuous Integration）

考虑一个应用程序，其代码存储在GitLab的Git仓库中。开发人员每天要多次推送代码更改。对于每次向仓库的推送，您都可以创建一组脚本来自动构建和测试您的应用程序，从而减少了向应用程序引入错误的机会。

这种做法被称为持续集成。对于提交给应用程序（甚至是开发分支）的每个更改，它都会自动连续地构建和测试，以确保所引入的更改通过您为应用程序建立的所有测试、准则和代码合规性标准。

GitLab本身就是使用持续集成作为软件开发方法的示例。对于项目的每一次推送，都有一组检查脚本的脚本。

1.2 持续交付（Continuous Delivery）

持续交付是超越持续集成的一步。您的应用程序不仅会在每次推送到代码库的每次代码更改时都进行构建和测试，而且还会进行自动部署，尽管部署是手动触发的。

此方法可确保自动检查代码，但是需要人工干预来手动地触发更改的部署。

1.3 持续部署（Continuous Deployment）

持续部署也比持续集成更进一步，类似于持续交付。不同之处在于，您将应用程序设置为自动部署，而不是手动部署。部署应用程序根本不需要人工干预。

注以上概念翻译自Gitlab官网https://docs.gitlab.com/ee/ci/introduction/index.html。

1.4 目前主流的CICD工具

Jenkins、Gitlab CI/CD、GoCD、Travis CI、Concourse CI等。

二、Gitlab CI/CD简介

GitLab CI / CD是内置在GitLab中的功能强大的工具，它支持持续集成、持续交付和持续部署，而无需集成第三方应用程序。

2.1 如何使用Gitlab CI/CD

要使用Gitlab CI/CD，首先您需要在Gitlab上创建代码仓库，并在项目的根路径中创建一个名为 .gitlab-ci.yml 的配置文件，然后在这个文件中定义构建、测试和部署脚本。将.gitlab-ci.yml配置文件添加到代码仓库库后，GitLab将检测到该文件并使用GitLab Runner运行脚本。

2.2 .gitlab-ci.yml配置文件

一个简单的.gitlab-ci.yml配置文件如下：

stages:
  - build
  - deploy
before_script:
  - echo '我要开始了哦'
build_job:
  stage: build
  script:
    - echo 'build start'
    - echo 'build end'
  tags:
    - my-tag
deploy_job:
  stage: deploy
  script:
    - echo 'start'
    - echo 'end'
  tags:
    - my-tag

其中，stages定义了包含哪些步骤，本例中包含build和deploy两个步骤；before_script指定的脚本将会在所有其他脚本执行之前执行（因此可能会执行多次）；build_job定义build阶段，其中script指定执行的脚本，这里只打印了两句话；tags用于指定执行job的Runner。

.gitlab-ci.yml的更多配置见Gitlab CI/CD的官方文档： https://docs.gitlab.com/ee/ci/yaml/README.html

2.3 Gitlab Runner

Gitlab Runner用于运行.gitlab-ci.yml中定义的job，需要另外安装，不建议将Gitlab Runner与Gitlab安装在同一台机器上。

2.3.1 安装和注册Gitlab Runner

这里以Docker安装为例。首先拉取镜像：

docker pull gitlab/gitlab-runner

之后启动容器：

docker run -d --name gitlab-runner --restart always -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner

启动成功后，还需注册Runner。到Gitlab首页，点击进入项目主页，点击settings-CI/CD，展开Runner，可以看到如下界面：

其中的url和token在后续的注册步骤中需要用到。

进入到gitlab-runner容器，执行如下命令注册Runner：

gitlab-runner register -n \
--url=http://192.168.4.210:8099/ \
--registration-token=BF-Y6fPYR-Wzg9AtRDb7 \
--name=my-runner \
--run-untagged=true 
--locked=true \
--tag-list my-tag \
--executor=shell

其中，url和registration-token就是上文提到的，name指定gitlab-runner的名称，tag-list定义一些标签，只有匹配.gitlab-ci.yml配置文件中的tags的Runner才会执行，executor指定Runner的执行环境，这里是shell。

值得一提的是，如果Gitlab配置了HTTPS，那么需要将Gitlab服务器的证书（要求是crt格式，如果是cer格式的需要使用openssl命令进行格式转换，转换的命令见http://blog.chinaunix.net/uid-31542012-id-5790297.html）copy到Runner中（通过挂载的方式，拷贝到宿主机即可），然后通--tls-ca-file参数指定证书路径，否则注册会失败。

Runner注册成功后，回到Gitlab，刷新页面，即可看到成功注册的Runner：

Runner的更多特性，参见Gitlab官方文档：https://docs.gitlab.com/ee/ci/runners/README.html

经过以上步骤，Gitlab CICD就可以正常工作了。当我们push代码到Gitlab后，就会触发Gitlab Runner按照.gitlab-ci.yml配置文件配置的Pipline进行工作，比如进行构建、测试、部署等。这里不再详细介绍。关于Gitlab CICD的更多特性，可以在官方网站找到：https://docs.gitlab.com/ee/ci/README.html

三、Gitlab CICD与Jenkins的比较

Jenkins作为老牌的持续集成框架，在这么多年的发展中，积累很多优秀的plugin工具，对进行持续集成工作带来很大的便利。

Gitlab CI/CD作为Gitlab提供的一个持续集成的套件，完美和Gitlab进行集成，Gitlab CI/CD已经集成进gitlab服务器中，在使用的时候只需要安装配置Gitlab Runner即可。Gitlab Runner基本上提供了一个可以进行编译的环境，负责从gitlab中拉取代码，根据工程中配置的.gitlab-ci.yml，执行相应的命令进行编译。

Gitlab Runner配置简单，很容易与gitlab集成。当新建一个项目的时候，不需要配置webhook回调地址，也不需要同时在jenkins新建这个项目的编译配置，只需在工程中配置.gitlab-ci.yml文件，就可以让这个工程可以进行编译。

Gitlab Runner没有web页面，但编译的过程直接就在gitlab中可以看到，不需要像jenkins进入web控制台查看编译过程。

Gitlab Runner仅仅是提供了一个编译的环境而已，全部的编译都通过shell脚本命令进行。当然，jenkins也可以是全部的编译都通过shell脚本命令进行。

Jenkins的好处就是编译服务和代码仓库分离，而且编译配置文件不需要在工程中配置，如果团队有开发、测试、配置管理员、运维、实施等完整的人员配置，那就采用jenkins，这样职责分明。不仅仅如此，jenkins依靠它丰富的插件，可以配置很多Gitlab CI/CD不存在的功能，比如说看编译状况统计等。