Самый простой способ проверить шаблон сборки TFS2010

Question

В настоящее время я работаю над созданием шаблона сборки для сборок TFS2010. Тем не менее, я заметил, что в настоящее время я «спамую» исходный элемент управления при каждом внесении изменений в шаблон (и многое другое для всех исправлений этих изменений).

Интересно, как проще всего проверить шаблоны сборки, которые я создаю? Есть ли способ изменить файл шаблона и пользовательские библиотеки активности, которые не требуют их регистрации?

В настоящее время на моей машине разработчика работают контроллер сборки и агент, который я использую для тестирования шаблона (test = начать сборку и надеюсь на меньшее количество ошибок, чем в прошлый раз).

Answer 1

Почему проблема спама?Во всяком случае, у меня есть отдельный командный проект для выполнения такой работы, и я могу получить доступ к своему сердцу, не затрагивая разработчиков, которым нужна стабильная сборка.как только я закончу тестирование, я проверяю шаблон в командном проекте (ах), используемом разработчиками.

Answer 2

@ d3r3kk: Почему бы просто не разветвлять шаблон и объединять изменения, когда они будут готовы, вместо создания копий? Таким образом, вы также можете сохранить историю источников более чистым способом.

В идеале, должен быть способ создать шаблон процесса сборки, который выполняется в локальной файловой системе, и временно указать ему определение сборки. Не уверен, что что-то подобное существует в более поздних версиях VS / TFS. В любом случае я не видел его доступным через пользовательский интерфейс.

Answer 3

Я хочу протестировать свои сборки на основе последней кодовой базы команд без необходимости переходить на пробный проект.

Вместо этого я делаю следующее:

1. Создайте отдельное определение сборки под названием «Инфраструктура».
   • клонировать определение производства
2. Установите триггер в определении сборки инфраструктуры на ручной.
3. Установите разрешения для определений инфраструктуры, чтобы позволить только [Project] \ Build членам группы иметь полный контроль над ней.
   • хранит уведомление о нарушенных сборках вдали от основной массы команды.
4. Создайте отдельный шаблон процесса сборки, который называется «Infrastructure.xaml».
5. Укажите определение сборки инфраструктуры на шаблон процесса инфраструктуры.

Теперь, когда я хочу перейти к новой функции сборки для команды:

1. Проверьте шаблон процесса сборки, который я хочу обновить, и заблокируйте его.
2. Скопируйте шаблон процесса сборки, который я хочу обновить поверх файла Infrastructure.xaml.
3. Добавьте функцию сборки в файл Infrastructure.xaml и отметьте это.
4. Используйте определение сборки инфраструктуры для проверки моих изменений.
5. Итерируйте по 3-4, пока я не пойму правильно.
6. Завершите эту функцию, и мои изменения будут проверены другим членом команды по инфраструктуре.
7. Скопируйте Infrastructure.xaml поверх шаблона процесса сборки, который я заблокировал (1), и установите его.

Это все еще приводит к «спаму» в элементе управления исходным кодом TFS, но не дает итерации определения сборки быть в поле зрения команды. Мои шаблоны процессов сборки расположены вне основного дерева исходных файлов (в папке «Шаблоны процессов сборки» или в самих ветвях в папке «Core / Build», где никто в команде обычно не обращает внимания), так что команда в значительной степени не затронута этим.