TFS2010複数のサーバーに展開するための定義をビルドしますか?
-
29-09-2019 - |
質問
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
NB:私は使用しません /p:deployiiisapppath = "xyz"すべてのプロジェクトを展開せず、プロジェクトの構成をオーバーライドします。
別のビルド引数を追加して、複数のmsdeployserviceurlを呼び出すようにすることはできますか?別のサーバーを指定する2番目の /p:msdeployserviceurl引数のようなものですか?
または、WFの編集など、別のソリューションを探す必要がありますか?
ここでほぼまったく同じ質問を見ました2か月前に投稿しました: TFS 2010-ビルド後に複数のサーバーに展開します 、だから、これを解決しようとしているのは私だけではないようです。
また、msdeployが議論されているiis.netフォーラムにも投稿しました。 http://forums.iis.net/t/1170741.aspx 。それはかなり多くの意見を持っていましたが、繰り返しますが、答えはありません。
解決
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>
他のヒント
探していた解決策が見つかりませんでしたが、最後に思いついたものがあります。
TFS引数内でソリューションをシンプルで構成可能に保ちたいと同時に、すでに提供されているものと一致し続けたいと思いました MSBuildArguments
多くの宣伝されている方法。そこで、新しいビルドテンプレートを作成し、新しいTFSワークフロー引数を追加しました MSBuildArguments2
ワークフローの引数タブで。
のすべての出来事について、BuildTemplateワークフローを検索しました MSBuildArguments
(2つの発生がありました)。
使用する2つのタスク MSBuildArguments
呼ばれています Run MSBuild for Project
. 。このタスクの真下に、条件を持つ新しい「if」ブロックを追加しました。
Not String.IsNullOrEmpty(MSBuildArguments2)
次に、「Run MSBuild for Project」タスクをコピーして、新しいif'sの「ブロック」に貼り付けて、それに応じてタイトルを更新しました。また、新しいタスクのconmmandlineargumentsプロパティを更新して、新しい引数を使用する必要があります。
CommandLineArguments = String.Format("/p:SkipInvalidConfigurations=true {0}", MSBuildArguments2)
これらの変更の後、ワークフローは次のようになります。
新しいワークフローを保存して確認します。この新しいワークフローを使用するには、ビルド定義を更新し、[ビルド定義のプロセス]タブで、使用する新しい引数と呼ばれる新しいセクションがあります。私は単にこの新しい引数を展開に使用しているので、私が使用したまったく同じ引数をコピーしました MSBuild Arguments
MSDEPLOYSERVICEURLを2番目の展開サーバーに更新しました。
そして、それだけです。よりエレガントな方法は、MSBuildargumentを一連の文字列に変換し、ワークフロープロセス中にそれらをループすることだと思います。ただし、これは2つのサーバー要件に適しています。
お役に立てれば!
これに対する私の解決策は、パッケージの後に実行される新しいターゲットです。パッケージを作成する必要がある各プロジェクトには、このターゲットファイルが含まれており、外部設定の「DodePloyment」プロパティを条件とすることを選択しました。さらに、各プロジェクトは、宛先サーバーがどのようなプロジェクトであるかに応じて適切にフィルタリングされるように、DeploymenterServerGroupプロパティを定義します。
下部に向かってわかるように、サーバーリストを使用してコマンドファイルを実行するだけです。非常に簡単です。
<!--
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>
私は他の同様の投稿の著者です。私はまだ解決策を見つけていません。ワークフローを変更して、ポストプロセスのMSBuild -Syncタスクを追加する予定だと思います。それは最もエレガントのようですが、それでも少し邪魔にならない何かを見つけることを望んでいました。
それがTFS 2010であなたを助けることができるかどうかはわかりませんが、私はTFS 2012のブログ投稿を持っています: TFS 2012からNLB対応環境への複数のWebプロジェクトの展開.