В TeamCity вы можете создавать зависимости построения, когда одна сборка не запускается до тех пор, пока другая не завершится успешно. Возможно ли это с TFS 2012? Где я могу найти дополнительную информацию о том, как настроить это?TFS Build Dependencies
Короткий ответ заключается в том, что TFS не имеет эквивалентной функциональности, но вы можете достичь тех же целей с небольшой работой.
Обычный сценарий, с которым я сталкиваюсь, - это команда, которая хочет сделать сборку, когда они регистрируются, что делает некоторые быстрые вещи (компиляция, быстрые модульные тесты), а затем сразу же после этого хочет сделать еще одну сборку, которая запускает некоторые более медленные вещи (интеграция тесты, тестирование и т. д.). Я часто это делаю с моими командами, и я настрою Gated Build, которая работает в 5 минут, а затем создайте CI-сборку, которая будет запущена, как только будет запущена проверка Gated Build, которая может занять час. Мне нравится этот подход, поскольку он быстро дает разработчикам некоторую обратную связь, а затем более подробную обратную связь вскоре после этого.
В другом поддерживаемом сценарии имеется явная сборка заготовок, зависящая от его зависимостей. Если вы посмотрите шаблон Lab Build Template, он сделает именно это, сначала он запустит приложение TFS Build, и Lab Build будет сидеть и ждать, пока он закончится, тогда Lab Build продолжит работу. В теории вы могли бы построить Build B kickoff build B, который запускает C & D и т. Д.
Если ваши потребности сложнее, чем это (например, у вас есть несколько приложений, для которых у вас есть сборка для каждого, то Продукт, который включает некоторые приложения, которые необходимо создать после каждого приложения, а затем, возможно, сборку Product Suite, которая должна запускаться при каждом изменении продукта - это сценарий, который я имел в виду). Я в основном реализовал собственную систему зависимостей сборки, чтобы справиться с этим. Мы создали XML-файл, который описывал зависимости сборки, а затем написал простой подключаемый модуль ISubscriber, который мы будем разворачивать в TFS, и он будет прослушивать события Build Completed, затем консультироваться с конфигурацией зависимостей и запускать соответствующие сборки.