## 前言

基础流水线跑通后，第一个痛点就是"多环境管理"——dev、test、staging、prod 四个环境的配置、密钥、部署策略都不同。本篇讲清楚如何在 GitLab CI 中优雅地管理多环境部署和变量，避免"一堆 if-else 和重复 Job"。

---

## 一、多环境部署架构

### 目标架构

```
代码仓库:
  main 分支 → deploy-test (自动)
           → deploy-staging (手动)
  v* Tag    → deploy-prod (手动)

环境隔离:
  ┌─────────┐   ┌──────────┐   ┌──────────┐   ┌─────────┐
  │ dev      │   │ test     │   │ staging  │   │ prod    │
  │ 开发自测 │   │ CI自动部署│   │ 预发验证  │   │ 生产    │
  │ K8s ns:  │   │ K8s ns:  │   │ K8s ns:  │   │ K8s ns: │
  │ myapp-  │   │ myapp-   │   │ myapp-  │   │ myapp-  │
  │ dev     │   │ test     │   │ staging │   │ prod    │
  └─────────┘   └──────────┘   └──────────┘   └─────────┘
```

---

## 二、环境管理

### GitLab Environments

```yaml
# 利用 GitLab 的 environment 功能实现部署追踪
deploy-test:
  environment:
    name: test
    url: https://test.myapp.com
    on_stop: stop-test  # 关联停止 Job
  script:
    - kubectl apply -f deploy/ -n myapp-test
    - kubectl set image deployment/myapp app=$IMAGE:$TAG -n myapp-test

# 停止环境的 Job
stop-test:
  environment:
    name: test
    action: stop
  when: manual
  script:
    - kubectl delete -f deploy/ -n myapp-test
```

### 多环境配置模板

```yaml
# 使用模板减少重复代码
.deploy-template:
  image: bitnami/kubectl:latest
  variables:
    IMAGE: "$REGISTRY/myapp:$CI_COMMIT_SHORT_SHA"
  script:
    # 使用 envsubst 替换模板中的变量
    - envsubst < deploy/deployment.yaml.tmpl > deploy/deployment.yaml
    - kubectl apply -f deploy/ -n $K8S_NAMESPACE
    - kubectl set image deployment/myapp app=$IMAGE -n $K8S_NAMESPACE
    - kubectl rollout status deployment/myapp -n $K8S_NAMESPACE --timeout=300s

deploy-test:
  extends: .deploy-template
  stage: deploy-test
  environment:
    name: test
    url: https://test.myapp.com
  variables:
    K8S_NAMESPACE: "myapp-test"
    REPLICAS: "1"
    CPU_REQUEST: "100m"
    MEMORY_REQUEST: "256Mi"
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy-staging:
  extends: .deploy-template
  stage: deploy-staging
  environment:
    name: staging
    url: https://staging.myapp.com
  variables:
    K8S_NAMESPACE: "myapp-staging"
    REPLICAS: "2"
    CPU_REQUEST: "500m"
    MEMORY_REQUEST: "512Mi"
  when: manual
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy-prod:
  extends: .deploy-template
  stage: deploy-prod
  environment:
    name: production
    url: https://myapp.com
  variables:
    K8S_NAMESPACE: "myapp-prod"
    REPLICAS: "4"
    CPU_REQUEST: "1000m"
    MEMORY_REQUEST: "1Gi"
  when: manual
  rules:
    - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/
```

### 部署模板文件

```yaml
# deploy/deployment.yaml.tmpl
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: ${K8S_NAMESPACE}
spec:
  replicas: ${REPLICAS}
  template:
    spec:
      containers:
      - name: app
        image: ${IMAGE}
        resources:
          requests:
            cpu: ${CPU_REQUEST}
            memory: ${MEMORY_REQUEST}
          limits:
            cpu: ${CPU_LIMIT}
            memory: ${MEMORY_LIMIT}
```

---

## 三、变量管理分层策略

### 变量层级

```
层级1: .gitlab-ci.yml 中的 variables（非敏感，可入 Git）
  ↓ 覆盖
层级2: GitLab Project Variables（敏感，不入 Git）
  ↓ 覆盖
层级3: GitLab Group Variables（跨项目共享）
  ↓ 覆盖
层级4: GitLab Instance Variables（全局默认）
  ↓ 覆盖
层级5: Job 级 variables（最高优先级）
```

### 非敏感变量 — 入 Git

```yaml
# .gitlab-ci.yml
variables:
  APP_NAME: "myapp"
  REGISTRY: "registry.mycompany.com"
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
  JAVA_VERSION: "17"
```

### 敏感变量 — GitLab Variables

在 GitLab → Settings → CI/CD → Variables 中配置：

```
变量名              值                   保护  Masked
DOCKER_REGISTRY_USER   ci-bot             ✓      ✓
DOCKER_REGISTRY_PASS   ********           ✓      ✓
KUBECONFIG_TEST       base64编码的kubeconfig ✓   ✗
KUBECONFIG_STAGING    base64编码的kubeconfig ✓   ✗
KUBECONFIG_PROD       base64编码的kubeconfig ✓   ✗
SONAR_TOKEN           ********            ✗      ✓
DEPLOY_WEBHOOK        https://hooks...    ✗      ✗
```

**Protected Variables 的含义：**

```
Protected = ✓
  → 只在 protected 分支（默认 main）和 protected Tag 上可用
  → 非 protected 分支（如 feature/*）无法访问
  → 防止从任意分支窃取生产密钥

Masked = ✓
  → 在 CI 日志中显示为 [MASKED]
  → 但只对纯字母数字字符串有效，kubeconfig 这种太长无法 mask
```

> **踩坑提示**：很多团队把所有环境变量都设为 Protected，结果开发分支的流水线因为拿不到变量而失败。正确做法是：生产密钥 Protected，开发密钥不 Protected。

### 变量文件管理

对于大量配置，用文件变量更方便：

```bash
# 在本地创建配置文件
cat > config-test.yaml <<EOF
database:
  host: test-db.mycompany.com
  port: 5432
  name: myapp_test
redis:
  host: test-redis.mycompany.com
  port: 6379
EOF

# 上传到 GitLab Variables（Type: File）
# GitLab → Settings → CI/CD → Variables → Add Variable
#   Key: CONFIG_TEST
#   Type: File
#   Value: 上传 config-test.yaml
```

```yaml
# .gitlab-ci.yml 中使用
deploy-test:
  script:
    # $CONFIG_TEST 是文件路径
    - cp $CONFIG_TEST config.yaml
    - kubectl create configmap app-config --from-file=config.yaml -n myapp-test
```

---

## 四、动态环境（Review Apps）

### 什么是 Review App

每次 MR 都自动创建一个独立的预览环境，方便代码审查：

```
MR #42 → 自动部署 → https://42-review.myapp.com → 审查后合并 → 自动销毁
```

### 实现

```yaml
# 动态环境：每个 MR 创建独立环境
review-deploy:
  image: bitnami/kubectl:latest
  stage: deploy
  environment:
    name: review/$CI_MERGE_REQUEST_IID
    url: https://$CI_MERGE_REQUEST_IID-review.myapp.com
    on_stop: review-stop
    auto_stop_in: 1 day  # 1天后自动销毁
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    # 使用 MR ID 作为命名空间
    - NAMESPACE="review-$CI_MERGE_REQUEST_IID"
    - kubectl create namespace $NAMESPACE
    - sed -i "s/__NAMESPACE__/$NAMESPACE/g" deploy/deployment.yaml
    - sed -i "s/__IMAGE__/$REGISTRY/myapp:$CI_COMMIT_SHORT_SHA/g" deploy/deployment.yaml
    - kubectl apply -f deploy/ -n $NAMESPACE
    - kubectl rollout status deployment/myapp -n $NAMESPACE

# MR 关闭时自动清理
review-stop:
  image: bitnami/kubectl:latest
  stage: deploy
  environment:
    name: review/$CI_MERGE_REQUEST_IID
    action: stop
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual
  script:
    - NAMESPACE="review-$CI_MERGE_REQUEST_IID"
    - kubectl delete namespace $NAMESPACE
```

---

## 五、多项目流水线（Trigger）

### 触发下游项目

```yaml
# 上游项目构建完成后，触发下游部署项目
trigger-deploy:
  stage: deploy
  needs: [package]
  trigger:
    project: devops/deploy-pipeline  # 下游项目路径
    branch: main                       # 下游分支
    strategy: depend                   # 等待下游完成
  variables:
    IMAGE_TAG: "$CI_COMMIT_SHORT_SHA"
    ENVIRONMENT: "staging"
```

### 触发同项目其他分支

```yaml
# 合并到 main 后触发 release 分支的流水线
trigger-release:
  stage: deploy
  needs: [deploy-staging]
  trigger:
    branch: release
    strategy: depend
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
```

### 父子流水线（Child Pipeline）

```yaml
# 父流水线 .gitlab-ci.yml
stages:
  - build
  - child-pipeline

build:
  stage: build
  script: mvn clean package

trigger-child:
  stage: child-pipeline
  needs: [build]
  trigger:
    include: child-pipeline.yml    # 引用子流水线配置
    strategy: depend
    forward:
      pipeline_variables: true     # 传递变量给子流水线
```

```yaml
# child-pipeline.yml（子流水线）
stages:
  - scan
  - deploy

security-scan:
  stage: scan
  script: trivy image $IMAGE_TAG

deploy:
  stage: deploy
  script: kubectl apply -f deploy/
```

> **培训要点**：父子流水线可以把一条很长的流水线拆成多个子流水线，各自独立运行。适合微服务架构——每个服务有自己的子流水线，父流水线负责编排。

---

## 六、本篇要点回顾

1. 多环境部署用 `.deploy-template` + `extends` 消除重复，按 `rules` 区分触发条件
2. 变量分层管理：非敏感入 Git、敏感入 GitLab Variables、生产密钥设 Protected
3. File 类型变量适合传递大量配置，自动生成临时文件路径
4. Review App 为每个 MR 创建临时环境，合并后自动销毁
5. `trigger` 触发下游项目或子流水线，`strategy: depend` 等待完成

**下一篇预告**：《与 Kubernetes 集成：自动化部署到 K8s 集群》——深入 K8s 部署自动化，包括镜像更新、配置管理、健康检查和回滚策略。

基础流水线跑通后，第一个痛点就是"多环境管理"——dev、test、staging、prod 四个环境的配置、密钥、部署策略都不同。本篇讲清楚如何在 GitLab CI 中优雅地管理多环境部署和变量，避免"一堆 if-else 和重复 Job"。

【CI/CD·GitLab篇】进阶实战：多环境部署与 CI/CD 变量管理

研发部经理

开发工具

运维

后端

GitLabCI多环境部署实战：通过模板化Job消除重复代码，实现dev/test自动部署、staging/prod手动控制。采用分层变量管理策略，敏感信息存入GitLab Variables并设置Protected保护。利用Review Apps为每个MR创建临时预览环境，通过trigger实现跨项目流水线编排，提升部署效率与安全性。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

GitLabCI多环境部署实战：通过模板化Job消除重复代码，实现dev/test自动部署、staging/prod手动控制。采用分层变量管理策略，敏感信息存入GitLab Variables并设置Protected保护。利用Review Apps为每个MR创建临时预览环境，通过trigger实现跨项目流水线编排，提升...

【CI/CD·GitLab篇】进阶实战：多环境部署与 CI/CD 变量管理-腾讯云开发者社区-腾讯云

【CI/CD·GitLab篇】进阶实战：多环境部署与 CI/CD 变量管理

【CI/CD·GitLab篇】进阶实战：多环境部署与 CI/CD 变量管理

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐