持续交付进阶：极狐GitLab自动化部署策略详解

当团队已经跑通"构建 → 测试 → 部署"的基础流水线后，下一步是提升部署的可控性与安全性：环境管理、灰度发布、一键回滚、并发合并治理。极狐GitLab内置的部署能力覆盖这些场景，本文将结合官方配置给出可落地的方案。

一、环境（Environments）与部署追踪

极狐GitLab官方将环境定义为"部署代码的目标位置"（如 staging、production）。在 .gitlab-ci.yml 中为作业声明 environment 后，每次部署都会记录到「操作 → 环境」页面，包含提交、作业与时间线，支持一键回滚。

deploy_production:
  stage: deploy
  script:
    - ./deploy.sh production
  environment:
    name: production
    url: https://app.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

二、滚动发布与回滚

滚动发布（Incremental Rollout） 是官方支持的一种渐进式部署方式：分批将新版本实例上线，逐步扩大流量。结合环境记录，团队可以在任意阶段执行 rollback 回退到上一个成功部署。

deploy_canary:
  stage: deploy
  script:
    - ./deploy_canary.sh
  environment:
    name: production/canary
    url: https://canary.app.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

金丝雀环境（canary）作为独立环境记录，先承载少量真实流量验证，再决定是否全量推送——这是生产变更的标准做法。

三、合并列车：治理并发合并冲突

在多分支并行开发场景下，多个 MR 同时命中主分支时，"合并即冲突"的连锁反应会拖慢交付。极狐GitLab专业版及以上提供 Merge Train（合并列车）：MR 按顺序排队合并，每个 MR 合入前都基于最新主分支重新跑一遍流水线，失败即自动退出列车，从机制上消除并发合并的不确定性。

开启方式：在项目的「设置 → 通用 → 合并请求」中启用"Merge when pipeline succeeds（流水线成功后自动合并）"并配置合并列车。

四、Review Apps：PR 级动态环境

官方提供的 Review Apps 能力，可以为每个 MR 自动创建一个临时预览环境。开发者与产品在合并前即可直接访问该分支的实际运行效果，把"环境验收"纳入评审流程：

review_app:
  stage: deploy
  script:
    - ./deploy_review.sh $CI_MERGE_REQUEST_IID
  environment:
    name: review/$CI_MERGE_REQUEST_IID
    on_stop: stop_review_app
  rules:
    - if: $CI_MERGE_REQUEST

stop_review_app:
  stage: deploy
  script:
    - ./teardown_review.sh $CI_MERGE_REQUEST_IID
  environment:
    name: review/$CI_MERGE_REQUEST_IID
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST

MR 关闭时自动触发 stop_review_app 清理临时环境，避免资源泄漏。

五、部署防护：受保护环境

生产环境不应允许任何流水线随意部署。极狐GitLab支持受保护环境（Protected Environments）：仅允许指定角色（如维护者）或用户，在指定分支/标签触发的流水线中向该环境部署，从权限层面锁死生产变更入口。

六、总结

从环境追踪、金丝雀/滚动发布、一键回滚，到合并列车与 Review Apps，极狐GitLab把持续交付的进阶场景全部纳入官方支持范围。团队可以在同一个 .gitlab-ci.yml 体系中，逐步建立"小步快跑、灰度验证、快速回退"的生产级交付能力。

各功能的完整配置项，参见极狐GitLab官方文档中心 docs.gitlab.cn「环境与部署」章节。