多服务Helm Chart的CI/CD流程搭建方案咨询

背景 #

我正在开发一个包含以下服务的应用：

• 前端（Frontend）
• 身份认证服务（IAM）
• 后端（Backend）
• 数据库（Database）

每个服务都有独立的代码仓库，包含源代码和用于构建镜像的Dockerfile。目前我已创建一个包含所有服务的Helm Chart，其values.yaml文件内容如下：

frontend:
  image:
    repository:  "myimage"
    tag: "1.0.0"

iam:
  image:
    repository:  "myimage"
    tag: "1.0.3"

backend:
  image:
    repository:  "myimage"
    tag: "1.0.1"

database:
  image:
    repository:  "myimage"
    tag: "2.0.0"

问题 #

我正在研究为上述场景搭建CI流程的可行方案，但面对众多选项感到困惑。网上的指南多为单服务Helm Chart示例，而我的Chart包含多个相互依赖的服务。根据指南思路，我似乎需要创建一个包含各服务子Chart的Umbrella Chart（顶层聚合Chart），即每个服务拥有独立的Chart。

我想咨询的是：如何为该场景搭建一套规范的CI（及CD）流程？

以下是我初步设计的流程（可能存在问题），我希望尽可能实现自动化：

// 前端代码仓库 | 特性分支
* 触发条件：打开Pull Request（或向该PR提交代码）
- 代码检查（Lint）
- 单元测试
- 代码质量检测
- 构建新镜像（标签=提交哈希值）
- 将镜像推送到镜像仓库
- 检出frontend-chart仓库
- 将新镜像标签提交到frontend-chart仓库的特性分支
- 若未打开PR则创建frontend-chart仓库的PR
- 等待frontend-chart仓库特性分支的构建完成
- 合并到主分支

// frontend-chart仓库 | 特性分支
* 触发条件：打开PR
- 部署前端Chart
- 部署另外3个服务，使用最新打包的Chart
- 运行端到端（E2E）测试
- 合并到主分支

// 前端代码仓库 | 主分支
* 触发条件：提交代码
- 将镜像重新打标签为latest
- 推送镜像
- 触发frontend-chart仓库的构建

// frontend-chart仓库 | 主分支
* 触发条件：由前端代码仓库主分支触发构建
- 确定新的Chart版本号
- 使用新版本号打包Helm Chart
- 添加Git标签
- 推送到ChartMuseum
- 检出umbrella-chart仓库
- 在特性分支中提交更新，将frontend-chart的版本号更新为新版本
- 在umbrella-chart仓库打开PR，将特性分支合并到主分支

// umbrella-chart仓库 | 特性分支
* 触发条件：打开PR
- 部署整个Umbrella Chart
- 运行端到端（E2E）测试
- 合并到主分支

// umbrella-chart仓库 | 主分支
* 触发条件：PR合并或提交代码
- 确定新的Chart版本号
- 使用新版本号打包Chart
- 发布Chart
- 添加Git标签
- 触发到验收环境（acc）的部署

// 环境配置仓库 | acc分支
* 触发条件：由umbrella-chart仓库触发并传入参数
- 部署最新的Umbrella Chart
- 从生产环境导入数据
- 运行端到端（E2E）测试
- 合并到生产分支

// 环境配置仓库 | 生产分支
* 触发条件：PR合并或提交代码
- 部署最新的Umbrella Chart
- 运行端到端（E2E）测试
- （失败时：执行回滚）

流程优化建议 #

1. 仓库结构调整 #

Umbrella Chart是多服务场景下的标准实践，建议优化仓库关联方式：

• 每个服务代码仓库中内置自身的Helm Chart目录（如./charts/frontend），无需单独创建chart-frontend仓库，代码变更时可直接同步更新Chart中的镜像标签，减少跨仓库操作的复杂度。
• Umbrella Chart仓库仅作为顶层依赖管理节点，维护各子Chart的版本依赖关系，不包含具体服务的Chart实现。

2. 镜像标签管理简化 #

• 避免使用latest标签，始终用提交哈希值或语义化版本号作为镜像标签（latest存在版本模糊、缓存歧义问题）。主分支构建时可同时打语义化版本标签（如v1.0.1）和提交哈希标签，便于追溯。

3. 跨仓库触发逻辑优化 #

• 用CI工具的跨仓库触发功能（如GitHub Actions的repository_dispatch、GitLab CI的管道触发）替代手动跨仓库提交PR的步骤，实现自动化更新Umbrella Chart中的子Chart版本。例如：frontend-chart主分支完成打包推送后，自动触发Umbrella Chart仓库的CI流程，更新依赖版本并自动创建PR。

4. 测试分层优化 #

• 特性分支阶段：仅部署当前变更的服务+依赖的稳定版本服务进行测试，无需部署所有服务，减少资源消耗和测试时间。
• 验收环境阶段：必须运行全链路E2E测试，覆盖所有服务的交互场景，验证整体兼容性。

5. 版本管理规范 #

• 严格遵循语义化版本控制（SemVer）：服务镜像版本、Chart版本均使用主版本.次版本.修订版本格式，功能变更升级次版本、Bug修复升级修订版本、不兼容变更升级主版本。
• Chart版本与服务镜像版本保持关联（如Chart版本v1.0.1对应镜像版本v1.0.1），便于追溯匹配。

6. 回滚机制完善 #

• 生产环境部署失败时，除执行Helm回滚，还要确保镜像版本与Chart版本的一致性。通过Git标签记录每次生产部署的Chart版本和对应镜像版本，便于快速回退到已知稳定状态。

内容的提问来源于stack exchange，提问作者Bas