GitLab CI/CD 初学者入门指南

本教程旨在对 GitLab CI/CD 进行高阶介绍，帮助用户在 30 分钟内轻松上手，无需阅读 GitLab 的所有文档。本教程面向希望尝试 GitLab CI/CD 等 CI/CD 工具的初学者。在本教程中，我将简要介绍什么是 CI/CD，为什么我选择使用 GitLab 的工具，并通过 .gitlab-ci.yaml一个示例应用程序演示如何创建 CI/CD。

持续集成/持续交付

CI/CD 是持续集成/持续交付/持续部署的缩写。它使团队能够以更快的速度构建、测试和发布软件。CI/CD 尽可能地消除了人工交互，除了最终手动将代码部署到生产环境之外，其他所有操作均实现自动化。实施此实践的挑战之一是集成构建 CI/CD 流水线所需的各种工具和系统。例如，您可以将代码存储在 Bitbucket 中，在私有基础架构上的自动化测试套件中进行测试，然后将应用程序部署到 AWS 或 Microsoft Azure。由于应用程序复杂且驻留在多个系统上，因此并非所有组织都能实现无缝的 CI/CD 流水线。

为什么选择 GitLab CI/CD？

我使用 GitLab CI/CD 有三个原因：我可以用一个工具构建一个完整的 CI/CD 管道解决方案，它速度很快，而且它是开源的。通过在同一个地方使用 GitLab CI/CD，我可以创建票据、合并请求、编写代码和设置 CI/CD 工具，而无需其他应用程序。它本质上是一个一站式商店。GitLab CI/CD 在GitLab Runners上运行构建。Runners是通过 GitLab CI API 运行预定义步骤的独立虚拟机。与在单个实例上运行相比，此工具本身就允许项目更快地运行管道构建。您可以在此链接中了解有关 GitLab Runners 的更多详细信息。最后，它是开源的，所以我可以随时为代码库做出贡献，并在出现问题时创建新问题。

设想

假设我们有一个 Node.js API，用于检索数据库中的书籍列表。我们可以创建一个管道，将代码推送到三个阶段：构建、测试和部署。管道是一组按相似特征分组的步骤。根据这些阶段，我们的管道由三种类型定义：

• 项目管道
• 持续集成管道
• 部署管道

项目流水线安装依赖项、运行代码检查器以及处理代码的任何脚本。持续集成流水线运行自动化测试并构建代码的分布式版本。最后，部署流水线将代码部署到指定的云提供商和环境。

这三个管道执行的步骤称为作业。按这些特征对一系列作业进行分组时，这些作业称为阶段。作业是管道的基本构建块。它们可以分组为阶段，而阶段又可以分组为管道。以下是作业、阶段和管道的层次结构示例：

A.) Build
     i. Install NPM Dependencies
     ii. Run ES-Linter
     iii. Run Code-Minifier
B.) Test
     i. Run unit, functional and end-to-end test.
     ii. Run pkg to compile Node.js application
C.) Deploy
     i. Production
        1.) Launch EC2 instance on AWS
     ii. Staging
        1.) Launch on local development server

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

使用 GitLab CI/CD

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

image: node:10.5.0

stages:
  - build
  - test
  - deploy

before_script:
  - npm install

正如我之前提到的，GitLab CI/CD 使用 Runner 来执行流水线。我们可以使用指令来定义 Runner 所基于的操作系统和预定义库。image在本例中，我们将使用最新版本的 Node.js 作为 Runner。该stages指令允许我们为整个配置预定义一个阶段。作业将根据指令中列出的顺序执行。要了解有关阶段的更多信息，您可以在此处stages查看。该指令用于在所有作业之前运行命令。before_script

现在，让我们从专用于构建阶段的作业开始。我们将此作业命名为build-min-code。我们希望它在此作业中安装依赖项并压缩代码。我们可以先使用script指令。该script指令是一个在 Runner 中执行的 Shell 脚本。然后，我们将此作业分配到“构建”阶段。要将作业分配到某个阶段，请使用stage指令。

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

现在，我们已经有一个与构建阶段关联的作业，我们将在测试阶段执行此操作。我们的测试作业将被调用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工作中，Runner 只会在分支发生变更时执行，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 所提供功能的概述。GitLab CI/CD 能够通过构建和发布 Docker 镜像以及与第三方工具集成，更深入地控制代码库的自动化。希望本教程对您有所帮助，感谢您的阅读！