{{< details >}}

  • Tier: 基础版, 专业版, 旗舰版
  • Offering: JihuLab.com, 私有化部署

{{< /details >}}

部署作业 是一种特定类型的 CI/CD 作业。它们可能比流水线中的其他作业更为敏感，可能需要特别小心对待。极狐GitLab有多种功能可以帮助维护部署的安全性和稳定性。

您可以：

如果您正在使用持续部署工作流，并希望确保不会对同一环境进行并发部署，则应启用以下选项：

限制对关键环境的写入访问

默认情况下，任何至少具有开发者角色的团队成员都可以修改环境。如果您想限制对关键环境（例如 production 环境）的写入访问，可以设置受保护的环境。

确保一次只运行一个部署作业

极狐GitLab CI/CD 中的流水线作业是并行运行的，因此可能会出现两个不同流水线中的部署作业尝试同时部署到同一环境的情况。这不是期望的行为，因为部署应按顺序进行。

您可以使用 .gitlab-ci.yml 中的 resource_group 关键字 来确保一次只运行一个部署作业。

例如：

deploy:
 script: deploy-to-prod
 resource_group: prod

在使用资源组 之前 的问题流水线流示例：

  1. Pipeline-A 中的 deploy 作业开始运行。
  2. Pipeline-B 中的 deploy 作业开始运行。这是并发部署，可能导致意外结果。
  3. Pipeline-A 中的 deploy 作业完成。
  4. Pipeline-B 中的 deploy 作业完成。

在使用资源组 之后 改进的流水线流：

  1. Pipeline-A 中的 deploy 作业开始运行。
  2. Pipeline-B 中的 deploy 作业尝试开始，但等待第一个 deploy 作业完成。
  3. Pipeline-A 中的 deploy 作业完成。
  4. Pipeline-B 中的 deploy 作业开始运行。

有关更多信息，请参阅 资源组文档。

防止过时的部署作业

{{< history >}}

  • 在极狐GitLab 15.5 中更改，以防止过时作业运行。

{{< /history >}}

流水线作业的实际执行顺序可能会因运行而异，这可能导致不期望的行为。例如，较新的流水线中的 部署作业 可能在较旧的流水线中的部署作业之前完成。这会创建一个竞态条件，其中较旧的部署稍后完成，覆盖“较新的”部署。

您可以通过启用 防止过时的部署作业 功能来防止旧的部署作业在启动新的部署作业时运行。

当较旧的部署作业启动时，它会失败，并标记为：

  • 在流水线视图中为 failed outdated deployment job。
  • 在查看完成的作业时为 The deployment job is older than the latest deployment, and therefore failed.。

当较旧的部署作业是手动时，运行 ({{< icon name=”play” >}}) 按钮会被禁用，并显示消息 This deployment job does not run automatically and must be started manually, but it's older than the latest deployment, and therefore can't run.。

作业年龄由作业开始时间而不是提交时间决定，因此在某些情况下可以防止较新的提交。

回滚部署的作业重试

{{< history >}}

  • 在极狐GitLab 15.6 中引入通过作业重试进行回滚。
  • 在极狐GitLab 16.3 中引入回滚部署的作业重试复选框。

{{< /history >}}

您可能需要快速回滚到稳定的过时部署。默认情况下，为 部署回滚 启用流水线作业重试。

要禁用流水线重试，请取消选中 允许回滚部署的作业重试 复选框。您应该在敏感项目中禁用流水线重试。

当需要回滚时，您必须使用先前的提交运行一个新的流水线。

示例

在启用防止过时部署作业 之前 的问题流水线流示例：

  1. 在默认分支上创建 Pipeline-A。
  2. 稍后，在默认分支上创建 Pipeline-B（具有较新的提交 SHA）。
  3. Pipeline-B 中的 deploy 作业首先完成，并部署较新的代码。
  4. Pipeline-A 中的 deploy 作业稍后完成，并部署较旧的代码，覆盖 较新的（最新）部署。

在启用防止过时部署作业 之后 改进的流水线流：

  1. 在默认分支上创建 Pipeline-A。
  2. 稍后，在默认分支上创建 Pipeline-B（具有较新的 SHA）。
  3. Pipeline-B 中的 deploy 作业首先完成，并部署较新的代码。
  4. Pipeline-A 中的 deploy 作业失败，因此不会覆盖来自较新流水线的部署。

在部署冻结窗口期间防止部署

如果您想在特定时期内防止部署，例如在大多数员工休假的计划假期期间，可以设置 部署冻结。在部署冻结期间，无法执行任何部署。这有助于确保部署不会意外发生。

下一个配置的部署冻结在 环境部署列表 页面的顶部显示。

保护生产密钥

生产密钥对于成功部署是必需的。例如，在部署到云时，云提供商需要这些密钥来连接到他们的服务。在项目设置中，您可以为这些密钥定义和保护 CI/CD 变量。受保护的变量 仅传递给在 受保护分支 或 受保护标签 上运行的流水线。其他流水线无法获得受保护变量。您还可以 将变量限定到特定环境。我们建议您在受保护环境上使用受保护变量，以确保密钥不会被意外暴露。您还可以在 runner 端 定义生产密钥。这可以防止具有维护者角色的其他用户读取密钥，并确保 runner 仅在受保护分支上运行。

有关更多信息，请参阅 流水线安全。

为部署设置单独的项目

项目的所有具有维护者角色的用户都可以访问生产密钥。如果您需要限制可以部署到生产环境的用户数量，可以创建一个单独的项目并配置新的权限模型，将 CD 权限与原始项目隔离开来，防止原始项目的维护者角色用户访问生产密钥和 CD 配置。您可以使用 多项目流水线 将 CD 项目连接到您的开发项目。

保护 .gitlab-ci.yml 不被更改

.gitlab-ci.yml 可能包含将应用程序部署到生产服务器的规则。此部署通常在推送合并请求后自动运行。为了防止开发人员更改 .gitlab-ci.yml，您可以在不同的存储库中定义它。该配置可以引用另一个项目中的文件，并具有完全不同的权限集（类似于 为部署设置单独的项目）。在这种情况下，.gitlab-ci.yml 是公开可访问的，但只能由其他项目中具有适当权限的用户编辑。

有关更多信息，请参阅 自定义 CI/CD 配置路径。

部署前需要批准

在将部署提升到生产环境之前，与专门的测试群组进行交叉验证是一种有效的安全保障方法。有关更多信息，请参阅 部署批准。