您告诉您不能有计划的触发器和 CI 触发器，但事实并非如此。请查看文档here。
如果您只想使用计划的触发器来运行您的管道，您可以
必须通过指定 pr 来禁用 PR 和持续集成触发器：
none 和 trigger: none 在您的 YAML 文件中。如果你使用的是 Azure Repos
Git、PR 构建是使用分支策略配置的，必须禁用
在那里。
所以你有两个选择：
- 将所有内容保存在一个 YAML 文件中，并检查哪个分支或构建是如何触发条件以将部署到适当的服务器
- 您可以有两个构建，但为了避免重复，您可以将常用内容提取到模板并在构建定义中重复使用（因此实际上在这种情况下，您将拥有 3 个 yaml 文件）。
几个例子：
jobs:
- job: A
steps:
- script: echo hello
- job: B
dependsOn: A
condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/master'))
steps:
- script: echo this only runs for master
常用步骤：
# File: simple-param.yml
parameters:
- name: yesNo # name of the parameter; required
type: boolean # data type of the parameter; required
default: false
steps:
- script: echo ${{ parameters.yesNo }}
构建定义：
# File: azure-pipelines.yml
trigger:
- master
extends:
template: simple-param.yml
parameters:
yesNo: false # set to a non-boolean value to have the build fail
您可以阅读the documentation 中的模板或查看我的blog post 中的示例。
如果您想拥有经典的发布管道，您需要定义两个发布管道并触发特定分支。
总而言之：您可以做自己想做的事，而且实现这一目标的方法不止一种。我个人的建议是使用带有模板的单独管道，因为它使构建定义比条件更清晰，以检查哪个分支或如何触发构建。
在这个变量Build.Reason 中，你可以检查你的分支是如何被触发的：
- 手动：用户手动将构建排队。
- IndividualCI：由 Git 推送或 TFVC 签入触发的持续集成 (CI)。
- BatchedCI：由 Git 推送或 TFVC 签入触发的持续集成 (CI)，并且选择了批量更改。
- 计划：计划的触发器。 ValidateShelveset：用户手动将
构建特定的 TFVC 搁置集。
- CheckInShelveset：门控签入触发器。
- PullRequest：构建是由需要构建的 Git 分支策略触发的。
- BuildCompletion：构建由另一个构建触发。
- ResourceTrigger：构建是由资源触发器触发的。
然后您可以在条件中使用此变量。欲了解更多信息，请转至here。
关闭这个，请注意有一种特殊的job 称为deployment 用于部署。如果您打算使用 yaml 管道部署应用程序，请考虑使用它。
对于您的额外问题：您可以覆盖您构建的设置。我的意思是你可以有 master 和只有 master 分支的触发器。但是您仍然可以为其他分支（例如开发分支）运行构建（例如通过手动运行）。那会发生什么？构建将为新定义的分支运行。最后，这是构建定义，触发器只是控制自动构建执行。