使用 GitLab CI/CD 增量部署 (BASIC ALL)

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

系统支持使用增量部署手动触发和定时部署到 Kubernetes 生产系统。使用 Manual Rollouts 时，每批 pod 的发布都是手动触发的，而在 Timed Rollouts 中，发布是在默认暂停 5 分钟后分批执行的。 也可以在暂停期到期之前手动触发定时推出。

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

手动触发的发布可以使用您的持续交付方法来实施，而定时发布不需要干预并且可以成为您的持续部署策略。 您还可以通过自动部署应用程序的方式将两者结合起来，除非您最终在必要时手动干预。

手动发布

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

例如，如果您的应用程序有 10 个 Pod，并且运行了 10% 的 rollout 作业，则应用程序的新实例将部署到单个 Pod，而其余 Pod 显示应用程序的前一个实例。

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

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

然后我们定义每一步的发布量： 

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

构建作业后，作业名称旁边会出现一个 运行 按钮。单击 运行 按钮以释放每个阶段的 pod。您还可以通过运行较低百分比的作业来回滚。一旦达到 100%，您将无法使用此方法回滚。仍然可以通过使用环境页面上的 回滚 按钮重新部署旧版本来回滚。

Play button

定时发布

定时发布的行为方式与手动部署相同，不同之处在于每个作业在部署之前定义为延迟数分钟。单击作业会显示倒计时。

Timed rollout

可以将此功能与手动增量部署相结合，以便作业倒计时然后部署。

首先我们将模板定义为定时： 

.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

蓝绿部署

note从 13.7 开始，团队可以利用 Ingress annotation 和设置流量权重作为此处记录的蓝绿部署策略的替代方法。

有时也称为 A/B 部署或红黑部署，此技术用于减少部署期间的停机时间和风险。与增量部署结合使用时，您可以将导致问题的部署的影响降至最低。

使用这种技术有两种部署（“蓝色”和“绿色”，但可以使用任何命名）。 在任何给定时间，只有其中一个部署处于活动状态，增量部署期间除外。

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

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