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