例如，我有一个解决方案和多个项目。基本上，多个项目是：
如果我想为 REST API 和管理 UI 建立 Azure DevOps 管道，最好的方法是什么？
我喜欢#2。我在想，如果只有 REST API 发生变化，那么只有 REST API 会为自己触发 CI/CD。如果 Admin UI 发生变化，只会触发它的 CI / CD。如果共享库发生更改，则 CI/CD 都会触发。
我相信这可以使用路径过滤器作为触发器来完成。但是，如果将来我有一个新的共享库2 怎么办？我需要为该新项目编辑管道触发器。所以我不确定这是否是一种好习惯（可能忘记添加触发器？）
【问题讨论】：
标签： azure-devops azure-pipelines
要回答您关于最佳实践的问题，它会以这样一种方式打破部署，以最大限度地减少潜在影响，同时确保合理的功能，同时确保一致的集成和高质量的代码流。
如果您想保持对这两种情况的控制，我建议您结合使用这些方法。这可以通过将每个部署分解成它自己的阶段，然后将该阶段与需要批准的环境联系起来来实现。对于 Dev 建议做一个完整的 CD 来捕捉任何可能失败的东西，然后批准你的其他环境。您的管道可能如下所示：
构建阶段：
部署 Rest API 阶段 [Dev]
部署 Admin UI Web Stage [Dev]
部署共享库阶段 [Dev]
部署 Rest API 阶段 [UAT]...
部署 Admin UI Web Stage [UAT]...
部署共享库阶段 [UAT]..
为每个环境执行此模式并配置环境批准。这将允许每次在没有批准的情况下在 Dev 中进行完整的部署，并且在其他环境中能够批准需要哪些部署。另外，如果执行多个地理/实例可以在该阶段的作业中调用它，以允许不同组件的可扩展性。此外，作业和任务可以模板化以优化可重用性并减少复制和粘贴。
此外，如果这样做会强烈推荐使用 YAML 模板，因为这将允许您一次性定义阶段所需的作业/步骤并重复使用。
【讨论】：
没有一种方法可以解决它。您实际上可以考虑的是 - 我是否要始终一起部署所有应用程序？如果是，那么您可以使用一条管道。如果不是，您应该使用单独的管道。
第二种解决方案有点复杂，但是您可以使用以下功能使这项工作更容易：
trigger:
branches:
include:
- master
- releases/*
paths:
include:
- sharedA
exclude:
- '*'
但是如果您的项目很小，请考虑第一种方法，因为它可能运行得足够快，并且可以节省您在复杂管道结构上的时间。
【讨论】：