Определение сборки TFS2010 для развертывания на нескольких серверах?
Я изучал новые возможности сборки и развертывания TFS2010 с помощью MSDeploy. Пока все идет хорошо (хотя информацию о конкретных сценариях найти было сложно).
Могу ли я изменить определение сборки, указав 2 или более серверов для развертывания? Что мне нужно сделать, так это развернуть на нескольких серверах (поскольку у меня есть два в моей тестовой среде, которые используют NLB).
Теперь у меня есть определение сборки, которое выполняет сборку, запускает мои тесты, а затем развертывает на ОДИН из моих тестовых серверов (на котором работает MsDeployAgentService). Он отлично работает, и каждый веб-проект развертывается в соответствии с настройками в файле проекта. Я использую следующие аргументы MSBuild:
* /p:DeployOnBuild=True
* /p:DeployTarget=MsDeployPublish
* /p:MSDeployServiceURL=http://oawww.testserver1.com.au/MsDeployAgentService
* /p:CreatePackageOnPublish=True
* /p:MsDeployPublishMethod=RemoteAgent
* /p:AllowUntrustedCertificated=True
* /p:UserName=myusername
* /p:Password=mypassword
NB: Я не использую / p: DeployIISAppPath = "xyz", поскольку он не развертывает все мои проекты и переопределяет конфигурацию моего проекта.
Могу ли я добавить еще один аргумент сборки, чтобы он вызывал более одного MSDeployServiceURL? Что-то вроде второго аргумента / p: MSDeployServiceURL, который указывает другой сервер?
Или мне нужно искать другое решение, например, редактировать WF?
Я видел почти точно такой же вопрос, размещенный здесь 2 месяца назад: TFS 2010 - Развертывание на нескольких серверах после сборки , поэтому не похоже, что я единственный, кто пытается решить эту проблему.
Я также разместил на форумах IIS.NET, где обсуждается MSDeploy: http://forums.iis.net/t/1170741.aspx . Было довольно много просмотров, но опять же никаких ответов.
2 ответа
Я являюсь автором другого аналогичного поста. Мне еще предстоит найти решение. Я полагаю, что это будет изменение рабочего процесса, чтобы добавить задачу постобработки MSBUILD -sync. Это казалось самым элегантным, но все же надеялся найти что-то менее навязчивое.
Я не мог найти решение, которое искал, но вот что я в итоге придумал.
Я хотел, чтобы решение оставалось простым и настраиваемым в рамках аргументов TFS, в то же время оставаясь в соответствии с уже предоставленным методом MSBuildArguments , который активно продвигался. Поэтому я создал новый шаблон сборки и добавил новый аргумент TFS WorkFlow под названием MSBuildArguments2 на вкладке «Аргументы» рабочего процесса.
Я поискал в BuildTemplate WorkFlow все случаи появления MSBuildArguments (было два случая).
Две задачи, использующие аргументы MSBuild , называются Выполнить MSBuild для проекта . Непосредственно под этой задачей я добавил новый блок «If» с условием:
Not String.IsNullOrEmpty(MSBuildArguments2)
Затем я скопировал задачу «Run MSBuild for Project» и вставил ее в новый блок «Then» If, соответствующим образом обновив его заголовок. Вам также необходимо обновить свойство ConmmandLineArguments новой задачи, чтобы использовать новый аргумент.
CommandLineArguments = String.Format ("/ p: SkipInvalidConfigurations = true {0}", MSBuildArguments2)
После этих изменений рабочий процесс выглядит следующим образом:
Сохранить и вернуть новый рабочий процесс. Обновите определение сборки, чтобы использовать этот новый рабочий процесс, затем на вкладке «Процесс» определения сборки вы найдете новый раздел под названием «Разное» с новым аргументом, готовым к использованию.Поскольку я просто использую этот новый аргумент для развертывания, я скопировал те же самые аргументы, которые использовал для аргументов MSBuild , и обновил MSDeployServiceURL на моем втором сервере развертывания.
Вот и все. Я полагаю, что более элегантным методом было бы преобразовать MSBuildArguments в массив строк, а затем перебрать их в цикле во время процесса WorkFlow. Но это соответствует нашим двум требованиям к серверу.
Надеюсь, это поможет!