GitLab CI 如何实现环境间的变量隔离

GitLab CI 实现环境变量隔离的核心是“作用域控制+条件注入”，需通过 environment name 绑定、Environment Scope 设置、rules 动态覆盖、受保护变量三重锁定及组/项目级分层管理共同实现。

GitLab CI 实现环境间变量隔离，核心在于“作用域控制”+“条件注入”，而不是靠文件位置或命名约定来区分。变量本身不自带环境属性，必须通过配置策略让它们只在目标环境中生效。

用 environment 关键字绑定变量作用域

GitLab 会将 environment 的 name 值（如 staging、production）作为变量生效的逻辑边界。但注意：仅定义 environment 不会自动加载变量——你需要配合变量的“环境范围（Environment Scope）”设置：

• 进入项目 Settings → CI/CD → Variables
• 添加变量时，在 Environment scope 栏填入匹配的环境名，例如：staging 或 production
• 该变量就只会在 environment: { name: staging } 的 job 中被注入
• 支持通配符，如 feature/*、release/v*，便于动态环境复用

用 rules + 变量覆盖实现分支级隔离

当环境与 Git 分支强绑定（如 main → prod、develop → dev），可通过 rules 动态覆盖变量，避免创建大量重复变量项：

• 在 .gitlab-ci.yml 中统一声明基础变量
• 按分支条件注入具体值，例如：

variables:
  DB_HOST: "default-db.example.com"
deploy-prod:
  stage: deploy
  environment: production
  script: - deploy.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      variables:
        DB_HOST: "prod-db.internal"
    - if: '$CI_COMMIT_BRANCH == "develop"'
      variables:
        DB_HOST: "dev-db.docker"

用受保护变量（Protected Variables）守住生产底线

仅靠环境名匹配还不够——恶意修改分支或手动触发可能绕过隔离。真正防越权需三重锁定：

• 第一步：在 Settings → Repository → Protected branches 中，明确保护 main、release/* 等分支
• 第二步：在 Variables 页面添加敏感变量（如 PROD_DEPLOY_KEY）时，同时勾选 Protect variable 和 Mask variable
• 第三步：关键作业中增加校验逻辑，例如：
  script:
  - '[ -n "$PROD_DEPLOY_KEY" ] || exit 1'

用组级/项目级变量分层管理公共与专属配置

避免每个项目重复设置通用参数，也防止误覆盖：

• 组级变量（Settings → Group → CI/CD → Variables）：存放跨项目的共享配置，如 COMPANY_API_BASE，默认对所有子项目生效
• 项目级变量（Settings → Project → CI/CD → Variables）：覆盖组级值或设置项目独有参数，如 PROJECT_NAME
• 两者都支持按 Environment scope 进一步细分，形成「组级通用 + 项目级定制 + 环境级覆盖」三层结构