Azure ML工作区CI/CD流程与代码仓库集成方法咨询

你现有ADF的Git联动逻辑可以直接映射到Azure Machine Learning（AML）Workspace，对应流程如下：

• 对应「dev环境ADF实例关联Azure代码仓库」：直接在dev环境AML工作室的管理面板找到Git集成配置项，绑定Azure Repos或GitHub仓库，指定日常开发用的主干分支即可。绑定完成后，工作区内的Notebook、自定义组件、流水线定义、运行环境配置等所有研发资产都会和仓库自动同步，和ADF绑定Git的操作逻辑完全一致。
• 对应「开发者通过编辑器提交代码变更」：你既可以在AML绑定的计算实例上直接拉取仓库代码做调试、跑训练实验，也可以用本地VS Code等工具连接仓库提交变更，所有脚本修改、组件参数调整、流水线逻辑更新都会被Git完整记录，和你之前的ADF开发提交流程没有本质差异。
• 对应「变更通过adf_publish分支发布到dev运行实例」：AML不会像ADF那样自动生成adf_publish发布分支，你只需要把开发分支上经过本地调试、实验验证的资产yaml定义（组件、流水线、环境配置等），通过PR合并到专门的发布分支（比如命名为aml-publish），这个合并动作就等同于ADF里点击“发布”生成发布分支的操作。合并完成后dev环境的AML工作区可以直接拉取发布分支的定义，在dev环境运行对应训练、推理任务。
• 对应「通过CI/CD和ARM模板部署到production环境」：和你用ARM模板部署ADF资产的逻辑类似，你不需要额外导出模板，直接用发布分支里存储的AML原生yaml定义，在CI/CD流水线里调用AML CLI任务，就能把对应版本的资产部署到生产环境AML工作区。

AML的CI/CD流程围绕「资产即代码」的逻辑设计，标准步骤如下：

• 多环境资源前置准备：至少部署两套权限、网络、计算资源完全隔离的AML Workspace，分别作为dev开发测试环境、prod生产环境，和你ADF多环境部署的资源规划逻辑一致。
• 仓库与分支策略配置：将所有AML相关资产全部纳入Git版本管理，包括训练/推理脚本、组件定义文件component.yaml、流水线定义文件pipeline.yaml、运行环境配置environment.yaml、模型注册规则、在线/批量端点部署配置。配置分支保护规则：开发分支接收日常开发提交，发布分支仅存放经过完整验证的可上线版本，所有合并到发布分支的PR必须经过代码评审、单元测试校验、dev环境实验运行验证。
• CI阶段触发与校验：当PR合并到发布分支时自动触发CI流水线，完成固定校验动作：执行代码静态扫描、单元测试；通过az ml CLI校验所有AML资产yaml的格式合法性；在dev环境触发一次端到端的训练流水线运行，验证训练逻辑可跑通、模型输出指标符合预期；校验通过后，将产出的模型版本、组件版本、环境版本打唯一标签，作为待发布制品留存。
• CD阶段分环境部署：CI校验通过后，按照发布审批规则触发CD流水线，按环境梯度部署：可先部署到预发环境做冒烟测试，验证推理接口响应、流水线调度正常后，经人工审批再部署到prod环境。部署动作包括：在目标工作区创建/更新对应版本的运行环境、自定义组件；注册对应版本的模型；更新批量推理流水线或实时在线端点的配置，按规则切流到新版本模型；部署完成后自动运行冒烟用例，验证线上服务可用性。

注意：和ADF依赖自动生成ARM模板做部署的机制不同，AML所有资产都以明文yaml格式存储在Git仓库中，你可以直接对这些文件做版本对比、变更回滚，灵活度更高，不需要依赖平台自动生成的发布产物。

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