为什么Azure Pipelines的deployment job需要指定pool代理池配置？

核心逻辑说明 #

你观察到的运行表现完全符合Azure Pipelines的设计规则，pool和environment关联资源属于两套调度逻辑，environment关联的可运行计算资源优先级高于job配置的pool：

• 当指定的environment绑定了可直接执行作业步骤的计算类资源（如虚拟机、Kubernetes集群）时，deployment job的所有步骤会优先调度到环境关联的资源上运行，你配置的pool字段会被直接忽略。
• 当environment没有绑定任何可直接运行步骤的计算资源时，系统才会使用你配置的pool来分配作业运行的代理。

pool字段存在的必要性 #

之所以要保留pool配置，是为了覆盖更多部署场景的需求：

• 很多场景下environment仅用来做部署生命周期管理：比如仅用它做部署审批门禁、部署记录追溯、环境安全策略校验，不会绑定具体计算资源，部署动作是在代理池的机器上通过远程调用完成（比如调用云服务的部署接口、远程推送更新到服务器），这时候deployment job的步骤就需要跑在pool指定的代理上。
• 兼容通用作业的配置逻辑：deployment job本身是普通job的扩展类型，天然继承了普通job的pool配置能力，方便用户在不需要绑定环境资源时，无需修改作业类型就能直接复用原有配置。
• 适配复杂部署策略：部分多阶段部署策略需要先在公共代理上完成代码拉取、打包、配置生成等前置工作，再将产物下发到环境资源上执行部署，pool可以满足这类前置步骤的运行需求。

对应你的示例解释 #

你在示例中明确指定了resourceType: VirtualMachine，系统检测到Stage环境下绑定了对应的虚拟机资源，就直接将所有步骤调度到这台虚拟机上运行，你配置的Ubuntu-16.04代理池自然不会被调用。如果你删除Stage环境下的虚拟机资源，或者去掉resourceType配置，作业就会按照你指定的pool配置分配Azure提供的Ubuntu虚拟机运行。

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