Visual Studio Team Servicesで2つのビルドをテストしないようにする

Question

新しいVSTSデプロイメントのためにビルド時間を短くしたいのですが、問題が発生しました。ビルドとテストの両方でデプロイメントの実行には成功しますが、私たちのインフラストラクチャのために、msbuildをデプロイフラグとともに使用する必要があります。

現在のビルドステップは、フラグを使用しています：/p:AllowUntrustedCertificate=True /p:DeployOnBuild=true /p:PublishProfile="$(PublishProfileName)" /p:Username=$(UserName);Password=$(Password) /p:EnableMSDeployAppOffline=true

現在のアーキテクチャ：

Step 1: Nuget Restore (3s) 

Step 2: Build/Deploy Solution (50s) 

Step 3: Other Deploy Tasks (102s) 

理想のアーキテクチャ：

Step 1: Nuget Restore 

Step 2: Build Solution 

Step 3: Run Tests 

Step 4: Deploy built solution 

Step 5: Other Deploy Tasks 

は基本的に私がどこその倍の50代を負担したくないI必要はありませんが、フラグ/ p：DeployOnBuildを使用するときにmsbuildが何をしているのかはわかりません。

Answer 1

/p：DeployOnBuildの引数は、成功ビルド後にプロジェクトを展開することを示します。ビルドとパブリッシュ/デプロイの間に違いはありません。

手順4では、ビルドに50時間を要しません。ファイルが変更されているかどうかをチェックし、そうでない場合は結果が最新のものになります。もう一度プロジェクトしてください。余分な時間は必要ありません。ご心配なく。構成とプラットフォームが同じであることを確認してください。

一方、baywetさんの提案はかなり分かりやすく、4と5段階に分かれています。

Answer 2

希望のアーキテクチャのステップ4と5をリリース定義に分割する必要があると思います。
これはベストプラクティスであるだけでなく、ビルド（ステップ1,2、および3）が成功したときに2番目の部分を起動させて、時間を節約することもできます。
手動トリガを避けて時間を節約するために、ビルドが成功したときに自動的にトリガするようにリリースを設定できます。
2つのテストプロジェクト/カテゴリの間でテストを分割して、テストタスクを必要なときにターゲットに絞るだけのテストタスクを微調整することもできます。
希望するもの