查看环境和部署
搜搜环境
环境类型
- 创建静态环境
  - UI 界面
  - .gitlab-ci.yml 文件
- 创建动态环境
环境部署级别
配置手动部署
配置 Kubernetes 部署（已弃用）
环境和部署的 CI/CD 变量
作业完成后设置动态环境 URL
- 设置动态环境 URL 示例
跟踪每个部署新包含的合并请求
使用环境
故障排查

环境和部署

环境描述了代码的部署位置。

每次 GitLab CI/CD 将一个版本的代码部署到环境中，就会创建一个部署。

极狐GitLab：

提供每个环境的完整部署历史。
跟踪您的部署，以便您始终了解服务器上部署的内容。

如果你有一个像 Kubernetes 这样的部署服务与您的项目相关联，您可以用它来协助你的部署。

查看环境和部署

先决条件：

您必须至少拥有报告者角色。

有几种方法可以查看特定项目的环境列表：

在项目的概览页面上，如果至少有一个环境可用（未停止）。
在左侧边栏中，选择 部署 > 环境，显示环境。
要查看环境的部署列表，请选择环境名称，例如 staging。

部署仅在部署作业创建之后才会显示在此列表中。

搜搜环境

引入于 15.5 版本。
在文件夹中搜索环境功能引入于 15.7 版本，功能标志为 enable_environments_search_within_folder。默认禁用。

要按名称搜索环境：

在顶部栏中，选择 主菜单 > 项目 并找到您的项目。
在左侧边栏中，选择 部署 > 环境。
在搜索栏中，输入您的搜索词。
- 您的搜索词的长度应为 3 个或更多字符。
- 从环境名称的开头开始匹配。
  - 例如，devel 匹配环境名称 development，但 elop 不匹配。
- 对于具有文件夹名称格式的环境，从基本文件夹名称之后匹配。
  - 例如，当名称为 review/test-app 时，搜索词 test 匹配 review/test-app。
  - 搜索带有前缀如 review/test 的文件夹名称匹配 review/test-app。

环境类型

环境是静态的或动态的：

静态环境
- 通常由连续的部署重用。
- 具有静态名称 - 例如，staging 或 production。
- 手动创建或作为 CI/CD 流水线的一部分创建。
动态环境
- 通常在 CI/CD 流水线中创建并仅由单个部署使用，然后停止或删除。
- 具有动态名称，通常基于 CI/CD 变量的值。
- 作为 review apps 的一项功能。

创建静态环境

您可以在 UI 或您的 .gitlab-ci.yml 文件中创建静态环境。

UI 界面

先决条件：

您必须至少具有开发者角色。

要在 UI 中创建静态环境：

在顶部栏上，选择 主菜单 > 项目 并找到您的项目。
在左侧边栏上，选择 部署 > 环境。
选择 新建环境。
配置各个字段。
选择保存。

`.gitlab-ci.yml` 文件

先决条件：

您必须至少具有开发者角色。

要创建静态环境，请在您的 .gitlab-ci.yml 文件中：

在 deploy 阶段定义一个作业。
在作业中，定义环境 name 和url。如果流水线运行时不存在该名称的环境，则会创建它。

环境名称中不能使用某些字符。有关 environment 关键字的更多信息，请参阅 .gitlab-ci.yml 关键字参考。

例如，要创建一个名为 staging 的环境，URL 为 https://staging.example.com：

deploy_staging:
  stage: deploy
  script:
    - echo "Deploy to staging server"
  environment:
    name: staging
    url: https://staging.example.com

创建动态环境

要创建动态环境，您可以使用每个流水线唯一的 CI/CD 变量。

先决条件：

您必须至少具有开发者角色。

要创建动态环境，请在您的 .gitlab-ci.yml 文件中：

在 deploy 阶段定义一个作业。
在作业中，定义以下环境属性：
- name：使用相关的 CI/CD 变量，如 $CI_COMMIT_REF_SLUG。（可选）向环境名称添加静态前缀，在 UI 中分组所有具有相同前缀的环境。
- url：可选。在主机名前加上相关的 CI/CD 变量，例如 $CI_ENVIRONMENT_SLUG。

环境名称中不能使用某些字符。有关 environment 关键字的更多信息，请参阅 .gitlab-ci.yml 关键字参考。

在以下示例中，每次运行 deploy_review_app 作业时，环境的名称和 URL 都使用唯一值定义。

deploy_review_app:
  stage: deploy
  script: make deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
  only:
    - branches
  except:
    - main

环境部署级别

引入于 13.10 版本。

有时，您可能不想使用行业标准环境名称（如 production），而是希望使用代码名称（如 customer-portal）。虽然没有技术上的理由不使用 “customer-portal 这样的名称，但该名称不再表明该环境用于生产。

要指示特定环境用于特定用途，您可以使用 tier：

环境 tier	环境名称示例
`production`	Production, Live
`staging`	Staging, Model, Demo
`testing`	Test, QC
`development`	Dev, Review apps, Trunk
`other`

默认情况下，系统假定一个基于环境名称的 tier。相反，您可以使用 deployment_tier 关键字来指定 tier。

配置手动部署

您可以创建需要有人手动启动部署的作业。例如：

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  environment:
    name: production
    url: https://example.com
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

when: manual 操作：

在 GitLab UI 中公开作业的运行按钮，带有可以手动部署到<环境>的文字。
表示只有在单击运行按钮时才会触发 deploy_prod 作业。

您可以在流水线、环境、部署和作业视图中找到运行按钮。

配置 Kubernetes 部署（已弃用）

引入于 12.6 版本。
废弃于 14.5 版本。

此功能废弃于 14.5 版本。

如果您要部署到与您的项目关联的 Kubernetes 集群，您可以从您的 .gitlab-ci.yml 文件中配置这些部署。

由极狐GitLab 管理的 Kubernetes 集群不支持 Kubernetes 配置。

支持以下配置选项：

namespace

在以下示例中，该作业将您的应用程序部署到 production Kubernetes 命名空间。

deploy:
  stage: deploy
  script:
    - echo "Deploy to production server"
  environment:
    name: production
    url: https://example.com
    kubernetes:
      namespace: production
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

当您使用 GitLab Kubernetes 集成部署到 Kubernetes 集群时，您可以查看集群和命名空间信息。在部署作业页面上，它显示在作业跟踪上方：

环境和部署的 CI/CD 变量

创建环境时，指定名称和 URL。

如果要在另一个作业中使用名称或 URL，可以使用：

$CI_ENVIRONMENT_NAME。.gitlab-ci.yml 文件中定义的名称。
$CI_ENVIRONMENT_SLUG。例如，名称的 “cleaned-up” 版本，适用于 URL 和 DNS。这个变量保证是唯一的。
$CI_ENVIRONMENT_URL。环境的 URL，在 .gitlab-ci.yml 文件中指定或自动分配。

如果更改现有环境的名称，则：

$CI_ENVIRONMENT_NAME 变量更新为新的环境名称。
$CI_ENVIRONMENT_SLUG 变量保持不变以防止意外的副作用。

作业完成后设置动态环境 URL

在作业脚本中，您可以指定静态环境 URL。但是，有时您可能需要动态 URL。例如，如果您将 Review App 部署到每次部署生成随机 URL 的外部托管服务，例如 https://94dd65b.amazonaws.com/qa-lambda-1234567。在这种情况下，在部署脚本完成之前您不知道 URL。如果要在极狐GitLab 中使用环境 URL，则必须手动更新它。

为了解决这个问题，您可以配置一个部署作业来报告一组变量。这些变量包括由外部服务动态生成的 URL。系统支持 dotenv (.env) 文件格式，并使用 .env 文件中定义的变量扩展 environment:url 值。

要使用此功能，请在 .gitlab-ci.yml 中指定 artifacts:reports:dotenv 关键字。

设置动态环境 URL 示例

以下示例显示了一个 Review App，它为每个合并请求创建一个新环境。review 作业由每次推送触发，并创建或更新名为 review/your-branch-name 的环境。环境 URL 设置为 $DYNAMIC_ENVIRONMENT_URL：

review:
  script:
    - DYNAMIC_ENVIRONMENT_URL=$(deploy-script)                                 # In script, get the environment URL.
    - echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env    # Add the value to a dotenv file.
  artifacts:
    reports:
      dotenv: deploy.env                                                       # Report back dotenv file to rails.
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: $DYNAMIC_ENVIRONMENT_URL                                              # and set the variable produced in script to `environment:url`
    on_stop: stop_review

stop_review:
  script:
    - ./teardown-environment
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop

一旦 review 作业完成，系统就会更新 review/your-branch-name 环境的 URL。通过解析 deploy.env 报告产物，将变量列表注册为 runtime-created，使用它来扩展 environment:url: $DYNAMIC_ENVIRONMENT_URL 并将其设置为环境 URL。您还可以在 environment:url 指定 URL 的静态部分，例如 https://$DYNAMIC_ENVIRONMENT_URL。如果 DYNAMIC_ENVIRONMENT_URL的值为 example.com，则最终结果为 https://example.com。

为 review/your-branch-name 环境分配的 URL 在 UI 中可见。

请注意以下事项：

stop_review 不会生成 dotenv 报告产物，因此它无法识别 DYNAMIC_ENVIRONMENT_URL 环境变量。因此您不应该在 stop_review 作业中设置 environment:url。
如果环境 URL 无效（例如，URL 格式错误），系统不会更新环境 URL。
如果在 stop_review 中运行的脚本只存在于您的仓库中，因此不能使用 GIT_STRATEGY: none，请为这些作业配置合并请求流水线。这确保即使在删除功能分支后， runners 也可以获取仓库。有关更多信息，请参阅 runners 参考规范。

对于 Windows runners，使用 echo 写入 .env 文件可能会失败。在这种情况下，使用 PowerShell Add-Content 命令会有所帮助。例如：

Add-Content -Path deploy.env -Value "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL"

跟踪每个部署新包含的合并请求

极狐GitLab 可以跟踪每个部署中新包含的合并请求。当部署成功时，系统会计算最新部署和先前部署之间的提交差异。此跟踪信息可以通过 Deployment API 获取并在合并请求页面，显示在合并后的流水线中。

要激活此跟踪，您的环境必须配置如下：

环境名称没有用 /（即顶级/长期环境），或
环境 tier 为 production 或 staging。

以下是 .gitlab-ci.yml 中 environment 关键字的示例设置：

# Trackable
environment: production
environment: production/aws
environment: development

# Non Trackable
environment: review/$CI_COMMIT_REF_SLUG
environment: testing/aws

使用环境

配置环境后，极狐GitLab 提供了许多使用它们的功能，如下所述。

环境回滚

当您在特定提交上回滚部署时，会创建一个新部署。此部署有自己唯一的作业 ID。它指向您要回滚的提交。

为了使回滚成功，部署过程必须在作业的 script 中定义。

重试或回滚部署

如果部署出现问题，您可以重试或回滚。

要重试或回滚部署：

在顶部栏上，选择 菜单 > 项目 并找到您的项目。
在左侧边栏上，选择 部署 > 环境。
选择环境。
在部署名称的右侧：
- 要重试部署，请选择 重新部署至环境。
- 要回滚到部署，在之前成功的部署旁边，选择 回滚环境。

如果您的项目中阻止过期的部署作业，回滚按钮可能会被隐藏或禁用。在这种情况下，请参阅如何回滚到过期的部署。

环境 URL

环境 URL 显示在极狐GitLab 的几个地方：

在作为链接的合并请求中：
在环境视图中作为一个按钮：
在部署视图中作为一个按钮：

如果出现以下情况，您可以在合并请求中看到此信息：

合并请求最终合并到默认分支（通常是 main）。
该分支还部署到环境（例如，staging 或 production）。

例如：

从源文件转到公共页面

使用 GitLab Route Maps，您可以直接从源文件转到为 Review Apps 设置的环境中的公共页面。

停止环境

当您停止环境时：

在环境页面上，它从 可用的 环境列表移动到 已停止 环境列表。
执行 on_stop 操作（如果已定义）。

有多种方法可以清理动态环境：

如果您使用合并请求流水线，当合并请求被合并或关闭时，系统停止环境。
如果您不使用合并请求流水线，当关联的功能分支被删除时，系统停止环境。
如果您设置环境的到期期限，当环境到期时，系统停止环境。

删除分支时停止环境

您可以将环境配置为在删除分支时停止。

以下示例显示了一个 deploy_review 作业，它调用 stop_review 作业来清理和停止环境。

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review

stop_review:
  stage: deploy
  script:
    - echo "Remove review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  when: manual

两个作业必须具有相同的 rules 或 only/except 配置。否则，stop_review 作业可能不会包含在具有 deploy_review 作业的所有流水线中，并且您无法触发 action: stop 来自动停止环境。

如果比启动环境的作业晚。带有 action: stop 的作业可能不会运行。

如果您不能使用合并请求流水线，请将 GIT_STRATEGY 在 stop_review 作业中设置为 none。然后 runner 在分支被删除后不会尝试检出代码。

在 .gitlab-ci.yml 参考中阅读更多内容。

合并或关闭合并请求时停止环境

您可以将环境配置为在合并或关闭合并请求时停止。当您使用合并请求流水线时，此停止触发器会自动启用。

以下示例显示了一个调用 stop_review 作业来清理和停止环境的 deploy_review 作业。

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    on_stop: stop_review
  rules:
    - if: $CI_MERGE_REQUEST_ID

stop_review:
  stage: deploy
  script:
    - echo "Remove review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual

当另一个作业完成时停止一个环境

您可以将环境设置为在另一个作业完成时停止。

在您的 .gitlab-ci.yml 文件中，在 on_stop: 关键字中指定停止环境的作业的名称。

以下示例显示了一个 review_app 作业，它在第一个作业完成后调用了一个 stop_review_app 作业。stop_review_app 是根据 when 下定义的内容触发的。在这种情况下，它被设置为 manual，因此它需要来自 GitLab UI 的手动操作运行。

两个作业必须具有相同的规则或仅/除外配置。在本例中，如果配置不相同：

stop_review_app 作业可能不会包含在包含 review_app 作业的所有流水线中。
无法触发 action: stop 来自动停止环境。

同样在示例中，GIT_STRATEGY 设置为 none。如果 stop_review_app 作业是自动触发，则在删除分支后 runner 不会尝试检出代码。

stop_review_app 作业必须定义以下关键字：

when，定义于：
- 工作级别。
- 在规则子句中。如果您使用 rules: 和 when: manual，您还应该设置 allow_failure: true，这样即使作业没有运行，流水线也可以完成。
environment:name
environment:action

review_app:
  stage: deploy
  script: make deploy-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review_app

stop_review_app:
  stage: deploy
  variables:
    GIT_STRATEGY: none
  script: make delete-app
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop

在特定时间段后停止环境

您可以将环境设置为在特定时间段后自动停止。

在你的 .gitlab-ci.yml 文件中，指定 environment:auto_stop_in 关键字。您可以指定一个人性化的日期作为值，例如 1 hour and 30 minutes 或 1 day。时间段过去后，系统会自动触发作业以停止环境。

由于资源限制，用于停止环境的后台 worker 每小时仅运行一次。这意味着环境不会在指定的确切时间戳处停止，而是在每小时 cron 工作器检测到过期环境时停止。

在以下示例中，每个合并请求都会创建一个 Review App 环境。每次推送都会触发 review_app 作业，并创建或更新名为 review/your-branch-name 的环境。环境运行直到 stop_review_app 被执行：

review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    on_stop: stop_review_app
    auto_stop_in: 1 week
  rules:
    - if: $CI_MERGE_REQUEST_ID

stop_review_app:
  script: stop-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual

只要合并请求处于活动状态并不断获得新的提交，Review App 就不会停止。开发者无需担心重新启动 Review App。

因为 stop_review_app 设置为 auto_stop_in: 1 week，如果一个合并请求超过一个星期没有活动，系统自动触发 stop_review_app 作业来停止环境。

在不运行 `on_stop` 操作的情况下停止环境

有时您可能想在不运行定义的 on_stop 操作的情况下停止环境。例如，您想在不使用 CI/CD 分钟数的情况下删除许多环境。

要在不运行定义的 on_stop 操作的情况下停止环境，请使用参数 force=true 执行停止环境 API。

通过 UI 停止环境

要触发 on_stop 操作并从环境视图手动停止环境，停止和部署作业必须位于相同的 resource_group 中。

要在 UI 中停止环境：

在顶部栏中，选择 主菜单 > 项目 并找到您的项目。
在左侧边栏中，选择 部署 > 环境。
在您要停止的环境旁边，选择停止。
在确认对话框中，选择 停止环境。

环境的多个停止操作

引入于 14.10 版本，带有名为 environment_multiple_stop_actions 的功能标志。默认禁用。
一般可用于 15.0 版本。功能标志 environment_multiple_stop_actions 已删除。 FLAG: 在私有化部署实例上，默认情况下此功能不可用。要使其可用，请要求管理员启用名为 environment_multiple_stop_actions 的功能标志。在 SaaS 上，此功能不可用。

当您需要对环境执行多个并行停止操作时，此功能很有用。

要在环境上配置多个停止操作，请在 .gitlab-ci.yml 文件中定义的相同 environment 的多个部署作业中指定 on_stop 关键字。

当环境停止时，仅来自成功部署作业的匹配 on_stop 操作会以无特定顺序并行运行。

在以下示例中，对于 test 环境，有两个部署作业 deploy-to-cloud-a 和 deploy-to-cloud-b。

deploy-to-cloud-a:
  script: echo "Deploy to cloud a"
  environment:
    name: test
    on_stop: teardown-cloud-a

deploy-to-cloud-b:
  script: echo "Deploy to cloud b"
  environment:
    name: test
    on_stop: teardown-cloud-b

teardown-cloud-a:
  script: echo "Delete the resources in cloud a"
  environment:
    name: test
    action: stop
  when: manual

teardown-cloud-b:
  script: echo "Delete the resources in cloud b"
  environment:
    name: test
    action: stop
  when: manual

当环境停止时，系统会并行运行 on_stop 操作 teardown-cloud-a 和 teardown-cloud-b。

查看部署的计划停止时间

您可以在 GitLab UI 中查看部署的到期日期。

在顶部栏上，选择 菜单 > 项目 并找到您的项目。
在左侧边栏上，选择 部署 > 环境。
选择部署名称。

在左上角，在环境名称旁边，显示到期日期。

覆盖部署的预定停止时间

您可以手动覆盖部署的到期日期。

在顶部栏上，选择 菜单 > 项目 并找到您的项目。
在左侧边栏上，选择 部署 > 环境。
选择部署名称。
在右上角，选择图钉 ()。

auto_stop_in 设置被覆盖，环境保持活动状态，直到它被手动停止。

删除环境

当您想要删除环境及其所有部署时，请删除该环境。

先决条件：

您必须至少具有开发者角色。
您必须先停止环境才能将其删除。

要在 UI 中删除环境：

在顶部栏上，选择 菜单 > 项目 并找到您的项目。
在左侧边栏上，选择 部署 > 环境。
选择 已停止 选项卡。
在要删除的环境旁边，选择 删除环境。
在确认对话框中，选择 删除环境。

访问环境用于准备或验证的环境

引入于 13.2 版本

您可以定义访问环境用于各种目的的作业，例如验证或准备，可以有效地绕过部署创建，以便您可以更准确地调整 CD 工作流程。

为此，请将 action: prepare、action: verify 或 action: access 添加到作业的 environment 部分：

build:
  stage: build
  script:
    - echo "Building the app"
  environment:
    name: staging
    action: prepare
    url: https://staging.example.com

这使您可以访问环境范围变量，并可用于保护构建免受未经授权的访问。您可以访问环境范围的变量，并可用于保护构建免受未经授权的访问。此外，有效避免阻止过期的部署作业功能。

分组相似的环境

您可以将环境分组到 UI 中的可折叠部分。

例如，如果您的所有环境都以名称 review 开头，那么在 UI 中，环境将分组在该标题下：

下面的例子展示了如何用 review 开始您的环境名称。 $CI_COMMIT_REF_SLUG 变量在运行时用分支名称填充：

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG

环境事件管理

生产环境可能会意外停机，包括由于您无法控制的原因。例如，外部依赖、基础设施或人为错误的问题可能会导致环境出现重大问题。例如：

依赖的云服务出现故障。
更新了第三方库，它与您的应用程序不兼容。
有人对您服务器中的易受攻击的端点进行 DDoS 攻击。
运营商错误配置基础设施。
在生产应用程序代码中引入了一个错误。

您可以使用事件管理在出现需要立即关注的关键问题时获取警报。

查看环境的最新警报

引入于 13.4 版本

如果您为 Prometheus 指标设置警报，环境警报将显示在环境页面上。显示具有最高严重性的警报，因此您可以确定哪些环境需要立即关注。

当触发警报的问题得到解决后，它会被删除并且在环境页面上不再可见。

如果警报需要回滚，您可以从环境页面中选择部署选项卡，然后选择要回滚到的部署。

自动回滚

引入于 13.7 版本

在典型的持续部署工作流中，CI 流水线在部署到生产之前测试每个提交。但是，有问题的代码仍然可以投入生产。例如，逻辑上正确的低效代码可以通过测试，即使它会导致严重的性能下降。运营商和 SRE 监控系统尽快发现这些问题。如果他们发现有问题的部署，他们可以回滚到以前的稳定版本。

系统自动回滚通过在检测到严重警报时，自动触发回滚来简化此工作流程。系统选择并重新部署最近成功的部署。

系统自动回滚的限制：

如果检测到警报时部署正在运行，则会跳过回滚。
回滚只能在三分钟内发生一次。如果一次检测到多个警报，则只执行一次回滚。

系统自动回滚默认是关闭的。要开启：

在顶部栏上，选择 菜单 > 项目 并找到您的项目。
在左侧边栏上，选择 设置 > CI/CD。
展开 自动部署回滚。
选中 启用自动回滚 复选框。
选择 保存修改。

在本地检出部署

每次部署都会在 Git 仓库中保存一个引用，因此只需通过 git fetch 即可了解当前环境的状态。

在您的 Git 配置中，将 [remote "<your-remote>"] 块附加一个额外的提取行：

fetch = +refs/environments/*:refs/remotes/origin/environments/*

存档旧部署

引入于 14.5 版本。适用于自助管理版于 14.6 版本。

当您的项目中发生新部署时，系统会创建一个特殊的 Git-ref 部署。由于这些 Git-refs 是从远端 GitLab 仓库填充的，您会发现一些 Git 操作，例如 git-fetch 和 git-pull，随着项目中部署数量的增加而变慢。

为了保持 Git 操作的效率，系统仅保留最近的部署 refs（最多 50,000 个）并删除其余的旧部署 refs。存档部署在 UI 中或通过使用 API 仍然可用，用于审计目的。此外，您仍然可以通过指定提交 SHA（例如，git checkout <deployment-sha>）从仓库中获取部署的提交，即使在存档之后也是如此。

系统将所有提交保留为 keep-around refs 以便部署的提交不会被垃圾收集，即使它没有被部署 refs 引用。

限制 CI/CD 变量的环境范围

群组 CI/CD 变量的环境范围设置添加到专业版于 13.11 版本。

默认情况下，所有 CI/CD 变量都可用于流水线中的任何作业。因此，如果项目在测试作业中使用受损工具，它可能会暴露部署作业使用的所有 CI/CD 变量。这是供应链攻击中的常见场景。极狐GitLab 通过限制变量的环境范围来帮助缓解供应链攻击。

您可以通过定义可用于哪些环境来限制 CI/CD 变量的环境范围。例如，如果环境范围是 production，那么只有定义了环境 production 的作业才会有这个特定的变量。

默认环境范围是通配符 (*)，这意味着任何作业都可以具有此变量，无论是否定义了环境。

如果环境范围是 review/*，那么对于环境名称以 review/ 开头的作业，该变量可用。

在大多数情况下，这些功能使用 environment specs 机制，它提供了一种在每个环境组中实现范围界定的有效方法。

例如，如果有四个环境：

production
staging
review/feature-1
review/feature-2

每个环境都可以与以下 environment spec 匹配：

Environment Spec	`production`	`staging`	`review/feature-1`	`review/feature-2`
*	匹配	匹配	匹配	匹配
production	匹配
staging		匹配
review/*			匹配	匹配
review/feature-1			匹配

您可以使用特定匹配来选择特定环境。您还可以使用通配符匹配 (*) 来选择特定的环境组，例如 Review Apps。

最具体的 specs 优先于其他通配符匹配。在这种情况下，review/feature-1 spec 优先于 review/* 和 * spec。

故障排查

带有 `action:stop` 的作业没有运行

在某些情况下，分支删除时环境不会停止。

例如，环境可能从一个有失败的作业的阶段开始。然后后期阶段的作业不会开始。如果环境中带有 action: stop 的作业也处于后期阶段，则它无法启动并且环境不会被删除。

为确保 action: stop 可以在需要时始终运行，您可以：

将两个作业放在同一阶段：

stages:
  - build
  - test
  - deploy

...

deploy_review:
  stage: deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review

stop_review:
  stage: deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  when: manual

向 action: stop 作业添加 needs 条目，以便作业可以不按阶段顺序启动：

stages:
  - build
  - test
  - deploy
  - cleanup

...

deploy_review:
  stage: deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review

stop_review:
  stage: cleanup
  needs:
    - deploy_review
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  when: manual

部署作业失败，并显示 “This job could not be executed because it would create an environment with an invalid parameter” 错误

引入于 14.4 版本。

如果您的项目配置为创建动态环境，您可能会遇到此错误，因为动态生成的参数不能用于创建环境。

例如，您的项目具有以下 .gitlab-ci.yml：

deploy:
  script: echo
  environment: production/$ENVIRONMENT

由于流水线中不存在 $ENVIRONMENT 变量，系统尝试创建一个名为 production/ 的环境，这在环境名称约束中是无效的。

要解决此问题，请使用以下解决方案之一：

从部署作业中删除 environment 关键字。系统已经忽略了 invalid 关键字，因此即使在删除关键字后，您的部署流水线也保持完整。
确保变量存在于流水线中。请注意，支持的变量有限制。

如果您在 Review Apps 上收到此错误

例如，如果您的 .gitlab-ci.yml 中有以下内容：

review:
  script: deploy review app
  environment: review/$CI_COMMIT_REF_NAME

当创建一个分支名称为 bug-fix! 的新合并请求时，review 作业会尝试创建一个带有 review/bug-fix! 的环境。但是，! 是环境的无效字符，因此部署作业将失败，因为它即将在没有环境的情况下运行。

要解决此问题，请使用以下解决方案之一：

重新创建没有无效字符的功能分支，例如 bug-fix。
将 CI_COMMIT_REF_NAME 预定义变量替换为去掉任何无效字符的 CI_COMMIT_REF_SLUG：
```
review:
  script: deploy review app
  environment: review/$CI_COMMIT_REF_SLUG
```

未找到部署 refs

从 14.5 版本开始，系统删除旧的部署 refs 以保持您的 Git 仓库的性能。

如果您必须恢复存档的 Git-refs，请让自助管理实例的管理员在 Rails 控制台上执行以下命令：

Project.find_by_full_path(<your-project-full-path>).deployments.where(archived: true).each(&:create_ref)

请注意，将来可能会出于性能问题放弃此支持。

环境和部署

查看环境和部署

搜搜环境

环境类型

创建静态环境

UI 界面

.gitlab-ci.yml 文件

创建动态环境

环境部署级别

配置手动部署

配置 Kubernetes 部署（已弃用）

环境和部署的 CI/CD 变量

作业完成后设置动态环境 URL

设置动态环境 URL 示例

跟踪每个部署新包含的合并请求

使用环境

环境回滚

重试或回滚部署

环境 URL

从源文件转到公共页面

停止环境

删除分支时停止环境

合并或关闭合并请求时停止环境

当另一个作业完成时停止一个环境

在特定时间段后停止环境

在不运行 on_stop 操作的情况下停止环境

通过 UI 停止环境

环境的多个停止操作

查看部署的计划停止时间

覆盖部署的预定停止时间

删除环境

访问环境用于准备或验证的环境

分组相似的环境

环境事件管理

查看环境的最新警报

自动回滚

在本地检出部署

存档旧部署

限制 CI/CD 变量的环境范围

故障排查

带有 action:stop 的作业没有运行

部署作业失败，并显示 “This job could not be executed because it would create an environment with an invalid parameter” 错误

如果您在 Review Apps 上收到此错误

未找到部署 refs

`.gitlab-ci.yml` 文件

在不运行 `on_stop` 操作的情况下停止环境

带有 `action:stop` 的作业没有运行