Beginner-Friendly GitLabCI/CD入门基础简介

点击上方蓝色字体，关注我们

预告： 《GitLabCI/CD实践》教程在路上，敬请期待！

本教程的目的是对GitLab CI / CD进行介绍，本教程适用于希望尝试使用CI / CD工具（如GitLab CI / CD）的初学者。在本教程中，我将简要介绍什么是CI / CD，为什么决定使用GitLab的工具以及有关如何.gitlab-ci.yaml使用示例应用程序创建的演练。

CI/CD基础概念

+

CI / CD是持续集成/持续交付/持续部署的缩写。它使团队可以更快地构建，测试和发布软件。CI / CD消除了手动的人机交互，从而使最终的手动代码部署到生产过程之外的一切都实现了自动化。实施此实践的挑战之一是集成构建CI / CD管道所需的各种工具和系统。

为什么选择GitLabCI/CD？

+

使用GitLab CI / CD的原因有以下三个：

• 可以使用一个工具构建完整的CI / CD管道，它既快速又开源。在同一应用中使用GitLab CI / CD，可以创建凭证，合并请求，编写代码和设置CI / CD工具，而无需其他应用程序。它本质上是一站式DevOps。

• GitLab CI / CD在GitLab Runners上运行。Runner 是一台独立的机器，运行通过GitLab CI API定义的流水线步骤。与在单个实例上运行相比，单独使用此工具可使项目在管道构建过程中运行得更快。

• 它是开源的，因此可以随时为代码库做出贡献，并在出现问题时提出新的问题。

需求场景

+

假设我们有一个Node.js API，可以检索数据库中的书籍列表。我们可以创建一个包含三个阶段的管道：构建，测试和部署。管道是一个或者多个不同的步骤组成的，在这些阶段中，我们的管道由三种类型定义：

• 项目管道

• 持续集成管道

• 部署管道

该项目管道用于安装依赖，运行脚本处理的代码。在持续集成管道运行自动化测试和代码构建。最后，部署管道将代码部署到指定的环境。

这三个管道执行的步骤称为作业。通过这些特征将一系列作业分组时，称为阶段。作业是管道的基本构建块。可以将它们分阶段组合在一起，也可以将各个阶段组合成管道。这是作业，阶段和管道的示例层次结构：

A.) Build i. 安装NPM依赖 ii. 运行ES-Linter iii. 运行 Code-MinifierB.) Test i. 运行测试 ii. 编译构建C.) Deploy i. 发布 1.) 测试环境

在此层次结构中，所有三个组件均被视为三个不同的管道。主要项目符号（构建，测试和部署）是阶段，这些部分下的每个项目符号都是作业。让我们将其分解为一个GitLab CI / CD yaml文件。

使用GitLabCI/CD

+

要使用GitLab CI / CD，请在您的GitLab存储库中的项目根目录下创建一个名为.gitlab-ci.yml的文件，并添加以下内容yaml：

image: node:10.5.0
stages:
 — build
 — test
 — deploy
before_script:
 — npm install

如上所述，GitLab CI / CD使用运行程序来执行管道。通过使用image指令，我们可以定义希望基于Runner的操作系统和预定义库。在我们的实例中，我们将为Runner使用最新版本的Node.js。该stages指令使我们可以预定义整个配置的阶段。作业将根据stages指令中列出的顺序执行。该before_script指令用于在所有作业之前运行命令。

现在让我们开始致力于Build阶段的工作。我们要称这项工作build-min-code。在这项工作中，我们希望它安装依赖项并减少代码。我们可以使用script指令开始。该script指令是在Runner中执行的Shell脚本。然后，我们将把这项工作分配到“构建”阶段。要将作业分配给阶段，请使用stage指令。

build-min-code:
  stage: build
  script:
    - npm install
    - npm run minifier

现在我们有一个与Build阶段相关的工作，我们将在Test阶段进行。我们的测试工作将被调用run-unit-test，我们将使用API中的npm脚本来运行测试npm test。

run-unit-test:
  stage: test
  script:
    - npm run test

最后，我们将添加一个任务来处理我们的部署阶段：deploy-production，deploy-staging。在这种情况下，我们将有两个不同的部署工作（预生产和生产）。这些工作将反映与我们以前的工作相同的布局，但是变化很小。当前，我们所有的作业都自动设置为在任何代码推送或分支上触发。当我们将代码部署到预生产和生产环境时，我们不希望这样做。为了防止这种情况的发生，我们使用了only指令。该only指令定义了要为其运行作业的分支和标签的名称。该工作将如下所示：

deploy-staging:
 stage: deploy
 script:
   — npm run deploy-stage
 only:
   — develop
deploy-production:
 stage: deploy
 script:
   — npm run deploy-prod
 only:
   — master

在我们的deploy-staging工作，如果有一个变化的分支将只执行它develop的分支和deploy-production该master分支。这是下面的屏幕截图，显示了对该master分支进行的代码推送。

从此镜像中，所有三个阶段和作业都被触发，但deploy-staging由于代码推送到了master分支。GitLab CI / CD带有直观的界面，可帮助显示正在运行的作业和阶段以及在构建过程中发生的错误。下面是.gitlab-ci.yaml文件的最终版本。如果您希望自己进行测试，请参见示例应用程序的链接。

image: node:10.5.0
stages:
  - build
  - test
  - deploy
before_script:
  - npm install
build-min-code:
  stage: build
  script:
    - npm install
    - npm run minifier
run-unit-test:
  stage: test
  script:
    - npm run test
deploy-staging:
  stage: deploy
  script:
    - npm run deploy-stage
  only:
    - develop
deploy-production:
  stage: deploy
  script:
    - npm run deploy-prod
  only:
    - master

---

上面介绍的项目是GitLab CI / CD可以提供的功能的高级概述。通过构建和发布Docker映像以与第三方工具集成，GitLab CI / CD能够对代码库的自动化进行更深入的控制。希望本教程对您有所帮助。谢谢阅读！

如果你对GitLabCI/CD感兴趣，不妨听听上周的分享。{每周末都会直播分享}

详细介绍为什么使用GitLabCI/CD。[订阅上面分享后这个可以忽略]