像搭积木一样设计流水线：用GitLab CI的tags、rules和when玩转多环境发布
像搭积木一样设计流水线：用GitLab CI的tags、rules和when玩转多环境发布
在软件交付过程中，多环境发布是每个技术团队必须面对的挑战。想象一下这样的场景：开发团队频繁提交代码到feature分支，测试团队需要快速验证功能，而生产环境则要求严格的变更控制。如何用一套优雅的CI/CD流水线满足这些不同需求？GitLab CI提供的tags、rules和when等关键字就像乐高积木，让我们可以灵活组装出适应各种场景的自动化工作流。
1. Runner标签系统：用tags构建专属执行环境
为不同环境选择正确的Runner是稳定性的第一道防线。我们给测试环境的Runner打上test-env标签，生产环境则使用带有prod-env标签的高性能Runner：
deploy_to_test: stage: deploy script: ./deploy-test.sh tags: - test-env - docker deploy_to_prod: stage: deploy script: ./deploy-prod.sh tags: - prod-env - high-memory标签组合策略：
- 基础标签（如
docker）定义运行时环境 - 环境标签（如
prod-env）确保隔离性 - 能力标签（如
high-memory）匹配资源需求
提示：在Runner配置中设置
lock_to_project可以防止生产环境任务被意外调度到测试Runner
2. 智能触发逻辑：从only/except到rules的进化
传统的only/except语法正在被更强大的rules取代。下面这个例子展示了如何根据分支类型自动调整测试强度：
test: stage: test script: ./run-tests.sh rules: - if: '$CI_COMMIT_BRANCH =~ /^feature/' changes: [ "src/**/*" ] variables: TEST_LEVEL: "quick" - if: '$CI_COMMIT_BRANCH == "main"' variables: TEST_LEVEL: "full" - when: manual allow_failure: truerules的决策维度：
| 判断条件 | 适用场景 | 典型用例 |
|---|---|---|
| branch匹配 | 区分功能分支与主干 | feature/*触发快速测试 |
| 文件变更 | 精准触发相关任务 | 仅当Dockerfile变更时构建镜像 |
| 变量判断 | 环境差异化配置 | 根据部署区域选择镜像仓库 |
| 手动确认 | 关键步骤人工卡点 | 生产发布前的最终确认 |
3. 环境间编排：when控制的发布节奏
多环境发布的核心是控制流程节奏。通过when关键字，我们可以实现开发环境的自动推进与生产环境的手动确认：
stages: - build - deploy-test - deploy-staging - deploy-prod - rollback build_image: stage: build script: docker build -t $CI_REGISTRY_IMAGE . rules: - if: '$CI_COMMIT_BRANCH != "main"' deploy_test: stage: deploy-test script: ./deploy.sh test needs: [build_image] when: on_success deploy_prod: stage: deploy-prod script: ./deploy.sh prod environment: production when: manual needs: [deploy_staging] rollback_prod: stage: rollback script: ./rollback.sh when: on_failure needs: [deploy_prod]when的典型组合拳：
- 自动流水线：开发环境使用
when: on_success实现提交即部署 - 人工卡点：生产环境设置
when: manual配合审批流程 - 安全网机制：配置
when: on_failure的自动回滚任务
4. 高级模式：动态流水线设计
对于复杂场景，可以结合variables和rules实现完全动态的流水线：
variables: DEPLOY_ENV: "none" determine_env: stage: .pre script: | if [[ "$CI_COMMIT_BRANCH" == feature/* ]]; then echo "DEPLOY_ENV=test" >> deploy.env elif [[ "$CI_COMMIT_TAG" =~ v[0-9]+ ]]; then echo "DEPLOY_ENV=prod" >> deploy.env fi artifacts: reports: dotenv: deploy.env deploy: stage: deploy script: ./deploy-$DEPLOY_ENV.sh rules: - if: '$DEPLOY_ENV != "none"'这个模式实现了：
- 前置任务分析代码特征决定部署目标
- 通过dotenv artifacts传递环境变量
- 只有匹配条件的部署任务才会被创建
5. 避坑指南：实际项目中的经验之谈
在金融项目中，我们发现这些实践特别有价值：
标签管理规范：
- 使用
region-前缀区分地理位置的Runner - 为GPU加速的任务保留专用标签
- 每月清理闲置Runner的陈旧标签
- 使用
rules的黄金法则：
# 反模式：过于复杂的条件判断 rules: - if: '$VAR1 && ($VAR2 || $VAR3) && !$VAR4' # 推荐：拆分为多个清晰规则 rules: - if: '$VAR1 && $VAR2 && !$VAR4' - if: '$VAR1 && $VAR3 && !$VAR4'- 生产环境必须配置：
- 部署超时自动取消
- 并发控制防止重复发布
- 关键操作留下审计日志
deploy_prod: timeout: 30 minutes interruptible: true parallel: 1 rules: - if: '$CI_COMMIT_TAG' when: manual allow_failure: false把这些积木块组合起来，我们最终得到的不是一堆杂乱无章的YAML配置，而是一个有明确阶段划分、环境隔离和风险控制的发布工作流。每次代码提交都会自动找到最适合的运行路径，而生产部署则牢牢掌握在可控的手动确认环节。