Ранее XAML Gated Build использовался для проверки файлов, принадлежащих нескольким рабочим областям в TFS другого решения, только с одним определением gated build.
То, что я имею в виду, похоже на то, что разработчики использовали для проверки нескольких файлов в TFS только одно определение gated build, даже если рабочие области этих файлов не были отображены в этом старом определении XAML Gated Build.
Но после перехода на TFS 2017, обновление 3, это не тот случай, мы должны создать отдельное определение сборочной системы для каждого решения, имеющего разные пути в TFS.(Хотя я бы сказал, что это хорошая практика, она запрещает проверку любого поврежденного кода в TFS, но его недостатки подобны множеству наборов изменений, создаваемых для каждого решения, и изменений файлов, которые мы проверяем)
Чтобы избежать несколькихпроблема с наборами изменений. Один из вариантов - создать одно определение gated build, которое будет отображать рабочую область для всех 8 решений, которые у нас есть, и получит сборку, которая позволит разработчикам проверять несколько файлов с одним определением gated, но также имеет свои недостатки относительно времени сборки.увеличится безо всяких причин, и даже если вы проверяете один файл, он будет создавать и другие решения.
Так есть ли другой вариант, с помощью которого я могу решить эту проблему, позволяя разработчикам проверять несколько файлов однимсам gated build, а также одновременно поддерживать проверки целостности кода?