Определение сборки TFS2010 для развертывания на нескольких серверах?

Question

Я изучал новые функции сборки и развертывания TFS2010 с MSDeploy.Пока все идет хорошо (хотя было сложно найти информацию о конкретных сценариях).

Могу ли я изменить свое определение сборки, указав 2 или более серверов для развертывания?Что мне нужно сделать, это развернуть на нескольких серверах (так как у меня есть два в моей среде тестирования, которая использует NLB).

Теперь у меня есть определение Build, которое строит, запускает мои тесты, а затем развертывает вОДИН из моих тестовых серверов (на котором работает 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 

Примечание: я не использую / p: DeployIISAppPath = "xyz", так как он не развертывает все мои проекты и переопределяет конфигурацию моего проекта.

Могу ли ядобавить еще один аргумент сборки, чтобы он вызывал более одного MSDeployServiceURL?Как что-то вроде второго аргумента / p: MSDeployServiceURL, который указывает другой сервер?

Или мне нужно искать другое решение, например, редактирование WF?

Я видел почти точно такой же вопросздесь опубликовано 2 месяца назад: TFS 2010 - Развертывание на нескольких серверах после сборки , поэтому не похоже, что я единственный, кто пытается решить эту проблему.

Я также писал вфорумы IIS.NET, на которых обсуждается MSDeploy: http://forums.iis.net/t/1170741.aspx.У него было довольно много просмотров, но опять же нет ответов.

Answer 1

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

Сначала создайте переменную с именем ProjectName.Затем добавьте действие «Назначить» в последовательность «Компилировать проект».Это находится в последовательности «Попробуйте скомпилировать проект».Вот свойства Assign:

To: ProjectName
Value: System.IO.Path.GetFileNameWithoutExtension(localProject)

Вот свойства нашего действия InvokeProcess, которое развертывается на тестовом сервере:

Arguments: "/y /M:<server> /u:<domain>\<user> /p:<password>"
FileName: String.Format("{0}\{1}.deploy.cmd", BuildDetail.DropLocation, ProjectName)

You will need to change <server>, <domain>, <user>, and <password> to the values that reflect your environment.

Если вам необходимо вручную развернуть на сервереВы можете запустить команду ниже из вашей папки сборки:

deploy.cmd /y /M:<server> /u:<domain>\<user> /p:<password>

Answer 2

Я не смог найти решение, которое искал, но вот что я придумал в конце.

Я хотел, чтобы решение было простым и настраиваемым в аргументах TFS, в то же время оставаясь в соответствии с уже предоставленным методом MSBuildArguments, который получил широкое распространение. Поэтому я создал новый шаблон сборки и добавил новый аргумент TFS WorkFlow с именем MSBuildArguments2 на вкладке Аргументы WorkFlow.

Я искал в BuildTemplate WorkFlow все вхождения MSBuildArguments (было два вхождения).

Две задачи, использующие MSBuildArguments, называются Run MSBuild for Project. Непосредственно под этой задачей я добавил новый блок «Если» с условием:

Not String.IsNullOrEmpty(MSBuildArguments2)

Затем я скопировал задачу «Запустить MSBuild for Project» и вставил ее в новый блок If «Тогда», соответственно обновив его заголовок. Вам также потребуется обновить свойство ConmmandLineArguments новой задачи, чтобы использовать новый аргумент.

CommandLineArguments = String.Format("/p:SkipInvalidConfigurations=true {0}", MSBuildArguments2)

После этих модификаций WorkFlow выглядит следующим образом:

Сохраните и зарегистрируйте новый WorkFlow. Обновите определение сборки, чтобы использовать этот новый WorkFlow, затем на вкладке «Процесс» определения сборки вы найдете новый раздел под названием «Разное» с новым аргументом, готовым для использования. Поскольку я просто использую этот новый аргумент для развертывания, я скопировал те же самые аргументы, которые я использовал для MSBuild Arguments, и обновил MSDeployServiceURL для моего второго сервера развертывания.

И это все. Я предполагаю, что более элегантный метод - преобразовать MSBuildArguments в массив строк, а затем перебрать их во время процесса WorkFlow. Но это соответствует нашим требованиям к 2 серверам.

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

Answer 3

Мое решение для этого - новая цель, которая запускается после пакета. Каждый проект, который должен создать пакет, включает этот целевой файл, и я решил сделать условие Включить включенным для внешнего свойства «DoDeployment». Кроме того, каждый проект определяет свойство DeploymentServerGroup, чтобы конечные серверы были должным образом отфильтрованы в зависимости от типа проекта.

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

<!-- 
This targets file allows a project to deploy its package  

As it is used by all project typesconditionally included from the project file 

->

<UsingTask TaskName="Microsoft.TeamFoundation.Build.Tasks.BuildStep" AssemblyFile="$(TeamBuildRefPath)\Microsoft.TeamFoundation.Build.ProcessComponents.dll" />

<!-- Each Server needs the Group metadatum, either Webservers, Appservers, or Batch. -->
<Choose>
    <When Condition="'$(Configuration)' == 'DEV'">
        <ItemGroup>
            <Servers Include="DevWebServer">
                <Group>Webservers</Group>
            </Servers>
            <Servers Include="DevAppServer">
                <Group>Appservers</Group>
            </Servers>
        </ItemGroup>
    </When>
    <When Condition="'$(Configuration)' == 'QA'">
        <ItemGroup>
            <Servers Include="QAWebServer1">
                <Group>Webservers</Group>
            </Servers>
            <Servers Include="QAWebServer2">
                <Group>Webservers</Group>
            </Servers>
            <Servers Include="QAAppServer1">
                <Group>Appservers</Group>
            </Servers>
            <Servers Include="QAAppServer2">
                <Group>Appservers</Group>
            </Servers>
        </ItemGroup>
    </When>
</Choose>

<!-- DoDeploy can be set in the build defintion -->
<Target Name="StartDeployment" AfterTargets="Package">

    <PropertyGroup>
        <!-- The _PublishedWebsites area -->
        <PackageLocation>$(WebProjectOutputDir)_Package</PackageLocation>

        <!-- Override for local testing -->
        <PackageLocation Condition="$(WebProjectOutputDirInsideProject)">$(IntermediateOutputPath)Package\</PackageLocation>

    </PropertyGroup>

    <Message Text="Tier servers are @(Servers)" />

    <!-- A filtered list of the servers.  DeploymentServerGroup is defined in each project that does deployment -->
    <ItemGroup>
        <DestinationServers Include="@(Servers)" Condition="'%(Servers.Group)' == '$(DeploymentServerGroup)'" />
    </ItemGroup>

    <Message Text="Dest servers are @(DestinationServers)" />

</Target>

<!-- Only perform the deployment if any servers fit the filters -->
<Target Name="PerformDeployment" AfterTargets="StartDeployment" Condition="'@(DestinationServers)' != ''">

    <Message Text="Deploying $(AssemblyName) to @(DestinationServers)" />

    <!-- Fancy build steps so that they better appear in the build explorer -->
    <BuildStep
                    TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
                    BuildUri="$(BuildUri)"
                    Message="Deploying $(AssemblyName) to @(DestinationServers)...">
        <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>

    <!-- The deployment command will be run for each item in the DestinationServers collection.  -->
    <Exec Command="$(AssemblyName).deploy.cmd /Y /M:%(DestinationServers.Identity)" WorkingDirectory="$(PackageLocation)" />

    <BuildStep
                    TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
                    BuildUri="$(BuildUri)"
                    Id="$(StepId)"
                    Status="Succeeded"
                    Message="Deployed $(AssemblyName) to @(DestinationServers)"/>
    <OnError ExecuteTargets="MarkDeployStepAsFailed" />
</Target>

<Target Name="MarkDeployStepAsFailed">
    <BuildStep
            TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
            BuildUri="$(BuildUri)"
            Id="$(StepId)"
            Status="Failed" />
</Target>

Answer 4

Я не уверен, может ли это помочь вам с TFS 2010, но у меня есть запись в блоге для TFS 2012: Развертывание нескольких веб-проектов из TFS 2012 в среду с поддержкой NLB .

Answer 5

Я автор другого подобного поста.Я еще не нашел решение.Я полагаю, что это будет изменение рабочего процесса, чтобы добавить задачу MSBUILD -sync постобработки.Это кажется самым элегантным, но все еще надеялся найти что-то менее навязчивое.