Создавать рабочий элемент TFS только в новой неудачной сборке - PullRequest
Новая
       13

Создавать рабочий элемент TFS только в новой неудачной сборке

3 голосов
/ 16 января 2009

Я видел пост об отключении создания рабочего элемента во всех неудачных сборках, но я бы хотел, чтобы TFS создавал рабочий элемент только при первом сбое. У нас очень сложная унаследованная система, которая включает COM-компоненты VB6 и часто имеет сбои сборки на сервере сборки, которые отслеживают некоторую функциональность, которую VB6 делает с двоичными файлами (frx, ctl и т. Д.), Если вам не приходилось иметь дело с что через некоторое время ты не хочешь). Единственный способ решить эти проблемы - попытаться сделать обновления на компьютере разработчика, затем проверить файлы и снова запустить сборку (так как сборка не завершается с ошибкой на компьютере разработчика). Таким образом, у нас может быть три или четыре (или более) неудачных сборки, прежде чем мы добьемся успеха, что означает, что у нас будет три или четыре рабочих элемента для закрытия.

В идеале я хотел бы иметь следующее:

  1. Джо регистрирует изменение, которое приводит к сбою сборки
  2. Рабочий элемент создается и назначается Джо
  3. Джо проверяет другое изменение, и сборка все еще не удается
  4. Нет создания дополнительного рабочего элемента
  5. Джо проверяет изменения, сборка завершается
  6. Рабочий элемент, назначенный Джо на шаге 2 выше, помечается как Закрытый

Но я был бы счастлив только с шагами с 1 по 4.

1 Ответ

1 голос
/ 19 января 2009

Как бы вы определили, что вторая неудачная сборка была связана с первой, так как здесь требуется дополнительная регистрация? Что произойдет, если следующая регистрация на самом деле представляет собой дополнительный код, совершенный другим разработчиком - вы хотите, чтобы они знали, что их код нарушил сборку, или что он все еще не работает, даже если в соответствии с вашими действиями ничего не сработает.

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

Это двигает вас в правильном направлении?

...