Azure Data Factory多环境部署：版本回溯与热修复方案咨询

一、同时部署已验证的Release1到Prod、Release2到QA的解决方案 #

核心思路是为每个已验证的版本保留独立的快照引用，避免adf_publish分支被后续发布覆盖导致旧版本丢失：

1. 为Release1创建版本快照
   • 当Release1部署到QA并验证通过后，立即对当时adf_publish分支的提交打Git标签，比如release/v1.0.0；或者将该版本的ARM模板（包含ARMTemplateForFactory.json、ARMTemplateParametersForFactory.json及相关依赖文件）打包上传到制品库（如Azure DevOps Artifacts、GitHub Packages）。
2. 分别引用不同版本部署
   • 部署Prod时：在CI/CD流水线中指定拉取release/v1.0.0标签对应的代码，或者从制品库下载Release1的ARM模板包进行部署，完全不依赖最新的adf_publish分支。
   • 部署QA时：直接使用最新的adf_publish分支代码（对应Release2）进行部署。

获取Release1引用的具体操作 #

• Git标签方式：
  • Azure DevOps流水线中，在checkout步骤执行：git checkout release/v1.0.0
  • GitHub Actions中，使用actions/checkout@v4并指定参数：ref: release/v1.0.0
• 制品库方式：
  • 发布Release1时，添加流水线步骤将adf_publish下的ARM模板文件夹打包为zip，上传到制品库并标记版本v1.0.0；部署Prod时，从制品库拉取该版本的zip包解压后执行部署。

二、不引入QA环境Release2变更的前提下，对Prod的Release1进行热修复 #

除功能开关外，还有以下可行方案：

方案1：基于Release1标签创建独立热修复分支 #

1. 从release/v1.0.0标签创建热修复分支，比如hotfix/v1.0.1
2. 在该分支中仅修改需要热修复的内容（禁止合并Dev环境Release2的代码），可通过本地ADF工具验证修改后的ARM模板，或用脚本从分支生成模板
3. 将热修复分支的ARM模板部署到Prod环境，验证修复效果
4. 若需要将修复同步到Release2，将hotfix/v1.0.1合并到Dev的协作分支（如main），再发布到adf_publish，确保后续Release2版本包含该修复

方案2：反向同步Prod临时修复到Dev（应急场景） #

• 紧急情况下，可直接在Prod环境的ADF中修改需要修复的资源，完成后将修改的资源导出为ARM模板片段，反向合并到Dev的协作分支，避免后续发布丢失该修复。但此方式会打破GitOps流程，仅适合极端应急场景。

方案3：参数化模板隔离修复逻辑 #

• 提前将易出问题的逻辑（如管道活动、数据集配置）设计为可参数化的内容，热修复时仅修改Prod环境的部署参数值，无需修改ARM模板本身。例如：将某个管道活动的SQL语句、开关状态做成参数，Prod环境使用修复后的参数值，QA环境保持Release2的原有参数。

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