Team Foundation Server 2015 リリース ノート

  • [アーティクル]

| | Developer Communityシステム要件と互換性 | ライセンス条項 | TFS DevOps ブログ | SHA-1 ハッシュ | 最新の Visual Studio 2019 リリース ノート

Note

これは、Team Foundation Server の最新バージョンではありません。 最新のリリースをダウンロードする場合は、Team Foundation Server 2018 Update 3 の最新のリリース ノートを参照してください。 ページ フッターにある地球アイコンをクリックし、目的の言語を選択すると、このページの言語を変更できます。

この記事では、Team Foundation Server 2015 に関する情報を紹介します。

Team Foundation Server 2015 の詳細については、「 と互換性 」ページを参照してください。

詳細については、TFS のインストール ページを参照してください。

リリース ノート アイコンリリース日: 2015 年 8 月 6 日

Team Foundation Server 2015 の新機能の概要

SKU の変更:

機能の更新:

Team Foundation Server 2015 の新機能の詳細

Basic ライセンスの拡張

"Basic" ライセンスを持つすべての Team Foundation Server ユーザーが、次の機能を使用できるようになりました。

  • Web ベースのテスト実行
  • アジャイル ポートフォリオ管理
  • 作業項目グラフの作成
  • チームのルーム

これが意味すること:メンバーが 5 人以下のチームは "Basic" ライセンスを持っていれば、無料で Team Web Access を使用してこれらの機能にアクセスできます。また、これより多人数のチームは、非常に低価格でこの機能にアクセスできます。

データベースのスキーマの変更

Team Foundation Server 2015 には、そのデータベースで使用されるスキーマへの変更が多数含まれています。そのため、TFS 2013 とそれ以前のリリースからのアップグレードにはかなりの時間がかかると予想されます。 アップグレードはオフラインであるため、Microsoft は TfsPreUpgrade.exe というツールを提供しています。これを使用すると、TFS 2013 QU4 と QU5 のデプロイに対して最も時間のかかる部分のアップグレードをオンラインで実行できます。 このアップグレード ウィザードには準備チェックが含まれており、データベースのサイズが大きく、TfsPreUpgrade.exe の実行が推奨される場合に警告されます。

Project Server の拡張機能

Project Server の拡張機能は、個別にダウンロードされます。 詳細については、ダウンロードに関するページの TFS セクションを参照してください。

SharePoint の拡張機能

以前は、Team Foundation Server を別のマシン上にある SharePoint インスタンスと統合したい場合は、SharePoint サーバーで Team Foundation Server インストーラーを実行してから SharePoint 用 TFS 拡張機能を構成する、"または" SharePoint 用 TFS 拡張機能の構成に必要なビットのみを配置する特殊なインストーラー (tfs_sharePointExtensions.exe) を実行することができました。

この特殊なインストーラーが削除されたため、Team Foundation Server を SharePoint と統合するには、SharePoint サーバーで Team Foundation Server インストーラーを実行してから SharePoint 用 TFS 拡張機能を構成する必要があります。

ID コントロールとアバター

この新しいコントロールには、ユーザーのフル ネーム、アバター、メール アドレスが含まれています。

このコントロールは、きわめて直感的に使用できるように設計されています。 コントロールにフォーカスを移すと、作業項目を最後に割り当てたユーザーの MRU (最近使用した) 一覧が表示されます。 探している人が一覧にない場合は、[検索] をクリックするだけで、アカウント内のユーザーから、一致する結果が一覧に表示されます。 また、新しい ID コントロールが提供されただけでなく、アバターが含まれるように、ユーザーの名前が表示される場所の多くがリファクタリングされました。 アバターが作業項目やボードなどのカードに表示されます。

タスクボード:バックログとボードに表示されるバグ

プロセス テンプレートに関係なく、チームが、バックログにバグを表示するかどうかを選択できるようになりました。 この設定の機能が拡張されました。 チームは、バックログとタスクボードにバグを表示するときに、要件 (ユーザー ストーリーまたはプロダクト バックログ項目) を表示する、タスクを表示する、まったく表示しないから選択できるようになりました。

プロダクト バックログの更新

バックログ ナビゲーションの更新

バックログのナビゲーションが一新されました。 すべてのバックログから、タスクに至るまで、より多くのレベルにドリルダウンすることができます。 さらに、すべてのバックログから、親フィルターを使用して、バックログの上位レベルをオンまたはオフに切り替えることができます。 チームが所有していないがリレーションシップに基づいて取り込まれた項目には、色がくりぬかれたバーが表示されます。 チームが所有する項目と他のチームが所有する項目をひとめで区別できます。

最後に、すべてのビューで並べ替え、親の再指定ができます。 任意のビューでドラッグ アンド ドロップするだけで、項目の順序を変更し、リレーションシップを変更できます。

ポートフォリオ バックログ レベルへのオプトイン

ナビゲーションの更新に関連して、チームが使用していないバックログ レベルを無効にできるようになりました。 この更新の前は、すべてのバックログ レベルがすべてのチームに強制されていました。 各バックログ レベルが "オプトイン" になり、チームに適したレベルを構成することができるようになりました。 ページの上部にある歯車をクリックし、構成するチームを選択してから、必要なバックログ レベルを選択します。

フィルター処理されたバックログ内の並べ替え

コンテキスト メニューで、バックログにフィルターが適用されている場合でも、項目を一番上または特定の位置に移動するオプションを利用できるようになりました。

バックログとクエリのテキスト フィルター処理

ツールバーに配置された新しいフィルター テキストボックスを使用して、バックログとクエリ結果をすばやくフィルター処理できるようになりました。 探している項目のテキストを入力するだけで、バックログと結果がすぐにフィルター処理され、テキストが一致する項目のみが表示されます。 この機能は、特定の項目 (または一連の項目) の長いバックログまたはクエリ結果をスキャンする場合に非常に便利です。 一致は、タグを含む、表示されている列のデータに対して行われることに注意してください。

スプリント バックログとタスク ボードの更新

親を持たないタスクを表示する

スプリント内で親ストーリーを持たないタスクが、"親のない" カテゴリの下にあるスプリント バックログとタスク ボードに表示されるようになりました。 親を持たない行は、灰色のバーで強調表示されます。 親を持たない行から任意のユーザー ストーリーにタスクを移動できます。また、その逆も可能です (メモ: 親を持たない行をドラッグ & ドロップすることはできず、常に、スプリント バックログとタスクボードの上部に表示されます)。

完了したストーリーを折りたたむ

完了したストーリーは、タスク ボードを開いたときに自動的に折りたたまれます。 スプリント バックログのすべてのストーリーは、既定では折りたたまれます。 折りたたまれているが保留中の作業があるストーリーは、タスク ボードに警告が表示されます。 タスク ボードの折りたたまれた行には、そのユーザー ストーリーの保留中の作業の概要も表示されます。 また、タスク ボード上の PBI が、タスクと同じようにカードとして表示されるようになりました。

フィールドとタグを追加してカードをカスタマイズおよび構成する

かんばんボード上のカードの外観をカスタマイズできるだけでなく、カードに表示されるデータの構成オプションが [カードのカスタマイズ] ダイアログ ボックスに追加されました。

(タスクボードにも同様のカスタマイズ ダイアログ ボックスを使用できます)。

ID を有効または無効にする、担当者フィールドの表示方法を選択する、カードへのタグの直接表示を選択することができます。 ほとんどのユーザーは、すべてのカードに "役職" や "担当者" などのフィールドが欲しいと考えますが、カードを開いて詳細を確認しなくてもアクションを実行できるように、もう少し詳しい情報を追加する方が時間の節約になります。 たとえば、次のバグ カードに "優先度" と "重大度" の両方が追加されていることに注目してください。

カスタム フィールドの例

カードに追加したカスタム フィールドは、ボードから直接編集できます。 また、これらのオプションは、最大限の柔軟性が得られるように、チーム (またはバックログ) ごと、作業項目ごとです。

かんばんボードの更新

かんばんボードからの直接追加と編集

すべてのボードが、新しいカードの追加とインライン編集をサポートするように更新されました。 かんばんボードの最初の列の上部に、新しいカードを追加する [新しい項目] ボタンが追加されました。 新しいカードを追加した後、カード上のすべてのデータをカード自体から直接編集できます。 かんばんのインラインの追加と編集について詳細を確認してください。

かんばんボード上の並べ替え

ボード上の項目の並べ替えが有効になりました。 ボード上の各列内で優先度に合わせて項目を上下に移動できるようになりました。 ボード上で変更が行われると、バックログにも直接反映されます。 実際、ボードでの追加、インライン編集、並べ替えが今回サポートされたため、この変更により、多くのユーザーがバックログよりもボードを使用することを選択する可能性があります。 かんばんの並べ替えについて詳細を確認してください。

かんばんボードに表示されるすべてのデータに対してフィルター処理を行う

ボード全体をフィルター処理できるようになりました。 すべてのボード フィルターにフィルター語句を入力すると、追加したフィールドや、タグ、ID など、カードに表示されている情報でフィルター処理が行われます。 バックログでその項目を見つけてかんばんボードに取り込むことができるように、最初の列にもフィルターが用意されました。

かんばんボードの列を分割する

かんばんボードに "列の分割" という新機能が追加されました。 かんばんチームは、ボード上で作業を移動するのにプル モデルを使用します。 これを効果的に行うために、ボード上の各列が 2 つのサブ列 (実行中と完了) に分割されています。 [完了] 列にカードを移動することで、作業を進める準備が整っていること、その次のステージを所有するユーザーまたはチームがカードをプルできることを明確に示すことができます。

ボード上の任意の列を分割するには、ツールバーの [列のカスタマイズ] リンクをクリックするだけです。

かんばん分割列の詳細については、こちらを参照してください。

かんばんボード上のスイムレーン

チームが水平スイムレーンを作成して、作業のさまざまなクラスを追跡できる機能が追加されました。 典型的な例として、急送レーンがあります。 各チームが独自のレーンを作成し、ボードを思いどおりに見せることができるようになりました。

かんばんの完了の定義

ボード内で作業が移動するとき、各列の "完了"の意味について、チーム メンバーが同じ認識を持っていることが重要です。 今回のリリースで、ボード上の各列に対して完了の定義を指定できる新機能が追加されました。 マークダウンもサポートされているため、テキストの書式を設定したり、他の場所にハイパーリンクを含めたりすることができます。定義を含む列のヘッダーに、合意した定義を示す小さなアイコンが追加されました。

Kanban DoD (完了の定義) の詳細を確認してください。

CFD グラフの最初の列を無効にする

かんばんボードの最初の列を省略し、より有意義な CFD グラフを取得できるようになりました (最初の列は、多くの場合、チームが作業している項目の長いバックログを表し、かんばんボード上でアクティブになっている項目ではありません)。

これを行うには、CFD グラフで [編集] を選択し、[最初の列を含める] チェックボックスをオフにします (すべての既存のバックログと CFD グラフでは、このボックスは既定ではオンになっていることに注意してください)。

プロセス テンプレートの SAFe サポート

既存のスクラム、アジャイル、CMMI のテンプレートを使用して、Scale Agile Framework (SAFe) の組み込みサポートが提供されました。

エピックのサポート
  • エピックを追跡するために、エピック作業項目の種類、バックログ、ボードが追加されました。 エピックは、階層的にフィーチャーの上位に位置します。 バックログ項目がフィーチャーにマップされるように、フィーチャーはエピックにマップされます。
  • バックログとボードの完全な機能を使用できます。 他のバックログのようにエピック バックログを管理できるほか、かんばんの列とカードを必要に応じてカスタマイズできます (Epics バックログは既定では有効になっていません。この機能を有効にするには、[チームの設定] ページから [エピック] チェックボックスをチェックします)。
  • エピック バックログは、チーム レベルで有効または無効にすることができます。 Microsoft のホワイトペーパーにあるように、ポートフォリオ チームがエピック バックログを有効にする必要があります。 プログラムおよびフィーチャー チームは、組織内のエピックを管理しない場合にエピック バックログを無効にすることができます。
アーキテクチャとビジネス バックログのサポート

[価値の分野] フィールドが、バックログに表示されるすべての作業項目に追加されました。エピック、フィーチャー、このフィールド (プロセス テンプレートに応じる) は、プロダクト バックログ項目、ユーザー ストーリー、要件にも表示されます。

価値の分野は、2 つの値を持ちます。ビジネスとアーキテクチャです。 既定値では、すべてのエピック、フィーチャー、およびストーリーはビジネス タイプです。 アーキテクチャ エピック、フィーチャー、またはストーリーを作成するには、値を [アーキテクチャ] に設定します。

この機能を使用すると、アーキテクチャ エピックを定義できます。これは、アーキテクチャ フィーチャーおよびストーリーに分けられ、これにより、組織全体のアーキテクチャのロードマップを追跡することができます。

プロセス テンプレートの名前変更

テンプレートの名前が、バージョン名を含む詳細名 (たとえば、"MSF for Agile Software Development 2013.4") から、わかりやすい "スクラム"、"アジャイル"、"CMMI" に変更されます。 テンプレートがロックされるようになりました。これは、送付済みテンプレートに変更を加えることができないことを意味します。 カスタム プロセス テンプレートを送付済みテンプレートに基づいて作成するには、既存のテンプレートをエクスポートして新しい名前とバージョンを指定し、プロセス テンプレート マネージャーを使用して再インポートするだけです。 既存のプロジェクトは、この変更の影響を受けません。つまり、プロセスを witadmin を使用して引き続きカスタマイズすることができます。

現在のイテレーション クエリ トークン

この機能を使用すると、イテレーションベースのクエリで現在のイテレーションを表すトークンを指定できます。 ご存知のとおり、イテレーションには日付が関連付けられています。 イテレーションからイテレーションに移行する際、次のイテレーションの作業を追跡するために使用されるすべてのクエリを更新するのは非常に面倒です。 今回のリリースで、今日の日付に基づいて現在のイテレーションを返す新しいクエリ トークン @CurrentIteration が追加されました。 ただし、この新しいトークンにはいくつかの制限があります。 たとえば、Excel では機能しません。 このトークンはチームのコンテキストを理解しているかどうかに依存しており、残念ながら Excel には、どのイテレーションが現在のものかを判断するために必要なすべての情報が含まれていません。 詳しくは、現在のイテレーション クエリ トークンに関するページを参照してください。

クエリの段階的開示

クエリ ペインが表示されるたびに、大きなクエリ一覧が開かれないようになりました。 最初の 2 つのレベルのみが読み込まれ、残りのレベルは必要に応じて読み込むことができます。

ブランチ ポリシー

Git を使用しているチームが、リポジトリに入れるコードの品質を向上できるように、ブランチにポリシーを設定する新機能が追加されました。 これらの新しいポリシーを使用すると、チームは、プル要求をプッシュまたはマージするときにサーバーによって適用される開発ブランチの要件を構成できます。 ビルド ポリシーを使用して、ブランチに入るすべての変更が、構成済みビルドに合格する必要があることを要求することで、ビルドの中断を防ぐことができます。 コード レビュー ポリシーを使用して、プル要求のレビュー担当者の最小人数を設定したり、コードベースの特定の部分に加えられた変更をレビューするように特定のユーザーに要求したりすることもできます。

ブランチ ポリシー – ゲート ビルド

Git プロジェクトで、ブランチ ポリシーを設定することにより、コードをブランチに送信できるようになる前に、ビルドの成功を要求できるようになりました。 ビルド ポリシーを有効にするには、構成済みブランチに変更を送信するためにプル要求を使用する必要があり、プル要求の完了は、構成済みビルドが成功するとゲートされます。

ブランチ ポリシー – コード レビュー

Git プロジェクトで、ブランチ ポリシーを設定することにより、ブランチに送信されるコードに対してコード レビューを要求できるようになりました。 ブランチに対してコード レビュー ポリシーを有効にすると、プル要求を使用して、すべてのコードをそのブランチに送信する必要があります。 ポリシーには、最小限のコード レビュー担当者を必要とするだけでなく、特定のパスやファイルの種類に対して専用レビュー担当者を必要とするオプションが用意されています。

ブランチの履歴 (プッシュおよびプル要求)

Web ポータルで、コードの下にある [履歴] ハブが更新され、Git プロジェクトの新しいビューがサポートされました。 新しい [ブランチの更新] ビューには、特定のブランチのすべての更新が表示されます。コミットがプッシュおよびプル要求のアクティビティ別にグループ化されます。 このビューにより、Git リポジトリが時間の経過と共にどのように更新されるかに関する新しい洞察が開発者に提供され、履歴からプル要求までの追跡機能が提供されます。

Git プロジェクトの Web 履歴ビュー

コード履歴ハブに新しいビューが追加されました。[ブランチの更新] です。 このビューは、Git プロジェクトに対してのみ使用でき、特定のブランチに対するすべての更新が表示されます。コミットがプッシュおよびプル要求のアクティビティ別にグループ化されます。 また、このビューにより、Git リポジトリが時間の経過と共にどのように更新されるかに関する新しい洞察が開発者に提供され、履歴からプル要求までの追跡機能が提供されます。

クイック コード編集

今回のリリースでは、Web ブラウザーから直接、バージョン コントロールでファイルをすばやく編集し、これらの変更をサービスにそのままコミットする機能が追加されました。 ソース ファイルを参照するときに、ファイルを編集モードにする [編集] コマンドを使用できるようになりました。 変更はインラインで行うことができ、色の設定と書式設定もサポートされています。 [保存] コマンドをクリックしたらすぐに、変更を加えた新しいコミットまたは変更セットを作成します。 変更をコミットする前に差分ビューを使用すると、何を変更しようとしているのかを正確に確認できます。 ファイルが Markdown または HTML ファイルの場合は、変更内容を保存する前にプレビューすることもできます。

ファイルを編集できるだけでなく、Web から直接ファイルを追加、削除、名前変更する機能も追加されました。 新しいファイルを 1 つ以上追加するには、リポジトリ内のフォルダーを右クリックして、

[ファイルの追加] を選択し、チェックインまたはコミットのコメントを入力すると、準備が整います。 ファイルの名前変更や削除を行うためだけに、コードベース全体をダウンロードしなければならない時代は終わりました。

また、新しい編集機能が [ようこそ] ハブに表示され、プロジェクトのドキュメントを簡単に作成できます。 README.md ファイルがない場合は、テンプレート ガイドから開始して、独自のファイルをコミットできます。

また、構文に従って、既存の (または新規の) マークダウン ファイルへのリンクを作成する機能を使用できるようになりました。 リンクをクリックすると、新しいファイルを編集およびコミットできる (wiki スタイル) ため、ページが存在しなくても心配する必要はありません。

これらの新機能を使えば、プロジェクト ドキュメントを簡単かつ迅速に作成および編集できます。

クイック コード編集について詳細を確認してください。

履歴コントロール

ディスカッションが読みやすくなるように履歴コントロールが最適化されました。 具体的には、表示したいディスカッションによりすばやくアクセスできるように、必要な垂直方向の領域が縮小されました。これは、機能を減らすことなく行われました。

フォルダーの履歴表示

ソリューション エクスプローラー、[変更] ページ、または [コミットの詳細] ページで任意のフォルダーを右クリックして、そのフォルダー内のファイルに対する変更の履歴を取得できるようになりました。

ビルド オートメーション システム

Team Foundation 2015 に新しいビルド オートメーション システムが含まれました。 新しいビルド オートメーション システムの詳細については、[ビルド] タブにあるメッセージ ヘッダーのリンクをクリックしてください。

チーム プロジェクトの名前変更

チーム プロジェクトの名前を変更する機能を使用できるようになりました。 すべてのバージョン コントロール パス、作業項目、クエリ、およびその他のチーム プロジェクトの成果物が更新され、新しい名前が反映されます。 チーム プロジェクトの名前は複数回変更でき、古い名前を再利用することもできます。

詳しくは、チーム プロジェクトの名前の変更に関するページを参照してください。

REST API

これは、REST API をオンプレミスの TFS に取り入れた最初のリリースです。 JSON REST API を使用すると、Windows、Android、iOS、Node.js など、ほぼすべてのデバイス、プラットフォーム、またはテクノロジ スタックから、Team Foundation Server を簡単に操作できます。 作業項目の作成とクエリ、ビルドのキュー作成、最新のチーム ルーム メッセージの取得、ソース コードへのアクセス、ほぼすべてのチームまたはコード管理タスクの実行を行うことができます。

サービス フック

サービス フックを使用すると、Team Foundation Server でイベントが発生したときに、アプリやサービスですぐに通知を受け取ることができます。 サービス フックを使用すると、完了したビルド、コミットまたはチェックイン、作業項目の変更などの変更があるかどうかをアプリまたはサービスでチェックするための継続的なポーリングを回避できます。 Team Foundation Server から別のサービスに変更を通知し、両方のサービスを同時に使用できるようにする強力な統合シナリオを作成できるようになりました。 プロジェクト管理の新しいハブとしてサービス フックを見つけることができます。

サービス フックは次のように動作します。特定の種類のイベントが発生したときに、サービス フック サブスクリプションによって、対象の外部サービスに対してどのアクションを実行するかが制御されます。 メール アラート サブスクリプションと同様に、サービス フック サブスクリプションは、それを作成したユーザーに関連付けられます。 イベントが発生し、サービス フックから構成済みのサブスクリプションをイベントに照合しようとすると、そのサブスクリプションを作成したユーザーに、そのイベントに関連付けられているリソースへのアクセス許可があることを保証するためにアクセス許可チェックが実行されます。 たとえば、あるユーザー (おそらくはプロジェクト管理者) が、すべての "作業項目作成済み" イベントでトリガーされるサービス フック サブスクリプションを作成します。 新しい作業項目が、このユーザーがアクセス権を持っていない区分パスの下に作成されると、アクセス許可チェックによってサブスクリプションの照合が禁止され、このサブスクリプションを介して外部通知の送信が回避されます。

ただし、サービス フックを使用すると、外部サービス (Trello や Campfire など) と簡単に統合できるため、サブスクリプションの作成者がアクセスできるデータを、同じレベルのアクセス権を持たない他のユーザーが使用できないようにする必要があります。 たとえば、すべての "コード プッシュ" イベントを Campfire ルームに送信するように定義されているサブスクリプションでは、そのイベントに関連付けられているリポジトリへのアクセス権を持たない (が、Campfire ルームへのアクセス権があるために情報を表示できる) ユーザーに情報が誤って開示される可能性があります。

マージ パフォーマンスの向上

マージ パフォーマンスが向上しました。大規模なリポジトリで顕著に現れます。

複数のテスト担当者を割り当てて、テスト用に招待する

同じ一連のテスト ケースを実行するために複数のサインオフ所有者の招待が必要なシナリオがある場合、複数のテスト担当者を 1 つのテスト スイートに割り当てることができるようになりました。 そうすることで、テスト スイート内の各テスト ケースが選択され、テスト スイートに追加するテスト担当者ごとにテストが作成されます。 テストの実行を招待するメールを送信することもできます。 テスト担当者がメール内の [テストの表示] リンクをクリックすると、テスト計画が開き、フィルター処理されて、そのテスト担当者に割り当てられたテストの一覧が表示されます。

スイート内のテストを実行するすべてのテスト担当者を選択する

クラウド ベースのロード テスト

新しいビルド システムの一部としてクラウドベースのロード テストを実行する新機能について紹介します。 2 つのパーツ、クラウドベースのロード テストとクラウドベースの Web パフォーマンス テストがあります。

list-style-type: なし。

  • クラウドベースのロード テストを使用すると、既存のロード テスト プロジェクトを CI/CD パイプラインの一部として実行できます。
  • クラウドベースの Web パフォーマンス テストを使用して、アプリの URL に対する単純なロード テストを実行します。基本的なロード テスト パラメーターはタスク自体に構成されます。

クラウド ベースのロード テスト

自動テスト

新しいビルド システムの一部として、ビルド マシンで単体テストを実行する、リモート マシンで機能のオートメーションを実行する、テスト結果を参照する新機能を紹介します。 詳細については、こちらのブログを参照してください。

現在、Visual Studio テスト (VSTest タスク) と、テスト エージェントを使用する Visual Studio テスト (VSTest リモート タスク) の 2 つのテスト タスクがあります。

  • VSTest タスクにより、テストはビルド マシンでローカルに実行されます。通常、このタスクでは単体テストのみを実行します。
  • VSTest リモート タスクにより、テストはテスト エージェントを使用してリモート マシンで分散して実行されます。機能、単体テスト、または UI テストのいずれかを実行できます。

さらに、[マシン] ハブと、[テスト] ハブの [実行] タブを紹介します。

  • [マシン] ハブ。 [マシン] ハブを使用して、リモート マシンを作成および管理します。
  • [実行] タブ。[テスト] ハブのこのタブは、システム内のすべてのテスト結果に対して 1 つのリポジトリとして機能します。 VSTest および VSTestRemote タスクから自動テストの結果を参照できるだけでなく、XAML ビルドやビルド-デプロイ-テスト ワークフローなどの従来のワークフローからも参照できます。 また、REST API を利用してテスト結果を公開することで、テスト結果の公開をカスタム タスクに統合することを選択できます。 現在、[実行] ハブでは、テスト実行とテスト結果に対するクエリの実行、テスト エラーへの所有者の割り当て、分析の追跡、バグの提出がサポートされています。

API 動作の変更

IProcessTemplates.AddUpdateTemplate メソッドの API の名前、説明、およびメタデータ引数の値は、zipFileName に指定されたプロセス テンプレート データによって上書きされるようになりました。 この変更の理由は、ZIP ファイルの内容と、API にパラメーターとして渡されるものとの間で競合が発生しないようにするためです。

IProcessTemplates.AddUpdateTemplate メソッド

次のスクリーンショットは、これらのプロパティが ProcessTemplate.xml に定義されている場所を示しています。

xml テンプレートに定義されているプロパティ

バグ修正と既知の問題

今回のリリースのテクノロジの改善、バグの修正、既知の問題の詳細については、次の KB 記事をご覧ください。

ご感想をお聞かせください。

皆様のご意見をお待ちしております。 開発者コミュニティで問題を報告して追跡し、スタック オーバーフローでアドバイスを得ることができます。 Microsoft に優先的に取り組んで欲しいアイデアがある場合は、Developer Community にアクセスして、アイデアを追加するか、既存のアイデアに投票してください。

ページのトップへ