Для меня PowerShell - это путь. Вот мои причины, почему:
- Независимость скрипта:
Используя этот подход, вы получаете независимость от сценария. Пример: у меня есть несколько сценариев, которые запускаются после завершения процесса сборки (т.е. компиляции):
- База данных экземпляров
- Развертывание кода базы данных
- Развертывание веб-приложений
- Проверка развертывания
- Выполнить приемочные испытания
Все вышеперечисленное можно запускать, отлаживать и тестировать независимо, без необходимости ставить новую сборку в очередь.
- С Powershell легко работать:
Пользовательские сборки, как правило, добавляют сложности и изящества к решению. Пример: обновление с TFS 2010 до TFS 2012 было очень болезненным, потому что все шаблоны сборки сломались. Нам пришлось перекомпилировать все наши пользовательские сборки, и только один разработчик в команде знал, как TFS Build был настроен для выполнения наших пользовательских действий. Недавно я удалил все пользовательские сборки из наших шаблонов сборки и использую исключительно Powershell.
Я настроил свои шаблоны процессов для вызова пользовательского скрипта powershell после завершения сборки TFS. Я делаю это с помощью аргумента пути в определении сборки. Этот аргумент является просто массивом строк, указывающих на сценарии. Выше я согласен с Ewald, что TFS не передает аргументы сборки в сценарии. Чтобы решить эту проблему, в моем шаблоне рабочего процесса я анализирую каждый сценарий в массиве строк и заменяю известные токены аргументами сборки - например, @ (BuildNumber), @ (SourcesDirectory) и т. Д. Я считаю, что это очень простое и надежное решение.