GitLab CI/CD 进阶：优雅地实现多环境部署

StephenCurryFans
166 阅读5分钟

前言

在上一篇《GitLab CI/CD 入门：轻松实现自动化部署》中，我们学习了如何配置一个基本的 CI/CD 流水线，实现了代码提交后自动构建和部署到单台服务器。然而，在真实的开发流程中，我们通常需要多个环境来保证软件质量，例如：

  • 开发环境 (Development): 用于开发人员日常开发和调试。
  • 预发/测试环境 (Staging/Testing): 用于模拟生产环境，进行功能测试和回归测试。
  • 生产环境 (Production): 面向最终用户的正式环境。

本文将作为进阶篇，带你学习如何利用 GitLab CI/CD 的强大功能，为你的项目配置一个清晰、可控的多环境部署流程。

为什么需要多环境部署？

  1. 隔离风险: 将开发、测试和生产环境隔离开，可以有效防止未经测试的代码直接影响到线上用户，降低部署风险。
  2. 保证质量: 在部署到生产环境之前，代码能够在预发环境中经过充分测试，确保新功能的稳定性和正确性。
  3. 清晰的流程: 不同的环境对应不同的代码分支和部署策略，让团队成员对代码的生命周期有更清晰的认识。

核心概念：GitLab Environments 和 Variables

为了实现多环境部署，我们需要利用 GitLab 的两个核心功能：

  • Environments (环境): GitLab 允许你为项目定义不同的环境。在 .gitlab-ci.yml 中通过 environment 关键字，可以将一个部署 Job 与一个特定的环境关联起来。这不仅能让你在 GitLab 界面上清晰地看到每个环境的部署状态，还能实现回滚等高级操作。
  • Variables (变量): 我们可以为不同的环境设置不同的变量。例如，生产环境和预发环境的服务器地址、数据库密码等配置通常是不同的。通过在 Settings > CI/CD > Variables 中设置环境范围（Environment scope）的变量，可以轻松管理这些差异。

实战：改造 .gitlab-ci.yml 支持多环境

我们继续以上一篇的静态网站项目为例，目标是实现以下流程：

  • 代码推送到 develop 分支时，自动部署到 预发环境 (staging)。
  • 代码合并到 main 分支时，需要 手动触发 才能部署到 生产环境 (production)。

步骤 1: 调整分支策略

首先，我们需要一个 develop 分支用于日常开发和预发部署。

git checkout -b develop
git push origin develop

步骤 2: 更新 .gitlab-ci.yml

接下来，我们修改 .gitlab-ci.yml 文件，引入 environment 关键字，并为不同环境创建独立的部署 Job。

stages:
  - build
  - deploy

# 构建任务保持不变，但我们让它在 develop 和 main 分支上都运行
build_project:
  stage: build
  script:
    - echo "开始构建项目..."
    - npm install
    - npm run build
    - echo "构建完成。"
  artifacts:
    paths:
      - dist/
  only:
    - main
    - develop

# 部署到预发环境
deploy_staging:
  stage: deploy
  script:
    - echo "开始部署到预发环境..."
    # 使用预发环境的变量
    - scp -r dist/* user@$STAGING_SERVER_IP:/var/www/staging/
    - echo "预发环境部署完成。"
  environment:
    name: staging # 定义环境名称
    url: http://staging.your-domain.com # 预发环境的访问地址
  only:
    - develop # 仅在 develop 分支上执行

# 部署到生产环境
deploy_production:
  stage: deploy
  script:
    - echo "开始部署到生产环境..."
    # 使用生产环境的变量
    - scp -r dist/* user@$PRODUCTION_SERVER_IP:/var/www/production/
    - echo "生产环境部署完成。"
  environment:
    name: production # 定义环境名称
    url: http://your-domain.com # 生产环境的访问地址
  when: manual # 设置为手动触发
  only:
    - main # 仅在 main 分支上执行

步骤 3: 理解新的配置

  • build_project Job 现在会响应 main 和 develop 两个分支的提交。
  • deploy_staging Job:
    • environment: 我们定义了一个名为 staging 的环境，并指定了其访问 URL。当这个 Job 成功执行后，你可以在 GitLab 的 Deployments > Environments 页面看到 staging 环境的状态。
    • only: - develop: 这个 Job 只会在 develop 分支有代码提交时自动运行。
    • $STAGING_SERVER_IP: 我们使用了变量来表示服务器 IP，而不是硬编码。
  • deploy_production Job:
    • environment: 类似地，定义了 production 环境。
    • when: manual: 这是关键！这个设置使得该 Job 不会自动执行。当 main 分支的 Pipeline 运行到 deploy 阶段时，它会暂停，并在 GitLab 界面上显示一个“播放”按钮，需要有权限的用户手动点击才能继续部署。这为生产环境的部署增加了一道安全门锁。
    • only: - main: 确保只有 main 分支的 Pipeline 才能部署到生产。

步骤 4: 配置环境变量

最后，我们需要在 GitLab 中设置 STAGING_SERVER_IP 和 PRODUCTION_SERVER_IP 这两个变量。

  1. 进入项目的 Settings > CI/CD > Variables。
  2. 点击 Add variable，添加以下两个变量：
    • Key: STAGING_SERVER_IP, Value: your_staging_server_ip
    • Key: PRODUCTION_SERVER_IP, Value: your_production_server_ip
  3. (可选，但推荐) 你可以为每个变量设置 “Environment scope”，例如让 PRODUCTION_SERVER_IP 仅在 production 环境中可用，增加安全性。

同样，上一篇文章中提到的 SSH_PRIVATE_KEY 变量依然需要，并且可以被所有 Job 共享。

总结

通过以上改造，我们成功地建立了一个支持多环境部署的 CI/CD 流程。这个流程更加健壮和安全，符合现代软件开发的最佳实践。现在，你的团队可以放心地在 develop 分支上快速迭代，同时通过手动的预发验证和生产部署，确保线上服务的稳定可靠。

GitLab CI/CD 的 environment 和 variables 功能非常强大，你可以进一步探索，例如：

  • 动态环境 (Dynamic Environments): 为每个特性分支自动创建一个临时的测试环境。
  • 部署冻结 (Deploy Freezes): 在特定时间段（如节假日）禁止向生产环境部署。
  • 金丝雀部署 (Canary Deployments): 逐步将流量切换到新版本，进一步降低风险。

希望这篇文章能帮助你更好地驾驭 GitLab CI/CD，让自动化工具成为你提升工程效率的利器。

avatar
文章
阅读
粉丝