如何在GitLab CI流水线中自动更新Helm values文件的前后端版本值

核心逻辑是将版本号变更同步持久化到存放values文件的代码仓库，避免仅靠--set临时传参导致的版本覆盖问题，具体可按以下步骤实现：

方案1：基于GitOps的持久化更新（推荐） #

直接在部署流水线中修改values文件并提交回仓库，符合配置即代码的管理逻辑，溯源方便：

• 第一步：部署流水线启动后，先拉取Helm values仓库的最新代码
• 第二步：根据触发源判断待更新的服务类型，使用yq（YAML命令行处理工具）直接修改values.yaml中的对应版本字段：
  前端版本更新执行：

  yq eval ".frontend.version = \"$FRONTEND_TAG\"" -i values.yaml
  

  后端版本更新执行：

  yq eval ".backend.version = \"$BACKEND_TAG\"" -i values.yaml
  

• 第三步：将修改后的values.yaml提交回当前仓库，提交信息可标注版本变更详情，例如ci: update frontend version to $FRONTEND_TAG，需提前给流水线使用的账号开通仓库的代码推送权限
• 第四步：执行helm部署命令，无需再额外传--set参数，直接读取已更新的values文件即可：

  helm upgrade my-app ./my-chart -n staging -f values.yaml
  

  后续无论前端还是后端触发部署，拉取到的values文件都已存储了两个服务的最新版本号，不会出现旧版本覆盖的问题。

方案2：基于外部版本存储的无提交更新 #

如果不想频繁提交代码到values仓库，可引入独立的KV存储（如Consul、etcd）或者配置中心存储前后端的最新版本号：

• 前端/后端构建镜像完成后，先将新的版本号写入KV存储的对应字段
• 部署流水线执行前，先从KV存储拉取前端、后端的最新版本号
• 执行helm命令时同时传入两个服务的版本参数：

  helm upgrade my-app ./my-chart -n staging -f values.yaml --set frontend.version=$LATEST_FRONTEND_TAG --set backend.version=$LATEST_BACKEND_TAG
  

注意事项 #

• 上述yq命令为v4版本语法，若使用v3版本需调整对应语法规则
• 若存在前后端流水线同时触发的场景，可配置部署流水线串行执行，或添加提交冲突自动重试逻辑，避免代码冲突

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