2016-02-11 23 views
15

TFS 2015(Update 1)をオンプレミスにインストールしたばかりで、新しいTFSビルドシステムを使用してContinuous Integration/Buildシステムを作成しようとしています。ビルドはうまく動作し、私に緑色の光を与えますが、デフォルトのビルドを見るとbinディレクトリからバイナリをビルドしているだけなので、ローカルサーバーにオンプレミスのアプリケーションを簡単にデプロイする方法はないようです。TFS 2015でWebアプリケーションをビルドおよび展開する

ファイルシステムのコピーとpowershellスクリプトの2つの展開オプションがあります。ファイルを新しいサーバーにコピーするのに十分なほど簡単ですが、ビルドではバイナリのみがビルドされているため、これのためにWebアーティファクト(cshtml、画像、スクリプト、CSSなど)を収集するツールを参照してください。

http://www.deliveron.com/blog/building-websites-team-foundation-build-2015/

しかし、これはWebDeployを使用すると、むしろ厄介な展開パッケージを作成します。

は徹底的なGoogle検索の後、私は唯一で、この語る一品を見つけました。

サイト(標準のMVC Webアプリケーション、私のテストではプロジェクト作成ウィザードで作成されたデフォルトの定型サイトを使用しています)を、ローカルサーバーに可能な限り簡単に配布できますか? WebDeployをサーバーにインストールする必要はなく、PowerShellなどを使用して最終成果物を展開します。

ビルドは、ビルド、テスト、インデックス&パブリッシュ、ビルド成果物の公開)の4つの手順で、標準のVisual Studioビルドテンプレートです。

+0

これはどのようにあなたのために行くのですか?私は、次のテストステップが失敗した場合、配備が行われないようにしようとしています。あなたはそれをできましたか? –

+1

@ one.beat.consumer - デプロイメントからのコンパイル/テストを2つの別々の段階として分割し、同じコードをtest/qa/prod環境にデプロイすることができます。 –

+0

ありがとうございます。 「リリース」機能は、前述のようにパッケージを展開しています。私が問題を抱えていたのは、ビルドステップからテストの実行を分離することでした.XUnitで見つかった唯一の例はビルドのカスタマイズでした。私はその後、xunit.runner.visualstudio NuGetパッケージを見つけました。これにより、テストステップを適切にカスタマイズすることができます。ただし、テスト用の準備を最初に作成するのは2回、テストが合格すると2回目の展開パッケージが作成されます。 –

答えて

15

は、私たちはライン以下の使用のステップとMSBuildのための引数として「Visual Studioのビルド」を使用します。パブリッシュプロファイルの名前(pubxmlファイルのファイル名)でなければなりません。ファイルNameがBuild.pubxmlの場合、パブリッシュプロファイルはBuildです。例えば

/p:DeployOnBuild=True /p:PublishProfile=Build 
+3

@サバスティアン - ありがとう。私の質問は、次のVisual Studio Testビルドの手順が失敗した場合に、この展開を防ぐ方法です。 –

-5

私たちはWebDeploy/MSDeployを40以上のアプリケーションで使用しています。より簡単に展開できるように、すべてのサーバーにWebDeployをインストールしますが、WebDeployをプリインストールする必要のないWeb Deploy On Demand機能を使用することもできます。

/p:DeployOnBuild=True /p:PublishProfile=$(DeploymentConfiguration) 

変数にタブページでDeploymentConfigurationが設定されるようにしています

1

I wanted to add that Ben Day has an excellent write-up that helped us package quickly and then release to multiple environments through Release Manager

彼のMSBuildの引数は次のようになります。

/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=$(build.artifactstagingdirectory)\for-deploy\website 

これと受け入れ答えの違いは、このパラメータセットは、アーティファクトフォルダ内のすべてのステージということで、その後、ビルドの一部として保存します。次に、まったく同じコードを繰り返し配置することができます。

for-deployフォルダと一緒にweb.env.configファイルを取得し、展開プロセスでxdt変換を使用して、展開先の環境に合わせてすべてが更新されるようにします。私たちのすべてのWebプロジェクトでうまく動作します。

+1

パブリッシュディレクトリはパブリッシュプロファイルで設定できます。コマンドラインで指定する必要はありません。したがって、より簡単にバージョン管理することができます –

+0

これは良い点です。私たちの環境(おそらくここでは珍しいかもしれません)では、ビルド成果物としてサイトをキャプチャし、TFSリリースマネージャを通じて複数のターゲットに展開するために、公開プロファイルを上書きするためにこの方法を選択しました。 –

関連する問題