如何使用Google Deployment Manager和Cloud Build实现多项目多环境部署

核心思路是复用现有dev项目的Cloud Build流水线，通过跨项目IAM授权+触发规则区分环境变量的方式，实现一处配置、多环境自动部署，不需要为test环境单独搭建独立构建流程。

1. 配置跨项目访问权限 #

首先给dev项目的Cloud Build服务账号开通test项目的操作权限：

• 复制dev项目的Cloud Build默认服务账号，格式为[dev项目编号]@cloudbuild.gserviceaccount.com，可以在dev项目Cloud Build的设置页面查到
• 进入test项目的IAM管理页面，添加上述服务账号为成员，按需授予对应权限：如果只用到GDM部署，授予Cloud Deployment Manager Editor即可；如果涉及其他GCP资源（如云存储、云函数、GKE等），对应补充最小必要权限，避免权限过度开放。

2. 改造Cloud Build配置文件 #

把你现有固定写死dev环境参数的cloudbuild.yaml（或其他构建配置文件）改成支持变量注入的形式：

• 所有环境相关参数（目标项目ID、GDM部署名、环境标识等）全部替换为自定义变量，比如用$_TARGET_PROJECT_ID代替硬编码的dev项目ID，用$_DEPLOYMENT_NAME代替固定的dev环境部署名
• 配置默认变量值为dev环境参数，保证原有dev环境的触发逻辑不受影响
• 参考配置示例：

steps:
  - name: 'gcr.io/cloud-builders/gcloud'
    id: 'deploy-gdm-template'
    args:
      - deployment-manager
      - deployments
      - update
      - ${_DEPLOYMENT_NAME}
      - --config=gdm/your-config.yaml
      - --project=${_TARGET_PROJECT_ID}
substitutions:
  _TARGET_PROJECT_ID: 'your-default-dev-project-id' # 未指定变量时默认走dev环境
  _DEPLOYMENT_NAME: 'dev-env-deployment'

3. 新增test环境触发规则 #

不需要修改Bitbucket和dev项目Cloud Build的现有对接配置，只需要在dev项目的Cloud Build控制台新增一条test环境的触发规则即可：

• 触发源选择已经绑定的Bitbucket仓库
• 自定义触发条件：可以选择推送至指定分支（比如test分支）、推送带指定前缀的标签（比如test-release-*），或者手动触发
• 在触发规则的变量替换配置中，填入test环境的对应参数，比如_TARGET_PROJECT_ID填test项目ID，_DEPLOYMENT_NAME填test环境的GDM部署名
• 如果需要控制部署顺序，比如dev环境部署验证通过后再自动触发test环境部署，可以在dev环境的构建步骤最后加一步调用Cloud Build API触发test环境构建的逻辑。

4. 验证流程 #

推送测试变更到对应触发test部署的分支/打对应标签，查看dev项目的Cloud Build是否正常触发test环境部署，部署完成后到test项目核对GDM资源状态是否符合预期即可。后续如果要新增其他环境（如prod），只需要重复第一步的授权操作、新增对应触发规则即可，所有构建配置都在dev项目统一管理，不需要做大幅调整。

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