Как сообщить TFS о развертывании нескольких webapps, содержащихся в одном решении?

У нас есть одно решение, которое содержит один проект webapp и некоторые сопутствующие проекты. Наш TFS 2010 строит это решение каждую ночь и развертывает webapp на сервере IIS. Он работает как ветерок.

На вкладке "Процесс" определения сборки TFS вы можете указать "Аргументы MSBuild". Это значение, которое задано в нашем определении сборки (все в одной строке):

/p:DeployOnBuild=True 
/p:DeployTarget=MsDeployPublish 
/p:CreatePackageOnPublish=True 
/p:MSDeployPublishMethod=WMSVC
/p:MSDeployServiceUrl=<service url of IIS> 
/p:DeployIisAppPath="<a website>" 
/p:UserName=<domain>\<user 
/p:Password=<password>

В этом блоге объясняется вся настройка: http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html.

До сих пор так хорошо.

Теперь мы добавили второй проект webapp, который мы хотим развернуть также в один и тот же IIS каждую ночь. К сожалению, в этом случае установка не применима. TFS развертывает только один webapp.

Есть другие проблемы с такой же проблемой:

TFS 2010 + MSDeploy, когда решение имеет несколько веб-приложений

и

WebDeploy для развертывания нескольких веб-сайтов

Vishal R. Joshi предлагает добавить некоторые свойства в каждый проект webapp. Теперь сборка release будет генерировать webpackage (zip файл) для каждого проекта webapp, который имеет следующие свойства:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DeployOnBuild>True</DeployOnBuild>
    <DeployTarget>Package</DeployTarget>
    <CreatePackageOnPublish>true</CreatePackageOnPublish>
</PropertyGroup>

Ok. Но как привести TFS для развертывания каждого webapp в IIS? Любые другие идеи?

ОТВЕТЫ

Ответ 1

Как пишет Vishal в статье в блоге, которую вы связали с собой, все параметры MSBuild могут быть перемещены внутри csproj. Это значит, что каждый проект может иметь свои собственные настройки.

У меня есть одно решение с 6 проектами, 4 классами и 2 веб-приложениями (WCF и MVC). Я следил за директивой из блога Vishal и просто переместил все мои параметры MSBuild в каждый файл csproj.. i.e.

  <PropertyGroup>
    <DeployOnBuild>True</DeployOnBuild>
    <DeployTarget>MsDeployPublish</DeployTarget>
    <CreatePackageOnPublish>True</CreatePackageOnPublish>
    <MSDeployPublishMethod>InProc</MSDeployPublishMethod>
    <MSDeployServiceUrl>localhost</MSDeployServiceUrl>
    <DeployIisAppPath>Dev.Auzzy\Web</DeployIisAppPath>
    <UserName>Username</UserName>
    <Password>Password</Password> 
    ...

Убедитесь, что вы удалили параметры из определения сборки.

Затем TFS развертывает, как ожидалось. каждый проект в правильную папку, указанную как домашний каталог для каждого сайта IIS.

Также стоит отметить, что вы не можете включить DeployIisAppPath в PropertyGroup, как указано выше, но используйте страницу свойств проекта, чтобы указать это для каждой конфигурации сборки. (Щелкните правой кнопкой мыши по каждому проекту > Свойствa > Пакет/Публиковать веб-сайт).

Ответ 2

Мне потребовалось 2 дня на эту проблему. Я нашел свободное решение, которое работает для меня.

Я создал еще 2 конфигурации с помощью решения Configuration Manager с именем DeployMvc1, DeployMvc2. Снимите флажок build для проекта MVC2 в DeployMvc1 и снимите флажок build для проекта MVC1 в DeployMvc2.

Далее я создал 2 определения сборки DeployMvc1Build и DeployMvc2Build. Первый прослушивает проект MVC1 с помощью

/p:DeployObBuild=true
/p:Deploytarget=MsDeployPublish
/p:Configuration=DeployMvc1
/p:Platform="Any CPU"
/p:MSDeployPublishMethod=WMSvc
/p:MsDeployServiceUrl="https://{server1}:8172/MsDeploy.axd"
/p:DeployIisAppPath="mvc1"
/p:AllowUntrustedCertificate=True
/p:Username="{username}"
/p:Password={password}

Второй прослушивает проект MVC2 с помощью

/p:DeployObBuild=true
/p:Deploytarget=MsDeployPublish
/p:Configuration=DeployMvc2
/p:Platform="Any CPU"
/p:MSDeployPublishMethod=WMSvc
/p:MsDeployServiceUrl="https://{server2}:8172/MsDeploy.axd"
/p:DeployIisAppPath="mvc2"
/p:AllowUntrustedCertificate=True
/p:Username="{username}"
/p:Password={password}

Тогда моя проблема решена.

Ответ 3

У меня есть аналогичная ситуация, когда у меня есть файл сборки TFSBuild.proj, и я создаю несколько инсталляторов и пакетов в конце сборки, нацеливая каждую среду развертывания: разработку, тестирование, постановку и производство. Свойства, определенные в ответе @Matt Shepherd, также могут быть предоставлены непосредственно заданию MSBuild вместо того, чтобы записывать их в отдельные файлы проекта.

<!-- After build -->
<Target Name="AfterCompileSolution">

  <!-- Create SynchWorkflow deployment packages -->
  <CallTarget Targets="PackageSynchWorkflow" />

</Target>

<!-- Build deployment package for each target environment -->
<ItemGroup>
  <BuildMode Include="Development"/>
  <BuildMode Include="Test"/>
  <BuildMode Include="Staging"/>
  <BuildMode Include="Production"/>
</ItemGroup>
<PropertyGroup>
  <PackageLocation>$(OutDir)</PackageLocation>
</PropertyGroup>

<Target Name="PackageSynchWorkflow" Outputs="%(BuildMode.Identity)">
  <Message Text="Building %(BuildMode.Identity)"/>

  <MSBuild Projects="$(SolutionRoot)\SynchWorkflow\SynchWorkflow.csproj"
           Properties="Platform=Any CPU;
                       Configuration=%(BuildMode.Identity);
                       DeployOnBuild=true;
                       DeployTarget=Package;
                       DeployIisAppPath=Default Web Site/SynchWorkflow;
                       OutputPath=$(PackageLocation)\SynchWorkflow.%(BuildMode.Identity)Package;"/>
</Target>

В этом случае можно указать DeployIisAppPath, и это значение будет записано в файл параметров пакета развертывания.

Ответ 4

Один из вариантов - записать это в задаче MSBuild. Таким образом, вы можете поддерживать несколько неограниченных развертываний Webapp без IE. Мне еще предстоит перенести наши существующие файлы proj, которые делают это, поэтому я не столкнулся с этой проблемой. Во всяком случае, вот статья, в которой описывается этот процесс:

Статья

Надеюсь, что поможет