使用极狐GitLab CI/CD 进行增量回滚

当对应用进行更改时，可以仅将生产变更发布到 Kubernetes pods 的一部分作为风险缓解策略。通过逐步发布生产变更，可以监控错误率或性能下降，如果没有问题，所有 pods 都可以更新。

极狐GitLab 支持使用增量发布手动触发和定时发布到 Kubernetes 生产系统。在使用手动发布时，每一批 pods 的发布是手动触发的，而在定时发布中，发布是在默认暂停 5 分钟后以批次进行。定时发布也可以在暂停期结束前手动触发。

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

手动触发的发布可以通过持续交付来实现，而定时发布不需要干预，可以成为您持续部署策略的一部分。您也可以将两者结合，以便应用自动部署，除非您需要手动干预。

手动发布

可以通过 .gitlab-ci.yml 手动配置极狐GitLab 进行增量发布。手动配置允许更好地控制此功能。增量发布的步骤取决于为部署定义的 pods 数量，这些 pods 在创建 Kubernetes 集群时进行配置。

例如，如果您的应用有 10 个 pods，并运行 10% 发布作业，则应用的新实例部署到一个 pod，而其余 pods 显示应用的先前实例。

首先我们将模板定义为手动:

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

然后我们定义每个步骤的发布量:

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

作业构建完成后，选择作业名称旁边的运行 ({{< icon name=”play” >}}) 来发布每个阶段的 pods。您也可以通过运行较低百分比的作业来回滚。一旦达到 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

团队可以利用 Ingress 注释并设置流量权重作为蓝绿部署策略的替代方法。

有时也称为 A/B 部署或红黑部署，这种技术用于减少部署期间的停机时间和风险。结合增量发布，您可以最大限度地减少因部署导致议题的影响。

使用这种技术时，有两个部署（“蓝”和“绿”，但可以使用任何命名）。除了增量发布期间，任何时候只有一个部署是实时的。

例如，您的蓝色部署可以在生产中活动，而绿色部署是用于测试的“实时”状态，但未部署到生产中。如果发现问题，绿色部署可以在不影响生产部署（当前为蓝色）的情况下更新。如果测试没有发现问题，您可以将生产切换到绿色部署，蓝色现在可用于测试下一个版本。

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