Azure DevOps Git粒度触发器构建，用于持续集成和交付

Question

我继承了一个有点奇怪的git repo，其结构如下：

Some Client - Programme/
├── ClientName.Thing1/
│   ├── ClientName.Thing1.sln
│   └── ClientName.Thing1.ProjectX/
│       ├── ClientName.Thing1.ProjectX.csproj
│       ├── file1.cs
│       └── file2.cs
└── ClientName.Thing2/
    ├── ClientName.Thing2.sln
    ├── ClientName.Thing2.ProjectY/
    │   ├── ClientName.Thing2.ProjectY.csproj
    │   ├── file3.cs
    │   └── file4.cs
    └── ClientName.Thing2.ProjectZ/
        ├── ClientName.Thing2.ProjectZ.csproj
        ├── file5.cs
        └── file6.cs

基本上，我有一个单独的回购，包含一堆文件夹; ClientName.Thing1, ClientName.Thing2, etc..所有代码都存在于这些顶级文件夹下面。

工作流似乎是Person-A适用于ClientName.Thing2和Person-B一次在ClientName.Thing1上工作，独立...两者都可以在Visual Studio中使用* .sln文件打开。

但这意味着，尽管它们都在不同的领域工作......但是它们可以“交叉授粉”，因为它们都来自同一个master分支，技术上是Person-A，即使它们并不意味着，可以编辑Person-B正在查看的工作“区域”中的某些内容。

这不是最大的问题，最大的问题是实际发布内容，特别是要获得要发布的方面的构建。 没有真正编译的代码（python，sql等），因此只需连接到CICD管道中的repo并部署这些东西就可以“逃脱”......没有构建，我觉得有点烦人..这意味着你无法保证你总是在每个环境中部署相同的东西。

那么，对于这个问题！

有没有办法，如果Person-A对ClientName.Thing2文件夹下的任何内容进行一些更改，它是否只为特定的构建定义触发构建？

现在......我只能看到一种触发提交回购整体的方法，这将是超级超级嘈杂！

Answer 1

将路径过滤器添加到构建定义的CI触发器中。