GitLab CI/CD 入门：轻松实现自动化部署

前言

在现代软件开发中，持续集成（CI）和持续部署（CD）是不可或缺的一环。它不仅能提高开发效率，还能保证代码质量和部署的稳定性。GitLab CI/CD 是 GitLab 内置的强大工具，可以让你轻松地在项目中实现自动化构建、测试和部署。本篇文章将带你从零开始，一步步了解并配置一个基本的 GitLab CI/CD 自动化部署流程。

什么是 CI/CD？

持续集成 (Continuous Integration, CI)：开发者频繁地将代码合并到主干分支。每次合并后，系统会自动执行构建和单元测试，以尽早发现集成错误。
持续交付 (Continuous Delivery, CD)：在持续集成的基础上，将通过所有测试的代码自动部署到预生产环境（如测试环境或Staging环境）。
持续部署 (Continuous Deployment, CD)：更进一步，将通过所有测试的代码自动部署到生产环境，实现真正的自动化发布。

GitLab CI/CD 的核心概念

要使用 GitLab CI/CD，你只需要在你的代码仓库根目录下创建一个名为 .gitlab-ci.yml 的文件。GitLab 会自动识别这个文件，并根据其中的定义执行相应的任务。

理解以下几个核心概念至关重要：

Pipeline（流水线）：一次 CI/CD 的完整运行过程，包含多个阶段（Stage）和任务（Job）。当代码被推送到仓库时，通常会触发一个新的 Pipeline。
Stage（阶段） ：Pipeline 的不同阶段，按顺序执行。例如，一个典型的 Pipeline 可能包含 build（构建）、test（测试）和 deploy（部署）三个阶段。只有前一个阶段的所有任务都成功后，后一个阶段才会开始。
Job（任务） ：Stage 中具体的执行单元，可以并行执行。例如，在 test 阶段，你可能同时有 unit-test 和 integration-test 两个 Job。
Runner（执行器）：真正执行 Job 的代理程序。你可以在自己的服务器上安装 GitLab Runner，也可以使用 GitLab 提供的共享 Runner。

实战：配置一个简单的前端项目自动化部署

假设我们有一个简单的静态网站项目，我们希望在每次推送到 main 分支时，自动将其部署到服务器上。

步骤 1: 创建 `.gitlab-ci.yml` 文件

在你的项目根目录下创建 .gitlab-ci.yml 文件，并添加以下内容：

yaml 复制代码

# 定义流水线的各个阶段
stages:
  - build
  - deploy

# 构建任务
build_project:
  stage: build # 指定该任务属于 build 阶段
  script:
    - echo "开始构建项目..."
    - npm install # 安装依赖
    - npm run build # 执行构建命令
    - echo "构建完成。"
  artifacts:
    paths:
      - dist/ # 将构建产物（dist 目录）作为 artifact 保存，用于后续阶段
  only:
    - main # 仅在 main 分支上执行此任务

# 部署任务
deploy_to_server:
  stage: deploy # 指定该任务属于 deploy 阶段
  script:
    - echo "开始部署项目..."
    # 这里的脚本需要替换成你自己的部署逻辑
    # 例如，使用 scp 将 dist 目录下的文件复制到你的 web 服务器
    - scp -r dist/* user@your_server_ip:/var/www/html/
    - echo "部署完成。"
  only:
    - main # 仅在 main 分支上执行此任务

步骤 2: 理解配置文件

stages: 我们定义了两个阶段：build 和 deploy。它们将按顺序执行。
build_project Job:
- stage: build: 声明这个 Job 属于 build 阶段。
- script: 定义了需要执行的 shell 命令。这里我们模拟了安装依赖和构建项目的过程。
- artifacts: artifacts 用于在不同的 Job 之间传递文件。这里我们将构建生成的 dist 目录保存下来，以便 deploy 阶段可以使用。
- only: - main: 表示这个 Job 只会在 main 分支有代码提交时触发。
deploy_to_server Job:
- stage: deploy: 声明这个 Job 属于 deploy 阶段。
- script: 这里我们使用 scp 命令将构建产物从 GitLab Runner 的临时环境拷贝到目标服务器。注意： 这只是一个示例，实际部署中你可能需要配置 SSH 免密登录或者使用更安全的部署方式（如 rsync、Ansible 等）。

步骤 3: 配置 GitLab Runner (如果需要)

如果你的项目需要特定的编译环境或者你想在自己的服务器上执行任务，你需要安装和配置 GitLab Runner。对于简单的公有项目，可以使用 GitLab 提供的共享 Runner。

要配置自己的 Runner，你需要：

在你的服务器上安装 GitLab Runner。
使用从 GitLab 项目的 Settings > CI/CD > Runners 页面获取的 URL 和 token 来注册 Runner。
为 Runner 添加 tag，并在 .gitlab-ci.yml 的 Job 中通过 tags 关键字指定使用哪个 Runner。

例如，在 deploy_to_server Job 中指定一个 Runner：

yaml 复制代码

deploy_to_server:
  stage: deploy
  tags:
    - my-deploy-runner # 指定使用带有 'my-deploy-runner' 标签的 Runner
  script:
    - ...

步骤 4: 配置 SSH 密钥 (用于部署)

为了让 GitLab Runner 能够通过 scp 或 ssh 连接到你的服务器，你需要配置 SSH 密钥。

生成一对 SSH 密钥。
将公钥 (.pub 文件) 添加到你目标服务器的 ~/.ssh/authorized_keys 文件中。
将私钥添加到 GitLab 项目的 Settings > CI/CD > Variables 中。创建一个变量，例如 SSH_PRIVATE_KEY，将私钥内容粘贴进去，并勾选 Protected 和 Masked 选项以增加安全性。

然后在你的 .gitlab-ci.yml 的 before_script 中加载这个密钥：

yaml 复制代码

deploy_to_server:
  stage: deploy
  before_script:
    - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - ssh-keyscan your_server_ip >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
  script:
    - scp -r dist/* user@your_server_ip:/var/www/html/
  # ...

总结

通过以上步骤，你就成功配置了一个基本的 GitLab CI/CD 流程。现在，每当你向 main 分支推送代码时，GitLab 都会自动为你完成构建和部署工作，大大解放了你的生产力。

GitLab CI/CD 的功能远不止于此，它还支持更复杂的场景，如：

多环境部署 (开发、测试、生产)
定时任务 (Scheduled pipelines)
手动触发 (Manual jobs)
集成 Docker，实现容器化部署

希望这篇入门文章能帮助你迈出自动化部署的第一步。探索并善用 GitLab CI/CD，它将成为你项目开发中的得力助手。

GitLab CI/CD 入门：轻松实现自动化部署