Help us learn about your current experience with the documentation. Take the survey.

使用 GitLab CI/CD 进行渐进式发布

在向应用程序发布变更时，可以将生产环境的变更仅发布到部分 Kubernetes Pod 中，以此作为风险缓解策略。通过逐步发布生产环境的变更，可以监控错误率或性能下降情况，如果没有问题，就可以更新所有 Pod。

GitLab 支持使用渐进式发布功能，对 Kubernetes 生产系统进行手动触发和定时发布。使用手动发布时，每个 Pod 批次的发布都是手动触发的；而在定时发布中，发布会在默认暂停 5 分钟后分批次进行。定时发布也可以在暂停期结束前手动触发。

手动发布和定时发布会自动包含在由 Auto DevOps 控制的项目中，但也可以通过 .gitlab-ci.yml 配置文件中的 GitLab CI/CD 进行配置。

手动触发的发布可以通过持续交付来实现，而定时发布不需要人工干预，可以成为持续部署策略的一部分。你也可以将两者结合使用，让应用程序自动部署，除非必要时你最终需要手动干预。

我们创建了示例应用程序来演示这三种选项，你可以将其作为构建自己应用程序的示例：

手动发布

可以通过 .gitlab-ci.yml 配置 GitLab 来手动进行渐进式发布。手动配置可以让你更好地控制此功能。渐进式发布的步骤取决于部署时定义的 Pod 数量，这些 Pod 是在创建 Kubernetes 集群时配置的。

例如，如果你的应用程序有 10 个 Pod，并且运行了一个 10% 的发布任务，那么应用程序的新实例会被部署到单个 Pod 中，而其余 Pod 显示的是应用程序的旧实例。

.manual_rollout_template: &manual_rollout_template
  <<: *rollout_template
  stage: production
  when: manual

rollout 10%:
  <<: *manual_rollout_template
  variables:
    ROLLOUT_PERCENTAGE: 10

作业构建完成后，选择作业名称旁边的 Run ( ) 来发布每个阶段的 Pod。你也可以通过运行百分比更低的作业来回滚。一旦达到 100%，你就不能使用此方法回滚。要回滚部署，请参阅重试或回滚部署。

有一个可部署的应用程序可用，演示了手动触发的渐进式发布。

定时发布的行为与手动发布相同，只是每个作业在部署前都定义了一个以分钟为单位的延迟。选择作业会显示倒计时。

可以将此功能与手动渐进式发布结合使用，让作业倒计时后进行部署。

.timed_rollout_template: &timed_rollout_template
  <<: *rollout_template
  when: delayed
  start_in: 1 minutes

我们可以使用 start_in 键定义延迟时间：

start_in: 1 minutes

timed rollout 30%:
  <<: *timed_rollout_template
  stage: timed rollout 30%
  variables:
    ROLLOUT_PERCENTAGE: 30

Teams can leverage an Ingress annotation and set traffic weight as an alternative approach to the blue-green deployment strategy documented here.

有时也称为 A/B 部署或红黑部署，这种技术用于减少部署期间的停机时间和风险。当与渐进式发布结合使用时，可以最小化部署导致问题的影响。

使用此技术时，有两个部署（“蓝色"和"绿色”，但可以使用任何命名）。在任何给定时间，只有一个部署处于活跃状态，渐进式发布期间除外。

例如，你的蓝色部署可以在生产环境中活跃，而绿色部署用于测试，但未部署到生产环境。如果发现问题，可以更新绿色部署而不会影响生产部署（当前为蓝色）。如果测试没有发现问题，你就可以将生产环境切换到绿色部署，蓝色现在可用于测试下一个版本。

此过程减少了停机时间，因为不需要关闭生产部署来切换到不同的部署。两个部署并行运行，可以随时切换。