1. environment：不只是标签，而是“部署锚点”

在 job 上声明 environment 后，GitLab 会把该次执行登记为对某环境的一次部署尝试： 成功、失败、取消都会留下记录。你可以在项目 Operations → Environments 里看到当前 URL、最后一次部署、以及进入历史的入口。 常用字段包括 name、url、deployment_tier（如 development / staging / production，用于展示与策略）， 以及用于回收的 on_stop（见后文 Review App）。

deploy_staging:
  stage: deploy
  script:
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.com
    deployment_tier: staging

2. Deployments：可追溯的发布事实

Deployment 在 GitLab 中关联：环境、pipeline、job、提交、触发者。团队用它做发布沟通、变更管理、以及事故回溯（“线上当前是哪一版？”）。 若结合 Kubernetes、Flux 等 GitOps 工具，仍建议把 GitLab deployment 当作人类可读的里程碑，与集群真实状态交叉验证。

3. Review App：每个 MR 一座“快闪店”

核心模式：用动态环境名区分每个 MR（常用 CI_MERGE_REQUEST_IID 或 CI_COMMIT_REF_SLUG）， 部署到独立子域或命名空间；在 environment 上配置 on_stop 指向清理 job，该 job 使用 action: stop 关闭环境，释放资源。 没有 teardown 的 Review App 会像忘收的展台——账单与攻击面一起涨。

review_app:
  stage: review
  script:
    - ./deploy_review.sh
  environment:
    name: review/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID.review.example.com
    on_stop: stop_review
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

stop_review:
  stage: cleanup
  script:
    - ./teardown_review.sh
  environment:
    name: review/mr-$CI_MERGE_REQUEST_IID
    action: stop
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual

4. 受保护环境、审批与第 42 章的汇合

对 production 等环境可配置 Protected environments 与部署前审批（能力依 GitLab 版本与 tier 有所不同）。 这与受保护分支、受保护变量一起构成“谁能触达线上”的闭环。平台组应把审批人、紧急绕过流程、审计保留写成 runbook，而不是只依赖 UI 记忆。

5. 成本、配额与安全

• 资源上限：每 MR 一套集群命名空间时，设置 CPU/内存配额与自动回收 TTL。
• 数据：预览库是否含脱敏数据；种子数据与生产副本要隔离。
• 入口：Basic Auth、VPN、或内网 Review 网关，避免公网裸奔测试环境。
• 并发 MR：大量 open MR 同时存在时，部署队列与 Runner 容量要建模。

6. 与 GitHub Actions / 其他 CD 的对照

7. 本章清单

1. 为 staging / production 配置 environment 与 deployment_tier，核对 Operations 页展示。
2. 实现最小 Review App：动态 name、可访问 url、可重复的部署脚本。
3. 补齐 on_stop 清理 job，并在团队内约定触发方式（手动 / 自动）。
4. 对生产环境启用审批与受保护策略，与第 42 章变量策略对齐。
5. 监控预览环境数量与云成本，设置配额与告警。