deployment - TFS2010ビルド定義を複数のサーバーにデプロイしますか？

Question

私は、MSDeployを使用したTFS2010の新しいビルドおよび展開機能を調査してきました。これまでのところ、すべてが順調に進んでいます（ただし、特定のシナリオに関する情報を見つけるのは困難です）。

ビルド定義を変更して、デプロイ先の2つ以上のサーバーを指定できますか？私がする必要があるのは、複数のサーバーにデプロイすることです（NLBを使用するテスト環境に2つあるため）。

私が今持っているのは、ビルドしてテストを実行し、テストサーバーの1つ（MsDeployAgentServiceが実行されている）にデプロイするビルド定義です。これは正常に機能し、各Webプロジェクトはプロジェクトファイルで構成されたとおりにデプロイされます。私が使用する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を呼び出せるようにすることはできますか？別のサーバーを指定する2番目の/p：MSDeployServiceURL引数のようなものですか？

または、WFの編集など、別の解決策を探す必要がありますか？

2か月前に投稿されたほぼ同じ質問を見ました：TFS 2010-ビルド後に複数のサーバーにデプロイするので、これを解決しようとしているのは私だけではないようです。

また、MSDeployが議論されているIIS.NETフォーラムにも投稿しました：http：//forums.iis.net/t/1170741.aspx。かなり多くの意見がありましたが、やはり答えはありません。

Answer 1

2台のサーバーにデプロイするために、プロジェクトを2回ビルドする必要はありません。ビルドプロセスは、展開ファイルのセットをビルドします。その後、InvokeProcessを使用して複数のサーバーにデプロイできます。

まず、ProjectNameという名前の変数を作成します。次に、「プロジェクトのコンパイル」シーケンスに割り当てアクティビティを追加します。これは、「プロジェクトのコンパイルを試みる」シーケンスにあります。割り当てのプロパティは次のとおりです。

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、多く推進されているすでに提供されているメソッドに沿ったものにしたいと考えていました。MSBuildArguments2そこで、新しいビルドテンプレートを作成し、ワークフローの[引数]タブで呼び出される新しいTFSワークフロー引数を追加しました。

BuildTemplate WorkFlowを検索して、MSBuildArguments（2つの発生がありました）のすべての発生を検索しました。

を使用する2つのタスクMSBuildArgumentsはと呼ばれRun MSBuild for Projectます。このタスクのすぐ下に、次の条件を持つ新しい「If」ブロックを追加しました。

Not String.IsNullOrEmpty(MSBuildArguments2)

次に、「Run MSBuild for Project」タスクをコピーして、新しいIfの「Then」ブロックに貼り付け、それに応じてタイトルを更新しました。また、新しい引数を使用するには、新しいタスクのConmmandLineArgumentsプロパティを更新する必要があります。

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

これらの変更後、ワークフローは次のようになります。

新しいワークフローを保存してチェックインします。この新しいワークフローを使用するようにビルド定義を更新すると、ビルド定義の[プロセス]タブに、新しい引数を使用できるMiscという新しいセクションが表示されます。この新しい引数を展開に使用しているだけなので、使用したのとまったく同じ引数をコピーしてMSBuild Arguments、MSDeployServiceURLを2番目の展開サーバーに更新しました。

そしてそれはそれです。より洗練された方法は、MSBuildArgumentsを文字列の配列に変換し、ワークフロープロセス中にそれらをループすることだと思います。しかし、これは2つのサーバー要件に適合します。

お役に立てれば！

Answer 3

これに対する私の解決策は、Packageの後に実行される新しいターゲットです。パッケージを作成する必要がある各プロジェクトには、このターゲットファイルが含まれているため、外部で設定された「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

それがTFS2010で役立つかどうかはわかりませんが、TFS2012のブログ投稿があります。TFS2012からNLB対応環境への複数のWebプロジェクトの展開。

Answer 5

私は他の同様の投稿の著者です。私はまだ解決策を見つけていません。ワークフローを変更して、後処理のMSBUILD-syncタスクを追加すると思います。それは最もエレガントなようですが、それでも少し邪魔にならないものを見つけることを望んでいました。