развернуть сайт MVC с помощью msdeploy, включая параметры IIS, с сервера CI, на котором нет настройки виртуального каталога - PullRequest
8 голосов
/ 20 февраля 2012

Я пытаюсь выяснить, как использовать msdeploy с моим сайтом MVC, чтобы иметь возможность автоматизировать развертывания, включая настройку IIS на удаленном сервере.

Я использую следующую команду для создания пакета:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Clients\PokerLeagueWebSite\PokerLeagueWebSite.csproj /T:Package /p:Configuration=Deployment

Моя настройка выглядит следующим образом:

local dev box using VS2010 + GIT
GITHUB for repo
Teamcity for CI server (different machine to dev box)
remote (same network) UAT server

Если установить флажок «Включить параметры IIS, настроенные в IIS» и «Включить параметры пула приложений, используемые этим веб-проектом», и создатьпакет на моей коробке разработчика, а затем опубликовать оттуда он прекрасно работает.Вот команда, которую я использую:

C:\myproject\Packages\Deployment\PokerLeagueWebSite>PokerLeagueWebSite.deploy.cmd /Y /M:192.168.10.98:8172 /U:administrator /P:password

Это создает виртуальный каталог на моем сервере UAT, и все в порядке.Проблема в том, что когда я фиксирую github, сервер CI загружает и собирает его.Естественно, виртуальный каталог не настроен на сервере CI, поэтому сборка / пакет завершается неудачно.

Я хочу использовать пакет, предоставляемый msdeploy, и иметь возможность удаленного развертывания сайта и IIS.Я предполагаю, что есть несколько вариантов:

1) Измените файл проекта MVC на параметры жесткого кода iis, чтобы при запуске / сборке пакета всегда создавались файлы XML с правильными настройками, чтобы он могбыть развернутым с любой машины.Я думаю, что это можно сделать с помощью файла package.xml в корневом каталоге проекта, но я не знаю, как настроить все настройки пула приложений и виртуального каталога.Чувствую, что я на полпути, но не могу получить окончательный толчок через линию.

2) Используйте powershell для изменения созданных файлов пакета XML, чтобы добавить параметры извлечения IIS.

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

Я полагаю, что я мог бы выяснить второй вариант, используя VS для созданияпакет и получить настройки, которые мне нужны, затем запишите его, но я не имею ни малейшего понятия и потратил немало времени, читая об этом, но безуспешно, как бы я сделал вариант 1.

NB

Читая некоторые из предложенных вопросов, прежде чем я разместил это, я вижу некоторые возможности:

MSdeploy развертывает приложение MVC 2 с неправильным именем виртуального каталога

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

Похоже, эта ссылка продолжается с вышеприведенным: http://msdn.microsoft.com/en-us/library/ee814764.aspx

На этой странице рассказывается о возможностях варианта 2.http://learn.iis.net/page.aspx/1082/web-deploy-parameterization/

Подумайте, вот как: используйте файл settings.xml в корне сайта для материалов проекта: http://vishaljoshi.blogspot.com/2010/07/web-deploy-parameterization-in-action.html

РЕДАКТИРОВАТЬ

Я продолжил читать и тестировать вокруг этого.Используя файл parameters.xml в корневом каталоге проекта, я могу получить параметры там, я думаю.Моя проблема, кажется, файл archive.xml.Это довольно сильно отличается от того, что вызывает неправильную установку пакета, если у меня не установлен флажок использования параметров IIS.Я начал читать о файле [project] .wpp.targets, который может помочь, но чертовски потерян с этим банкоматом.

EDIT 2

Так что я думаю, что янужно получить файл [project] .sourcemanifest.xml, чтобы изменить некоторые его настройки.Я считаю, что это то, что движет archive.xml, который сейчас отличается.Я думаю, что параметры. Xml работают правильно.

Когда НЕ используется IIS, sourcemanifest.xml выглядит следующим образом:

<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
  <IisApp path="C:\hoh_code\GIT\ai-poker-project\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" managedRuntimeVersion="v4.0" />
  <setAcl path="C:\hoh_code\GIT\ai-poker-project\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" setAclResourceType="Directory" />
  <setAcl path="C:\hoh_code\GIT\ai-poker-    project\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp"     setAclUser="anonymousAuthenticationUser" setAclResourceType="Directory" />
</sitemanifest>

Но когда я отмечаю использование настроек IIS, это выглядит так:

<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
  <appHostConfig path="Default Web Site/PokerLeague" />
  <contentPath path="C:\hoh_code\GIT\ai-poker-project\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" />
  <setAcl path="C:\hoh_code\GIT\ai-poker-project\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" setAclResourceType="Directory" />
  <setAcl path="C:\hoh_code\GIT\ai-poker-project\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" setAclUser="anonymousAuthenticationUser" setAclResourceType="Directory" />
</sitemanifest>

Не уверен, как изменить его, работая над файлом [project] .wpp.targets, но шарить в темноте.

РЕДАКТИРОВАТЬ 3

ОК, так что я подумал, что у меня это получится на минуту.в моем файле [project] .wpp.targets у меня есть:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>

    <AddContentPathToSourceManifestDependsOn>
      SetCustomACLs;
    </AddContentPathToSourceManifestDependsOn >
  </PropertyGroup>

  <Target Name="SetCustomACLs">
    <ItemGroup>
      <MsDeploySourceManifest Include="appHostConfig">
        <Path>Default Web Site/PokerLeague</Path>
      </MsDeploySourceManifest>
    </ItemGroup>
    <ItemGroup>
        <MsDeploySourceManifest Include="contentPath">
            <Path>$(_MSDeployDirPath_FullPath)</Path>
        </MsDeploySourceManifest>
    </ItemGroup>
  </Target>
</Project>

При сборке создается пакет развертывания, который я затем могу развернуть с моего устройства разработчика на сервер UAT, и он работает. Но когда я запускаю его на своем сервере CI, он не создает пакет развертывания, он выпадает на этапе манифеста с ошибкой:

One or more entries in the manifest 'sitemanifest' are not valid. 

Файл манифеста выглядит так:

<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
  <appHostConfig path="Default Web Site/PokerLeague" />
  <contentPath path="C:\TeamCity\buildAgent\work\71e78d4c543e0594\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" />
  <IisApp path="C:\TeamCity\buildAgent\work\71e78d4c543e0594\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" managedRuntimeVersion="v4.0" />
  <setAcl path="C:\TeamCity\buildAgent\work\71e78d4c543e0594\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" setAclResourceType="Directory" />
  <setAcl path="C:\TeamCity\buildAgent\work\71e78d4c543e0594\Clients\PokerLeagueWebSite\obj\Deployment\Package\PackageTmp" setAclUser="anonymousAuthenticationUser" setAclResourceType="Directory" />
</sitemanifest>

Я предполагаю, что это потому, что у него все еще есть IisApp, а также appHostConfig, который я добавил. Я просто догадываюсь об этом, и пока не знаю, как это убрать.

РЕДАКТИРОВАТЬ 4

ОК, поэтому я нашел параметр для удаления IISAPP из манифеста и параметры:

<DeployAsIisApp>False</DeployAsIisApp>

Это входит в файл wpp.targets.

Теперь возникла новая проблема, которая больше не будет развертываться. Я считаю, что это как-то связано с apphostconfig, работающим с сайтами, и iisapp, работающим с виртуальными каталогами.

РЕДАКТИРОВАТЬ 5

поэтому я изучал разницу между тикингом с IIS и моим обычным.

файлы sourcemanifest.xml совпадают systeminfo.xml одинаковы

setparameters.xml:

Раздел имени веб-приложения IIS отличается. В IIS версия имеет значение «Веб-сайт по умолчанию / pokerleague», а у моей - «C: \ sites \ pokerleague».

Я думаю, что именно это приводит к ошибке в settings.xml:

веб-приложение IIS имеет те же значения, а атрибут теги имеет физический, а не iisapp.

Ответы [ 2 ]

3 голосов
/ 10 января 2013

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

  • git repo
  • vs 2010, asp.net mvc 3
  • teamcity 7.1
  • msbuild
  • msdeploy

Я разделяю этапы сборки, упаковки и развертывания.Я не использую файлы msdeploy xml, но делаю то же самое в командной строке.

Это мои шаги:

Шаг 1: отредактируйте свойства проекта Visual Studio

щелкните правой кнопкой мыши проект «MyAppName» -> Свойства ..., вкладка «Пакет /Publish Web "...

  • Конфигурация: Active (Debug) - это означает, что конфигурация 'Debug' активна в VS, и вы ее редактируете.Конфигурации «Отладка» и «Выпуск» могут выбираться и редактироваться независимо.
  • Настройки пакета веб-развертывания - установите флажок «Создать пакет развертывания в виде zip-файла».Мы хотим, чтобы ZIP-файл был развернут позже отдельно.
  • Имя веб-сайта / приложения IIS - это должно соответствовать записи веб-сайта IIS на целевом сервере.Я использую «MyAppName /» без имени приложения после пути, потому что я создаю его в IIS вручную.Вот как это выглядит в конфигурации веб-сервера.

В первый раз я создаю веб-сайт IIS вручную (может быть, вы можете автоматизировать, а я нет).При использовании MSDeploy оно будет выдвигать ваше приложение к соответствующему имени веб-сайта - вам не нужно жестко кодировать пути к целевым папкам или что-либо еще.

Сохраните его вместе со своим проектом и убедитесь, что ваши изменения зарегистрированы в Git (отправлены в origin / master).Эти параметры будут извлечены из контроля версий, когда сервер CI выполнит шаги сборки.

Шаг 2: добавьте шаг сборки в конфигурацию TeamCity

Я редактирую шаги сборки и добавляю вторуюшаг сборки, чтобы собрать MyAppName.sln напрямую, используя msbuild.Вы можете изменить, как вам нравится, поскольку вы, вероятно, уже делаете это каким-то образом.

Шаг 3: исправьте ошибку сборки, установив распространяемый пакет оболочки Microsoft Visual Studio 2010 (интегрированный)

По сути, либо нам нужно установить VS на сервере сборки, либо вручную скопировать файлы, либо установить Распространяемый пакет оболочки Microsoft Visual Studio 2010 (интегрированный) .

Microsoft.WebApplication.targets не найден на сервере сборки.Каково ваше решение?

Это позволит его построить.Еще не развернуто на сервере.

Шаг 5: Установите средство MS Web Deployment

Я получил Web Deployment Tool здесь и установил.После перезагрузки логин TeamCity имеет ошибку 404.Оказывается, в Web Deploy есть служба, которая прослушивает порт 80, но также и сервер TeamCity Tomcat.На короткий срок я прекращаю работу веб-службы Web Deploy на панели управления и запускаю веб-службу TeamCity.Назначение службы агента веб-развертывания - принимать запросы к этому серверу от других серверов.Нам это не нужно, поскольку сервер TeamCity будет действовать как клиент и развертываться на других веб-серверах.

Инструмент веб-развертывания также должен быть установлен на целевом веб-сервере.Я не буду вдаваться в подробности здесь, но вы также должны настроить службу на прослушивание, поэтому, когда вы запускаете команду развертывания, она принимает ее и устанавливает на сервер.Для сервера я создал новую учетную запись с именем «webdeploy» с разрешением на установку.

Шаг 6. Создайте команду MSBuild для упаковки веб-проекта.

Я делаю отдельные шаги для упаковки и развертывания.Это позволит создавать пакеты Release, но при необходимости вручную их развертывать.

Это команда пакета msbuild:

"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" 
           MyAppName/MyAppName/MyAppName.csproj 
           /T:Package 
           /P:Configuration=Debug;PackageLocation="C:\Build\MyAppName.Debug.zip"

Позвольте мне объяснить части команды:

MyAppName.csproj: путь к файлу проекта VS для сборки.Там есть важные параметры, которые устанавливаются на вкладках свойств проекта.

/ T: Пакет: создать пакет ZIP

/ P: Configuration = Debug; PackageLocation = ***: запустить конфигурацию Debug. Это то же самое, что и сборка в Visual Studio с выбранным параметром «Отладка». «Расположение пакета» - это то, что он создал. Мы будем ссылаться на файл пакета позже в команде развертывания.

Шаг 7. Создайте команду Web Deploy для развертывания проекта ##

"C:\Program Files\IIS\Microsoft Web Deploy V2\msdeploy.exe" -verb:sync 
     -source:package="C:\Build\MyAppName.Debug.zip" 
     -dest:auto,wmsvc=webservername,username=webdeploy,password=******* 
     -allowUntrusted=true

Эту команду также стоит подробно объяснить:

-verb: sync: синхронизирует веб-сайт от источника к месту назначения

-source: package = "C: \ Build \ MyAppName.Debug.zip": источником является пакет zip-файла MSBuild

-dest: auto, wmsvc = webservername: использовать параметры в файле пакета для развертывания на сервере. Учетная запись пользователя - это учетная запись уровня ОС с разрешением. Указывается имя хоста, но не имя веб-сайта IIS (которое ранее указывалось в файле проекта MSBuild в свойствах проекта).

После развертывания я проверил файлы веб-сервера IIS, чтобы убедиться, что в них установлены самые последние библиотеки DLL и файл web.config.

Шаг 8: вызов MSDEPLOY из шагов сборки TeamCity

Поскольку теперь есть 2 хорошие команды (MSBUILD.exe для упаковки, MSDEPLOY.exe для развертывания), добавьте их к этапам сборки. Я использую бегун командной строки и просто вставляю ту же команду, что и предыдущие 2 шага.

запустить все это

Когда вы запустите сборку с этими шагами, если они пройдут успешно, вы получите автоматическое развертывание непосредственно из git.

Теперь каждый раз, когда новый код объединяется и помещается в ветку git origin / master, он автоматически создает и развертывает сервер разработки.

Как видите, это позволяет избежать исходной проблемы:

Проблема в том, что когда я выполняю коммит на github и сервер CI загружает и строит это. Естественно, виртуальный каталог не настроен на CI сервер, поэтому сборка / пакет завершается неудачей.

Сервер CI только строит и упаковывает. Затем он развертывается на целевом веб-сервере.

1 голос
/ 11 января 2013

Посмотрите на Appveyor.Мы только что выпустили v2.0 и IMHO, это действительно сильная альтернатива WebDeploy.Весь процесс развертывания может быть записан через PowerShell на CI-сервере, и есть PS-хуки для настройки процесса.

Отказ от ответственности: я разработчик Appveyor.Я не пытаюсь рекламировать здесь, но было бы здорово увидеть, если это работает для вас.

...