GitLab CI/CD：多环境下Kubernetes应用部署方案咨询

不需要依赖semantic-release的话，有几个轻量且高效的方案：

• 用jq直接解析（推荐，多数GitLab CI环境预装jq）
  可以在变量定义阶段直接提取，或者在build_image的前置步骤中设置：

  variables:
    IMAGE_NAME: react-app
    IMAGE_TAG: $(jq -r '.version' package.json)
  
  # 或者在build_image阶段的before_script里动态设置
  build_image:
    before_script:
      - export IMAGE_TAG=$(jq -r '.version' package.json)
      - echo "$REGISTRY_PASS" | docker login $REGISTRY_URL -u $REGISTRY_USER --password-stdin
  

  如果环境没有jq，可利用npm 7+自带的pkg命令提取：

  export IMAGE_TAG=$(npm pkg get version | tr -d '"')
  

• 用简单Node脚本提取
  写一个极简的get-version.js：

  const pkg = require('./package.json');
  console.log(pkg.version);
  

  然后在CI中调用：

  export IMAGE_TAG=$(node get-version.js)
  

如果你的场景需要自动版本递增、生成CHANGELOG等完整语义化版本管理流程，semantic-release是合适的选择；但如果只是提取现有version，上述轻量方案更高效。

你当前的replace_placeholders脚本存在安全风险：eval会执行变量中的命令，若变量值包含特殊字符或恶意内容，可能导致意外执行。不推荐这种实现方式，以下是更优替代方案：

• 用envsubst（轻量首选）
  envsubst是GNU gettext工具包的组件，多数基础镜像（如debian、alpine）预装或可快速安装，直接替换环境变量占位符：

  deploy_app:
    stage: deploy_app
    image: debian
    before_script:
      - apt-get update && apt-get install -y gettext-base
      - envsubst < $CONFIG_FILE > deployment.yaml
    script:
      - kubectl apply -f deployment.yaml
  

  注意：K8s清单中的占位符要写成${DEPLOYMENT_NAMESPACE}格式，与CI中定义的环境变量名完全一致。
• 用Helm模板（复杂场景首选）
  若你的部署涉及多环境、多配置项，可将K8s清单做成Helm模板，通过Helm命令渲染并部署：

  deploy_app:
    stage: deploy_app
    image: alpine/helm
    script:
      - helm upgrade --install react-app ./helm-chart --namespace ${DEPLOYMENT_NAMESPACE} --set image.tag=${IMAGE_TAG} --set environment=${CI_ENVIRONMENT_NAME}
  

  Helm支持变量传递、条件判断、依赖管理等高级功能，适合复杂应用的配置管理。
• 用Kustomize（K8s原生方案）
  K8s官方提供的配置管理工具，无需模板语法，通过kustomization.yaml覆盖基础配置：
  将基础deployment.yaml放在base目录，每个环境（dev/staging/prod）创建独立的overlay目录，在对应kustomization.yaml中定义namespace、镜像标签等覆盖项，CI中执行：

  kubectl apply -k overlays/${CI_ENVIRONMENT_NAME}
  

  这种方式完全基于K8s原生生态，无需额外工具链。

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