比较两种CI/CD策略以及K8s部署预览

60次阅读

问题描述

在实施新的CI/CD策略时，希望将组织的几十个代码仓库从专用的QA环境分支迁移到在Kubernetes集群中创建的ad-hoc环境中进行部署预览，以实现特性的单独发布，且不会互相阻塞。他提出了两种策略并希望了解每种策略的优缺点以及可能的潜在问题。此外，用户还想知道是否有可以加强这两种策略的修正措施，或者是否存在可供参考的最佳实践。

解决方案

请注意以下操作可能涉及版本差异或风险，确保在执行之前备份相关数据。

策略1：单一CI/CD管线，使用Github环境部署

步骤

开发人员从main分支创建特性分支。
当准备就绪时，开发人员从特性分支创建一个拉取请求合并到main分支。
在pull_request触发事件中，Github Actions运行一个单一的管线，按照以下步骤依次执行任务：
a. 执行CI检查（代码规范检查、静态分析、单元测试）。
b. 使用Github环境部署将代码部署到以分支命名的环境中，无需批准，并执行以下操作：
- 创建并应用一个补丁，使用git diff --cherry main...feature命令（不提交）将代码置于“似乎已合并到main”的状态。
- 构建并发布带有分支名称标签的镜像。
- 创建一个K8s清单，包含新镜像。
- 部署新的K8s清单，创建一个在{branch-name}.example.com可用的环境。
  c. 运行功能测试和动态分析以验证生产环境。可以在此阶段进行手动QA，因为管线在下一步之前会暂停等待批准。
  d. 请求将代码部署到生产环境，需要经理批准。一旦批准，将执行类似于步骤3.2的操作：
- 创建并应用补丁，以防测试镜像创建后main分支有更新。
- 构建并发布带有新生产版本号的镜像。
- 更新生产K8s清单，设置新的生产镜像。
- 部署更新后的K8s清单，将新镜像部署到生产环境。
  e. 在K8s清单中删除{branch-name}.example.com环境，并部署以移除部署预览。
合并拉取请求到main分支（此操作仅由Github Action执行）。
删除特性分支。

策略2：分离的CI和CD管线，使用合并部署

步骤

开发人员从main分支创建特性分支。
当准备就绪时，开发人员从特性分支创建一个拉取请求合并到main分支。
在pull_request触发事件中，Github Actions运行一个CI/构建管线，按照以下步骤依次执行任务：
a. 执行CI检查（代码规范检查、静态分析、单元测试）。
b. 构建并发布带有分支名称标签的镜像。
c. 创建一个K8s清单，包含新镜像。
d. 部署新的K8s清单，创建一个在{branch-name}.example.com可用的环境。
e. 运行功能测试和动态分析以验证生产环境。
经理合并拉取请求。在main分支上触发push事件后，Github Actions运行一个CD管线，按照以下步骤依次执行任务：
a. 构建并发布带有main分支代码的镜像，使用新的生产版本号标签。
b. 更新生产K8s清单，设置新的生产镜像。
c. 部署更新后的K8s清单，将新镜像部署到生产环境。
d. 在K8s清单中删除{branch-name}.example.com环境，并部署以移除部署预览。

总结

根据用户的需求，两种策略都具有一些优点和潜在问题。策略1强调在Github Actions中使用环境部署来实现预览环境，并在部署到生产环境前等待经理批准。策略2则将CI和CD管线分开，通过在main分支的合并来触发生产环境部署。选择哪种策略取决于组织的具体需求和工作流程，以及对环境部署和合并批准的偏好。在实施时，务必仔细考虑各自的优缺点以及潜在的问题，并根据实际情况进行调整和优化。