Прочитав первую ссылку в моем вопросе еще раз, я заметил, что вы можете отредактировать определение сборки (или шаблон), чтобы указать на профиль публикации, который вы хотите использовать:
Путь к настройкам развертывания: путь к вашему .pubxml-файлу для веб-приложения относительно корневой папки репозитория. Игнорируется для облачных сервисов.
К сожалению, это не работает и позволяет указать только один файл профиля публикации. Предположительно, даже если указание этого аргумента сработает, сборка все равно развернет только первое приложение в алфавитном порядке.
Это привело меня к этому вопросу и ответу, который предполагает, что непрерывное развертывание Azure / TFVC работает просто с использованием обычного веб-интерфейса. Разверните аргументы в MSBuild. Просмотр журналов диагностики моей сборки в Visual Studio Online подтвердил, что это так; вот соответствующие аргументы:
C:\Program Files (x86)\MSBuild\14.0\bin\amd64\msbuild.exe /p:DeployOnBuild=true /p:CreatePackageOnPublish=true /p:DeployIisAppPath=mysitename
Итак, согласно этому вопросу, чтобы использовать определенный профиль публикации, вы можете просто установить дополнительные необходимые аргументы MSBuild в определении сборки:
У каждого проекта должен быть профиль публикации с именем «publishprofilename.pubxml», в данном случае зарегистрированный в системе управления версиями. Я обнаружил, что имя пользователя (это имя вашего сайта со знаком доллара перед ним) не требуется, но, к сожалению, требуется строка пароля. Если вы не включите его, вы получите такую ошибку в сборке:
Не удалось выполнить задачу веб-развертывания. (Подключен к удаленному компьютеру («[mysitename] .scm.azurewebsites.net») с помощью службы веб-управления, но не может авторизоваться.
Никаких других аргументов мне не потребовалось, но включение пароля не кажется идеальным. Настройка развертывания по умолчанию, без использования профилей публикации, должна каким-то образом авторизоваться с этим паролем, но я не знаю, как это сделать.
Поэтому после внесения этого изменения я перешел на [mysitename] .azurewebsites.net, и оказалось, что все еще развертывается только проект веб-API. Однако, перейдя в консоль сайта и введя dir D:\home\site\wwwroot, я вижу, что оба проекта фактически развертываются. Просто оба проекта развертываются в корне сайта, по адресу D:\home\site\wwwroot. Параметры DeployIisAppPath различны в каждом профиле публикации, но эти значения игнорируются. Это связано с тем, что аргумент /p:DeployIisAppPath=mysitename для MSBuild (упомянутый выше) переопределяет любые PropertyGroup настройки в файлах профиля публикации * .pubxml, как описано в это сообщение в блоге.
Я обнаружил, что процесс непрерывного развертывания для Azure / TFVC работает за счет наличия действия сборки InitializeContinuousDeployment в шаблоне сборки TfvcContinuousDeploymentTemplate.12.xaml непосредственно перед действием RunMSBuild. Он принимает аргументы MSbuild, указанные в определении сборки, и добавляет к ним те, которые необходимы для развертывания в Azure. К сожалению, это в основном жестко запрограммировано, а это означает, что он всегда указывает единый путь развертывания для всех веб-проектов в решении. Вы не можете развернуть каждое веб-приложение в другом месте, используя только профили публикации.
Таким образом, один из вариантов обходного пути - добавить что-то вроде цели BeforeBuild MSBuild в каждый проект, чтобы переопределить значение командной строки DeployIisAppPath. Проблема заключается в том, что путь, указанный в профиле публикации и видимый в мастере публикации, больше не будет тем путем, который фактически используется для развертывания.
Так что решение, которое я выбрал, немного лучше; это то, что мы назвали бы в Новой Зеландии «хакерством».
По сути, я добавил действие сборки InvokeMethod между действиями InitializeContinuousDeployment и RunMSBuild. Аргументы в пользу этого действия следующие:
DisplayName:
Configure build for using publish profiles (removes DeployIisAppPath MSBuild parameter)
GenericTypeArguments:
System.String
MethodName:
SetValue
TargetObject:
AdvancedBuildSettings
Parameters:
Direction: Type: Value
In String "MSBuildArguments"
In String String.Join(" ", AdvancedBuildSettings.GetValue(Of String)("MSBuildArguments", String.Empty).Split(New String() {" "}, StringSplitOptions.RemoveEmptyEntries).Where(Function(s) Not s.StartsWith("/p:DeployIisAppPath=")))
Это полностью удаляет аргумент DeployIisAppPath из списка аргументов командной строки MSBuild, чтобы он не переопределял это свойство в профилях публикации. Вместо того, чтобы возиться с разделением и соединением строки, было бы немного лучше, если бы вы могли просто добавить /p:DeployIisAppPath="" в командную строку, но это просто устанавливает свойство в пустую строку, и вы получаете сообщение об ошибке:
Задаче ConcatFullServiceUrlWithSiteName не было присвоено значение обязательного параметра SiteAppName.
Как я уже сказал, довольно глупо, но это решение, которое позволяет вам непрерывно развертывать несколько веб-проектов в Azure с минимальным количеством изменений в настройках по умолчанию.
person
Adam Goodwin
schedule
16.08.2015
