GitLab CI/CD中管理多客户软件版本的最优方案咨询

分支结构设计 #

先明确分支规则，避免混乱：

• main分支：存放所有客户通用的PHP/CSS/JS代码，不包含任何客户专属文件
• 每个客户对应一个专属分支，命名格式如client-[协会名称]（比如client-greenpeace、client-redcross）：这些分支基于main，仅包含该客户的3个专属差异文件

实现步骤 #

1. 配置main分支自动合并到所有客户分支

在项目根目录创建.gitlab-ci.yml，添加自动合并的Job，仅在main分支有提交时触发：

stages:
  - merge-to-clients
  - deploy-staging
  - deploy-prod

# 自动将main分支代码合并到所有客户分支
merge-to-clients:
  stage: merge-to-clients
  only:
    - main
  script:
    - |
      # 配置CI的Git身份
      git config --global user.name "GitLab CI Bot"
      git config --global user.email "ci-bot@your-org.com"
      # 拉取所有远程分支
      git fetch origin
      # 定义客户分支列表（根据实际情况修改）
      CLIENT_BRANCHES=("client-greenpeace" "client-redcross" "client-oxfam")
      for BRANCH in "${CLIENT_BRANCHES[@]}"; do
        echo "=== Merging main into $BRANCH ==="
        git checkout $BRANCH
        # 仅执行快进合并，避免自动解决冲突（冲突需手动处理）
        git merge main --ff-only
        # 推送到远程仓库
        git push origin $BRANCH
      done
  tags:
    - your-runner-tag # 指定有权限推送代码的GitLab Runner
  variables:
    GIT_STRATEGY: clone # 确保完整克隆仓库

2. 客户分支自动部署到Staging，手动部署到Production

在同一个.gitlab-ci.yml中添加部署Job：

# 自动部署到对应客户的Staging环境
deploy-staging:
  stage: deploy-staging
  only:
    - /^client-.+/ # 匹配所有以client-开头的客户分支
  script:
    # 替换为你的实际部署命令，比如SSH拉取代码、重启服务等
    - ssh staging@$CLIENT_STAGING_SERVER "cd /var/www/$CI_COMMIT_BRANCH && git pull origin $CI_COMMIT_BRANCH && chown -R www-data:www-data ."
    # 如果有依赖安装或编译步骤，可在此添加（比如npm install、composer install）
  environment:
    name: staging/$CI_COMMIT_BRANCH
    url: https://staging-$CI_COMMIT_BRANCH.your-org.com
  tags:
    - deploy-runner # 指定有权限访问Staging服务器的Runner

# 手动触发部署到Production环境
deploy-prod:
  stage: deploy-prod
  only:
    - /^client-.+/
  when: manual # 必须手动点击触发
  script:
    # 替换为你的Production部署命令
    - ssh prod@$CLIENT_PROD_SERVER "cd /var/www/$CI_COMMIT_BRANCH && git pull origin $CI_COMMIT_BRANCH && chown -R www-data:www-data ."
  environment:
    name: production/$CI_COMMIT_BRANCH
    url: https://$CI_COMMIT_BRANCH.your-org.com
  tags:
    - deploy-runner
  allow_failure: false # 部署失败时标记流水线失败

关键注意事项 #

• 权限配置：确保GitLab Runner使用的账号（或CI/CD变量中的GITLAB_TOKEN）拥有项目的Developer权限，能推送代码到客户分支；同时Runner需要能SSH访问客户的Staging/Production服务器。
• 冲突处理：如果客户分支的专属文件与main分支出现冲突（比如误在main中添加了同名文件），merge-to-clients Job会失败，此时需要手动拉取对应客户分支，解决冲突后重新运行Job。
• 动态分支列表：如果客户数量较多，手动维护CLIENT_BRANCHES列表麻烦，可以用GitLab API动态获取所有客户分支：

  # 替换$GITLAB_TOKEN和$CI_PROJECT_ID为实际值
  CLIENT_BRANCHES=$(curl -s --header "PRIVATE-TOKEN: $GITLAB_TOKEN" "https://gitlab.your-org.com/api/v4/projects/$CI_PROJECT_ID/repository/branches?search=client-" | jq -r '.[].name')
  

• 专属文件管理：建议将所有客户专属文件放在统一子目录（比如clients/[client-name]/），便于区分和维护，避免与通用代码混淆。

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