2016-08-11 2 views
1

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

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

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

Я попытался следующие:

с помощью PowerShell

Start-Process <path to file> 

С CMD

с 'CMD' в качестве инструмента и следующие аргументы:

<path to file> 
start <path to file> 
/c start <path to file> 
cmd <path to file> 
cmd start <path to file> 
cmd /c start <path to file> 

Я также пробовал просто поставлять путь .exe в качестве имени инструмента, и никаких аргументов тоже не повезло.

Насколько хорошо это сработало?

Ну, для большинства из приведенных выше подходов, дополнительный шаг с командой PS Get-Process <exe name>* У меня получилось, что процесс был запущен. Тот же шаг не дал никаких результатов после шага, который остановил процесс, поэтому можно было бы обновить новый обновленный. Поэтому я уверен, что это работает, vNext build просто убивает все это после завершения сборки.

Другие решения

У меня 2 решения осталось, что я могу думать о том, должен работать, но оба решения слишком сложны для моей симпатии, в том, что я представляю совсем сложность процесса сборки, которые затем может пойти не так, но здесь идет:

  1. Установите сервер сборки как действительную цель развертывания. Затем я предполагаю, что могу использовать шаг «PowerShell on Target Machines», даже если я нацелен на себя. Я бы предположил, что он будет действовать как отдельные процессы. Для этого требуется всевозможные конфигурации, чтобы добавить их на место, плюс написать удаленный сценарий PowerShell для этой задачи.
  2. Написание небольшого окна, которое можно вызвать с помощью, например, REST, который затем может запустить процесс, поэтому новая служба Windows станет личным. - это просто вводит новый слой, который также может потребоваться обновить. Тогда это может быть обновлено вручную вместо автоматического.

Опять же, я бы предпочел не использовать ни одно из двух решений, если лучше. :)

ответ

2

На данный момент я оказался фиксируя его установкой AutoIt, и добавил этот простой скрипт в папку «развернуть» :

While 1 ; Opens up a WHILE loop, with 1 as a constant, so it is infinite 
If Not ProcessExists("DelphiDebug.exe") Then Run("DelphiDebug.exe") ; if the process of DelphiDebug.exe doesn't exist, it starts it 
Sleep (10) ; Puts the script to sleep for 10 milliseconds so it doesn't chew CPU power 
WEnd ; Closes the loop, tells it to go back to the beginning 

Credit goes to this forum entry где пример блокнота был сделан.

Я тогда сделал скрипт PowerShell, который переименовывает текущую версию, копирует Новопостроенной версию «развернуть» папку, останавливает запущенный экземпляр, и удаляет переименованную версию:

# CONSTANTS AND CALCULATED VARIABLES 
[string]$deploymentFolder = 'C:\Deployment-folder-on-local-machine' 
[string]$deploymentPath = "$deploymentFolder\my-program.exe" 
[string]$searchPathExistingVersion = $deploymentPath + '*' # The star is important so Get-Item does not throw an error 
[string]$toDeleteExeName = 'please-delete.exe' 
[string]$newCompiledVersionFullPath = "$env:BUILD_SOURCESDIRECTORY\sub-path-to-bin-folder\my-program.exe" 
[string]$processName = 'my-program' 
[string]$searchPathToDeleteVersion = "$deploymentFolder\$toDeleteExeName*" # The star is important so Get-Item does not throw an error 

# EXECUTION 
Write-Verbose "Search path: $searchPathExistingVersion" 
$existingVersion = Get-Item $searchPathExistingVersion; 
if ($existingVersion) { 
    Write-Debug "Match found: $existingVersion" 
    Rename-Item $existingVersion.FullName $toDeleteExeName 
} else { 
    Write-Debug 'No existing file found' 
} 
Write-Verbose "Copy new version from path: $newCompiledVersionFullPath" 
Copy-Item $newCompiledVersionFullPath $deploymentPath 
Write-Verbose 'Stopping running processes' 
Get-Process ($processName + '*') | Stop-Process # The new version is auto started with a running AutoIt script in the deployment folder. 
Write-Verbose "Deleting old versions with search path: $searchPathToDeleteVersion" 
$toDeleteVersion = Get-Item $searchPathToDeleteVersion 
if ($toDeleteVersion) { 
    Write-Debug "Match found: $toDeleteVersion" 
    Remove-Item $toDeleteVersion -ErrorAction SilentlyContinue # Deletion is not critical. Next time the build runs, it will attempt another cleanup. 
} else { 
    Write-Debug 'No file found to delete' 
} 

Опять же, это решение добавила еще одну сложность серверу, поэтому я оставляю вопрос открытым на несколько дней, чтобы увидеть, есть ли более простые решения. :)

1

Вместо того, чтобы запускать процесс во время сборки, я думаю, вам нужно установить процесс как службу Windows и запустить его. Имеет смысл, что любой процесс, который вы запускаете в контексте сборки, остановится при завершении сборки.Вы можете использовать командную строку для установки/обновления/запуска службы Windows:

sc create [service name] [binPath= ] 

https://ozansafi.wordpress.com/2009/01/14/create-delete-start-stop-a-service-from-command-line/

+0

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

Смежные вопросы