TFS Build - Powershell или пользовательская активность? - PullRequest
2 голосов
/ 08 ноября 2010

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

Спасибо

Ответы [ 2 ]

4 голосов
/ 08 ноября 2010

Решение о том, использовать ли Powershell или пользовательский вид деятельности, зависит от того, кто несет ответственность. Если у вас есть действие, созданное мастером сборки (для TFS) и поэтому повторно используемое для всех команд в организации, я создаю настраиваемое действие.

Если за проект отвечает команда (например, сценарий развертывания), я использую PowerShell. Я создаю аргумент, в котором команда может указать путь к сценарию powershell, который необходимо выполнить для развертывания. Команда проекта может по выбору ввести значение в этот аргумент. Команда проекта также может самостоятельно поддерживать свой сценарий развертывания PowerShell без помощи мастера сборки.

Итак, вкратце:

  • Повторно используемое действие: Пользовательское действие
  • Активность только для команды: Powershell
1 голос
/ 19 марта 2014

Для меня PowerShell - это путь. Вот мои причины, почему:

  1. Независимость скрипта:

Используя этот подход, вы получаете независимость от сценария. Пример: у меня есть несколько сценариев, которые запускаются после завершения процесса сборки (т.е. компиляции):

  • База данных экземпляров
  • Развертывание кода базы данных
  • Развертывание веб-приложений
  • Проверка развертывания
  • Выполнить приемочные испытания

Все вышеперечисленное можно запускать, отлаживать и тестировать независимо, без необходимости ставить новую сборку в очередь.

  1. С Powershell легко работать:

Пользовательские сборки, как правило, добавляют сложности и изящества к решению. Пример: обновление с TFS 2010 до TFS 2012 было очень болезненным, потому что все шаблоны сборки сломались. Нам пришлось перекомпилировать все наши пользовательские сборки, и только один разработчик в команде знал, как TFS Build был настроен для выполнения наших пользовательских действий. Недавно я удалил все пользовательские сборки из наших шаблонов сборки и использую исключительно Powershell.

Я настроил свои шаблоны процессов для вызова пользовательского скрипта powershell после завершения сборки TFS. Я делаю это с помощью аргумента пути в определении сборки. Этот аргумент является просто массивом строк, указывающих на сценарии. Выше я согласен с Ewald, что TFS не передает аргументы сборки в сценарии. Чтобы решить эту проблему, в моем шаблоне рабочего процесса я анализирую каждый сценарий в массиве строк и заменяю известные токены аргументами сборки - например, @ (BuildNumber), @ (SourcesDirectory) и т. Д. Я считаю, что это очень простое и надежное решение.

...