TFS 2010 Несколько решений и сборка с закрытой регистрацией

Question

У меня есть два решения в соответствующей папке, например

1. SolutionA\SolutionsA.sln
2. SolutionB\SolutionB.sln

Для каждого решения настроена сборка Gated Check-in; то есть два определения сборки GatedSolutionA и GatedSolutionB.

Теперь ситуация такова, что, если я проверяю изменения в обеих папках вместе, TFS показывает диалоговое окно для выбора сборки (раскрывающейся с GatedSolutionA, GatedSolutionB) для запуска с набором изменений. В моем наборе изменений есть критические изменения в решении B и нерушимые изменения в решении A. То есть, сборка GatedSolutionB не будет выполнена, но GatedSolutionA пройдет.

Когда я выбираю GatedSolutionA для сборки на основе моей ревизии, TFS регистрирует ее, что, в свою очередь, оставляет решение B в нерабочем состоянии, и цель проверки Gated отменяется для решения B.

Если я изменю триггер на CI для определений сборки, TFS ставит в очередь обе сборки.

То, что я ищу, - это одно и то же поведение, т. Е. Все сборки Gated ставятся в очередь, и в случае сбоя одной из них набор изменений должен быть отклонен.

Примечание : я не хочу создавать одно определение сборки для обоих решений. Кроме того, я знаю, что мы можем избежать этой проблемы, создав два отдельных набора изменений, но обычно это происходит, когда разработчики не знают, что у них есть какие-то файлы, проверенные для решения, отличного от того, над которым они работают.

Answer 1

@ Gchaves нашел решение этой проблемы, вы можете перейти к «Редактировать определения сборки» и на вкладке «Рабочая область», если вы настраиваете «Папка управления исходным кодом» во внутренней папке, где у вас есть SolutionA.

Например, если у вас есть эта файловая система:

1. Проекты \ SolutionA \ SolutionA.sln
2. Проекты \ SolutionB \ SolutionB.sln

Теперь, если вы сконфигурируете «Папка управления исходным кодом» и «Папка агента построения» для Projects \ SolutionA, проверка Gated будет запущена только при попытке проверить в SolutionA, и скомпилирует только SolutionA.sln (длячтобы это было правдой, вы должны просто указать SolutionA.sln на вкладке Process -> 1.Required-> ProjectsToBuild)

И тогда вы можете иметь несколько решений в одной рабочей области, независимо друг от друга создавая, регистрируя и маркируя:)

Answer 2

В определении сборки на вкладке Process вы можете выбрать более одной sln для сборки.

Answer 3

Я знаю, что вы сказали, что "вы не хотите создавать одно определение сборки для обоих решений", но на самом деле это единственно возможный вариант. Я бы предложил две ветви: одну для разработки функций и одну для интеграции. Пусть ваши разработчики будут работать в ветке (-ях) функций и использовать для этих решений компоновки закрытого входа (или CI). Периодически объединяйте изменения в ветви (ях) компонентов в ветвь интеграции, в которой есть единственное определение сборки регистрации, в котором собраны все ваши решения. Это сохранит сборки из вашей ветки интеграции в чистоте.

Answer 4

Одним из решений этой проблемы является то, что разработчики имеют отдельные рабочие пространства, сопоставленные для отдельных решений. Если между решениями нет перекрывающегося кода, и вы пытаетесь помешать разработчику проверить одно решение, когда они строят другое решение, тогда они должны использовать разные рабочие пространства.

Если у вас есть WorkspaceA для SolutionA и WorkspaceB для SolutionB, в диалоговом окне ожидающих изменений будут отображаться только изменения, внесенные в соответствующее рабочее пространство.

Как вы говорите, вы знаете, что можете избежать этого, используя отдельные наборы изменений. Вот как вы можете «заставить» разработчика использовать два отдельных набора изменений и избежать ситуации «разработчики не знают ...».

Создайте для них рабочие пространства и отзовите их разрешение «Создать рабочее пространство», чтобы они не могли создать одно, включающее обе области.