Team Foundation Server 2018 RC1 リリース ノート

Last Update: 2017/09/01

この記事では、Team Foundation Server 2018 RC1 の最新リリースに関する情報を紹介します。 ボタンをクリックしてダウンロードします。

Team Foundation Server の最新版のダウンロード

Team Foundation Server 2018 の詳細については、Team Foundation Server の要件と互換性に関するページを参照してください。


フィードバック

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


リリース日: 2017 年 8 月 30 日

概要: TFS 2018 RC1 での Team Foundation Server の更新

Team Foundation Server 2018 に新しい価値をたくさん追加しました。 主な特徴:

概要: このリリースの新機能

このリリースで削除された機能:


詳細: このリリースの新機能

作業項目のトラッキング

Web でのプロジェクト作成ウィザード

Web アクセスからチーム プロジェクトを作成するためのエクスペリエンスを機能強化しました。 Visual Studio クライアントでチーム プロジェクトを作成するときに使用できる機能の多くが含まれるようになっています。 Web インターフェイスを使う利点は、一致するバージョンの Visual Studio が必要ないことです。 Visual Studio と Web バージョンの違いは、Web バージョンでは SSRS でレポートがプロビジョニングされないことです。 チーム プロジェクト作成の Web バージョンを使用していた場合は、アプリケーション層で tfsconfig コマンドを実行して SSRS レポートをプロビジョニングまたは更新できます。 詳しくは、「AddProjectReports」をご覧ください。

Web でのプロセス テンプレート マネージャー

TFS 2018 では、Web アクセスを使ってプロセス テンプレートをアップロードできます。 Web インターフェイスは、プロセス テンプレートとやり取りするために Visual Studio の正しいバージョンをインストールする必要がないため、はるかに簡単なエクスペリエンスです。 Visual Studio 2017 Update 4 以前ではまだ [プロセス テンプレート マネージャー] ダイアログが表示されますが、Web インターフェイスを使うことをお勧めします。 Visual Studio 2017 Update 5 以降では、Web に自動的にリダイレクトされます。

モバイル作業項目フォーム

完全なエンドツーエンドのエクスペリエンスは、作業項目用の最適化されたルック アンド フィールを含み (図 1)、自分に割り当てられた項目、フォローしている項目、アクセスした項目、最近編集した項目を携帯電話から操作する簡単な方法を提供します。

モバイル作業項目のクエリ

(図 1) モバイル作業項目のクエリ

わかりやすい表示だけでなく、このエクスペリエンスはすべてのフィールドの種類に対する最適化されたコントロールをサポートします (図 2)

モバイル作業項目フォーム

(図 2) モバイル作業項目フォーム

新しいモバイル ナビゲーション (図 3) では、ユーザーは TFS の他のモバイル対応部分にアクセスでき、他のハブを使う必要があるときは完全なデスクトップ サイトに戻ることができます。

モバイル ナビゲーション

(図 3) モバイル ナビゲーション

バックログ、かんばんボード、スプリント、およびクエリのフィルター処理

すべての作業項目追跡グリッド エクスペリエンス (クエリ、バックログ、かんばんボード、スプリント バックログ、およびテスト ケース管理) で、共通の一貫したフィルター処理コンポーネントが使われるようになりました (図 4)。 表示されている列にキーワード フィルターを適用して、タグを選択するだけでなく、作業項目の種類、状態、担当者でフィルター処理を行って、探している作業項目をすばやく取得することもできます。

クエリでのフィルター処理

(図 4) クエリでのフィルター処理

かんばんカードの空のフィールドを表示するように展開する

カードにフィールドを追加した後、ボードの設定で__空のフィールドを非表示にする__ (図 5) ことで不必要なフィールドをボードから除去できます。 この機能の欠点は、空のフィールドを非表示にした後、作業項目フォームを開くことでしかフィールドを更新できなかったことです。 かんばんカードの新しい展開オプションを使うと、ボードで空のフィールドを非表示にしても、1 回のクリックでカードの特定のフィールドにアクセスして更新できます。 カードをポイントし、カードの下部にある下向きのシェブロンを使って、非表示フィールドを更新します。

非表示フィールド

(図 5) かんばんカードの非表示フィールド

カードの下部にある下向きのシェブロンをクリックして、フィールドを更新します (図 6)

非表示フィールドの更新

(図 6) かんばんカードでの非表示フィールドの更新

作業項目保存ブロック拡張機能

作業項目フォームのカスタム コントロール、グループ、およびページで、作業項目の保存をブロックし、作業項目フォームを保存する前に、データを検証し、必須情報が入力されていることを確認できるようになりました。

バージョン管理

フォーク

TFS 2018 では Git フォークのサポートが追加されます (図 7)。 フォークはリポジトリのサーバー側コピーです。 フォークを使うと、直接コミット アクセスを与えることなく、広範なユーザーにリポジトリへの寄与を許可できます。 代わりに、ユーザーはリポジトリの自分のフォークに作業をコミットします (図 7)。 これにより、中央リポジトリに変更を受け入れる前に、プル要求で変更を確認できます。

Git フォーク

(図 7) Git フォーク

TFVC リポジトリの Web 編集をオフに設定

TFVC を使うチームは、Visual Studio のチェックイン ポリシーを使ってコードの品質を確認することがよくあります。 ただし、チェックイン ポリシーはクライアントで適用されるため、Web で編集されたコードは同じポリシーの対象になりません。

複数のユーザーから、Web 編集を無効にしてチェックイン ポリシーをバイパスする変更を防ぐ方法を求められました。 プロジェクト/リポジトリ ベースで TFVC の Web 編集 (追加、削除、名前変更、編集) をオフにする方法を設けました。

Web 編集を禁止するには、[ファイル] ページから [設定][バージョン管理] に移動します (図 8)。 ツリーで TFVC リポジトリをクリックし、[オプション] ピボットに移動して、[Enable web-editing for this TFVC repository](この TFVC リポジトリの Web 編集を有効にする) をオフにします。 既定では、Web 編集は有効になっています。 注: __プロジェクト概要ページ__からの README の編集には影響ありません。

Web 編集を無効にする

(図 8) Web 編集を無効にする

Web 編集が無効になっているプロジェクトで Web 編集を試みると、Web 編集が許可されないことが通知されます (図 9)

Web 編集禁止ダイアログ

(図 9) Web 編集禁止ダイアログ

この機能は、関連する提案に基づいて開発されました。

古いブランチを識別する

不要になったブランチを削除することによってリポジトリをクリーンに維持すると、チームは重要なブランチを探して、適切な細分性でお気に入りを設定できます。 ただし、リポジトリに多数のブランチがある場合、非アクティブであり削除できるブランチを見極めるのが難しいことがあります。 "古い" ブランチ (3 か月より古いコミットをポイントしているブランチ) を識別しやすくしました。 古いブランチを表示するには、[ブランチ] ページの [古い] ピボットに移動します (図 10)

古いブランチ

(図 10) 古いブランチ

削除されたブランチを検索して再作成する

サーバーからブランチを誤って削除したとき、何が起きたのか明らかにするのが難しい場合があります。 削除されたブランチを検索し、いつ、だれが削除したのかを確認して、必要であれば再作成できるようになりました。

削除されたブランチを検索するには、ブランチ検索ボックスにブランチの完全な名前を入力します。 そのテキストに一致する既存のブランチが返されます。 削除されたブランチの一覧で完全に一致するものを検索するオプションもあります。 リンクをクリックして削除されたブランチを検索します (図 11)

削除されたブランチを検索する

(図 11) 削除されたブランチを検索する

一致が見つかった場合、だれが、いつ削除したかが表示されます。 ブランチを復元することもできます (図 12)

削除されたブランチを復元する

(図 12) 削除されたブランチを復元する

ブランチを復元すると、最後にポイントされていたコミットで再作成されます。 ただし、ポリシーとアクセス許可は復元されません。

プレフィックスで始まるブランチでコミットを検索する

すべてのブランチにプレフィックスが設定された階層形式のブランチ構造がある場合、この機能は、そのプレフィックス テキストで始まるすべてのブランチでコミットを検索するのに役立ちます。 たとえば、"dev" というプレフィックスが付いたすべてのブランチでコミットが行われたかどうかを確認する場合は、検索ボックスに「dev」と入力し、[Search in branches starting with "dev"]("dev" で始まるブランチ内を検索する) を選びます (図 13)

コミットを検索する

(図 13) コミットを検索する

コミット詳細ページのリッチになったプル要求の吹き出し

コミット詳細ページのプル要求の吹き出しに、診断の向上に役立つ関連情報がより多く表示されるようになりました (図 14)。 また、いずれかのブランチでコミットを行った最初のプル要求と、既定のブランチに関連付けられているプル要求が、吹き出しに表示されるようになりました。

プル要求の吹き出し

(図 14) プル要求の吹き出し

コードのツリー ビューをフィルター処理する

目的のファイルを探すのに、コミットが変更した可能性のあるすべてのファイルをスクロールする必要がなくなりました。 コミット詳細、プル要求、シェルブセットの詳細、変更セットの詳細の各ページのツリー ビューで、ファイルとフォルダーのフィルター処理がサポートされるようになりました。 これはスマート フィルターであり、フォルダー名でフィルター処理するとフォルダーの子ファイルが表示され、ファイル名でフィルター処理するとファイルの折りたたまれたツリー ビューでファイル階層が表示されます。

コミット ツリー (図 15) および (図 16) のファイルまたはフォルダー検索フィルター:

ファイルまたはフォルダーを検索する

(図 15) ファイルまたはフォルダーを検索する

フィルター処理されたビュー

(図 16) コミット ツリーのフィルター処理されたビュー

[ブランチの更新] ページが [Pushes](プッシュ) になった

[ブランチの更新] ページには大きな価値があります。 ただし、このページは [履歴] ハブでピボットとして非表示になっていました。 ブランチの更新に関するページは、[コード] に、[コミット][ブランチ][タグ][プル要求] と共に、[Pushes](プッシュ) という名前でハブとして表示されるようになります (図 17)。 プッシュ ページの新しい URL は、<TFS サーバー URL>/<プロジェクト名>/_git/<リポジトリ名>/pushes です。 古い URL も引き続き機能します。

プッシュ ページ

(図 17) プッシュ ページ

同時に、ハブにはコミットだけが表示されるようになったため、[履歴] ハブは [コミット] (図 18) に名前を変更されました。 コミット リスト ビューではポイントしたときにのみ詳細な時刻が表示されるためコミット関連のトラブルシューティングが難しいというフィードバックをいただきました。 現在は、インスタンスのコミット リスト ビューに dd/mm/yy hh:mm の形式で日時が表示されるようになっています。 コミット ページの新しい URL は、<TFS サーバー URL>/<プロジェクト名>/_git/<リポジトリ名>/commits です。 古い URL も引き続き機能します。

コミット ページ

(図 18) コミット ページ

ファイルからコミットに移動したときにファイル名が維持される

[コード] ハブの [ファイル] ピボットでディレクトリをフィルター処理して特定のファイルを表示した後、[履歴] ピボットに切り替えた場合、コミットで 1,000 より多くのファイルが変更されているとファイル名が維持されないというフィードバックがありました。 そのため、より多くのファイルを読み込み、内容をフィルター処理してファイルを検索する必要があり、生産性に影響がありました。 通常、開発者は同じディレクトリで作業しており、変更をトレースしても作業ディレクトリが維持されることを望みます。 このバージョンでは、コミットで変更されたファイルの数に関係なく、[コード] ハブのピボット間を移動してもファイル名が維持されるようになりました。 つまり、目的のファイルを検索するのに、[さらに読み込む] をクリックする必要はありません。

Git タグを表示する

リポジトリのすべてのタグを [タグ] ページで見ることができます (図 19)。 すべてのタグをリリースとして管理している場合、ユーザーはタグ ページにアクセスしてすべての製品リリースをまとめて見ることができます。

Git タグを表示する

(図 19) Git タグを表示する

ここでは、軽量タグと注釈付きタグを簡単に区別できます。注釈付きタグには関連するコミットと共にタガーと作成日が表示されるのに対し、軽量タグにはコミット情報のみが表示されます。

Git タグを削除する

リモート リポジトリからタグを削除したい場合があります。 タグ名を間違えたり、正しくないコミットにタグを付けたりした場合が想定されます。 [タグ] ページでタグのコンテキスト メニューをクリックして [タグの削除] を選ぶことで、Web UI からタグを簡単に削除できます (図 20)

注: リモート リポジトリ上のタグの削除は慎重に行う必要があります。

Git タグを削除する

(図 20) Git タグを削除する

Git タグのフィルター処理

古いリポジトリでは、時間とともにタグの数が大幅に増えることがあります。また、タグが階層構造で作成されたリポジトリでは、タグの検索が困難な場合があります。

タグ ページで探しているタグが見つからない場合、[タグ] ページ上部のフィルターを使ってタグ名を簡単に検索できます (図 21)

Git タグのフィルター処理

(図 21) Git タグのフィルター処理

Git タグのセキュリティ

このバージョンでは、リポジトリのユーザーにきめ細かいアクセス許可を付与してタグを管理できます。 このインターフェイスからは、タグの削除やタグの管理のアクセス許可をユーザーに付与できます (図 22)

Git タグのセキュリティ

(図 22) Git タグのセキュリティ

Git タグについて詳しくは、Microsoft DevOps のブログをご覧ください。

プル要求完了時に作業項目を自動的に完了させる

PR に作業項目をリンクしている場合、すべてのものを最新に保つことだけが簡素化されました。 このバージョンでは、PR を完了するとき、PR が正常にマージされた後で、リンクされた作業項目を自動的に完了させることができます (図 23)。 ポリシーを使っている場合、PR をオート コンプリートに設定すると、同じオプションが表示されます。 PR が完了した後で忘れずに作業項目に再度アクセスして状態を更新する必要はなくなりました。 この処理は自動的に行われます。

リンクされた作業項目を完了する

(図 23) リンクされた作業項目を完了する

プッシュ/新規イテレーションで投票をリセットする

PR でより厳密な承認ワークフローを選んでいるチームは、新しい変更がプッシュされるときに、オプトインして投票をリセットできるようになりました (図 24)。 新しい設定は、[レビュー担当者の最小数が必要です] ポリシーのオプションです。

投票の設定をリセットする

(図 24) 投票の設定をリセットする

このオプションをオンにすると、PR のソース ブランチが更新されると常に、すべてのレビュー担当者のすべての投票がリセットされます。 PR タイムラインは、このオプションの結果として投票がリセットされると常にエントリを記録します (図 25)

タイムラインでの投票のリセット

(図 25) タイムラインでの投票のリセット

ファイル名でプル要求ツリーをフィルター処理する

プル要求での特定のファイルの検索がこれまでより簡単になりました。 [ファイル] ビューの新しいフィルター ボックスでは、ツリー ビューのファイル一覧をフィルター処理できます (図 26)

プル要求のファイルまたはフォルダーを検索する

(図 26) プル要求のファイルまたはフォルダーを検索する

フィルターはプル要求内のファイルのパスの任意の部分と一致するので、フォルダー名、部分的なパス、ファイル名、または拡張子で検索できます (図 27)

結果を検索する

(図 27) 結果を検索する

プル要求のコメントのフィルター オプションの追加

プル要求の概要とファイル ビューの両方で、コメントのオプションが同じになりました (図 28)。 自分が参加したディスカッションだけをフィルターで抽出することもできます。

PR コメントのフィルター処理

(図 28) PR コメントのフィルター処理

プル要求の詳細でコードのコメントの元の差分を表示する

コメントで参照されているコードを変更した後 (多くの場合、要求された変更を行ったとき)、PR コメントを理解するのが難しい場合があります (図 29)

元の差分を表示する

(図 29) 元の差分を表示する

このような場合、更新番号の付いたバッジが表示されるようになり、それをクリックすると、コメントが最初に作成されたときのコードを見ることができます (図 30)

更新バッジ

(図 30) 更新バッジ

折りたたみ可能なプル要求のコメント

コードのレビューはプル要求のエクスペリエンスの重要な部分であるため、レビュー担当者がコードに簡単に集中できる新機能が追加されました。 コード レビュー担当者は、新しいコードを初めてレビューするときに、簡単にコメントを非表示にして邪魔にならないようにできます (図 31)

コメントを非表示にする

(図 31) コメントを非表示にする

コメントを非表示にすると (図 32)、ツリー ビューに表示されなくなり、ファイル ビューのコメント スレッドが折りたたまれます。

折りたたまれたコメント

(図 32) 折りたたまれたコメント

折りたたまれたコメントは、余白のアイコンをクリックして簡単に展開でき、もう一度クリックすると再び折りたたむことができます。 ツールヒントを使うと (図 33)、スレッド全体を表示することなく、コメントを簡単に見ることができます。

折りたたまれたコメントのツールヒント

(図 33) 折りたたまれたコメントのツールヒント

プル要求の説明とコメントのタスク一覧

PR を準備するとき、またはコメントを追加するときに、追跡したいことの短いリストがある場合がありますが、結局、テキストを編集したり、複数のコメントを追加したりすることが必要になります。 軽量タスク一覧は、PR 作成者やレビュー担当者が、説明または単一の統合されたコメントで、ToDo リストの進行状況を追跡できる優れた方法です。 [マークダウン] ツールバーをクリックして始めるか、または選択したテキストに書式を適用します (図 34)

タスク一覧ツールバー

(図 34) タスク一覧ツールバー

タスク一覧を追加した後は (図 35)、ボックスをオンにするだけで、項目を完了としてマークできます。 これらは、マークダウン内で [ ] および [x] と表されて、コメントに格納されます。 詳しくは、マークダウンのガイダンスをご覧ください。

タスク一覧

(図 35) タスク一覧

プル要求に "いいね" コメントを付ける機能

PR コメントの支持を、__いいね__ボタンのシングル クリックで示します (図 36)。 ボタンをポイントすると、コメントに "いいね" をしたすべてのユーザーのリストを見ることができます。

プル要求のコメントに

(図 36) プル要求のコメントに "いいね!" を付ける

提案を承認するときのワークフローの機能強化

プル要求で__オート コンプリート__ オプション (図 37) を使うのは生産性向上のためによい方法ですが、レビュー担当者とのアクティブなディスカッションを途中で中止するのはよくありません。 このようなディスカッションをさらに促進するため、__承認と提案__の投票では、プル要求にオート コンプリートが設定されているというメッセージが表示されるようになりました。 ユーザーは、フィードバックを読むことができるようにオート コンプリートをキャンセルすることも、オート コンプリートを設定したままにして、すべてのポリシーが満たされた時点でプル要求が自動的に完了されるようにすることもできます。

[オートコンプリートをキャンセルする] ダイアログ

(図 37) [オートコンプリートをキャンセルする] ダイアログ

Git 通知のパス フィルター処理のサポート

リポジトリ内のすべてのフォルダーについての通知を受け取る代わりに、チーム メンバーがプル要求を作成したとき、または関心のあるフォルダーでコードをプッシュしたときにのみ、通知を受け取ることができます。 Git プッシュ要求または Git プル要求のカスタム メール通知サブスクリプションを作成すると、フォルダー パスでこれらの通知をフィルター処理するための新しいオプションが表示されます (図 38)

通知のパス フィルター処理

(図 38) 通知のパス フィルター処理

プル要求ワークフローの優れたメール テンプレート

プル要求のメール通知が、明確で簡潔で実用的なように更新されました (図 39)。 件名行は PR タイトルとリポジトリ名などのセカンダリ情報で始まり、ID は末尾に移動されています。 作成者名が件名に追加され、PR を作成したユーザーでルールやフィルターを簡単に適用できるようになっています。

通知メール本文のテンプレートは更新されており、最初に通知の送信理由がまとめて示され、その後に重要なメタデータ (タイトル、ブランチ名、説明) とメインのアクション呼び出しボタンが表示されるようになっています。 レビュー担当者、ファイル、コミットなどの他の詳細情報は、メールのさらに下の方に記載されます。

改良されたメール テンプレート

(図 39) 改良されたメール テンプレート

ほとんどの通知では、アクション呼び出し (図 40) をクリックすると Web のプル要求が表示されます。 ただし、特定のコメントに関する通知を受け取るときは、アクション呼び出しは__そのコメントに直接リンク__しており、コードとコンテキストの前の会話を簡単に見つけることができます。

メールのアクション呼び出し

(図 40) メールのアクション呼び出し

プル要求のステータスの拡張性

ブランチ ポリシーの使用は、コードの品質を向上させる優れた方法です。 ただし、これらのポリシーは、VSTS によってネイティブに提供される統合のみに制限されています。 新しい PR Status API とそれに対応するブランチ ポリシーを使うと、サード パーティのサービスでもネイティブな VSTS 機能と同じように PR ワークフローに参加できます。

サービスがプル要求を Status API に発行すると、新しい [ステータス] セクションの __PR 詳細__ビューにすぐに表示されます (図 41)。 ステータス セクションには、説明が表示され、サービスによって提供される URL へのリンクが作成されます。 ステータスのエントリでは、Web 拡張機能によって追加される新しいアクションに合わせて拡張可能なアクション メニュー ([...]) もサポートされています。

PR ステータス セクション

(図 41) PR ステータス セクション

ステータスだけでは PR の完了はブロックされません。これを行うのはポリシーです。 PR ステータスを発行した後は、ポリシーを構成することができます。 ブランチ ポリシーのエクスペリエンスで、外部サービスからの承認を要求する新しいポリシーを使用できます。 [+ サービスの追加] を選んでプロセスを開始します (図 42)

新しいポリシーを追加する

(図 42) PR 新しいポリシーを追加する

ダイアログで、一覧からステータスを発行するサービスを選び、目的のポリシー オプションを選びます (図 43)

ステータスのポリシーを設定する

(図 43) PR ステータスのポリシーを設定する

ポリシーがアクティブになると、ステータスが [ポリシー] セクションの [必須] または [任意] のどちらか該当する方に表示され、必要に応じて PR 完了が適用されます。

Status API の詳細を学習し、自分で試してみるには、ドキュメントサンプルをご覧ください。

Wiki

各プロジェクトは独自の Wiki をサポートするようになりました (図 44)。 チーム メンバーによるプロジェクトの理解、使用、寄与を支援するページを簡単に作成できます。

Wiki ページ

(図 44) PR Wiki ページ

新しい Wiki に含まれる主要な機能は次のとおりです。

  • マークダウン構文を使用する簡素化された編集エクスペリエンス。
  • 新しいページでは、タイトルを指定し、コンテンツを追加できます。 (図 45)タイトル Wiki

    (図 45) PR タイトル Wiki

  • マークダウンでの HTML タグのサポート (図 46)

Wiki の HTML タグ

(図 46) PR Wiki の HTML タグ

  • マークダウン フォルダーでのイメージのサイズの簡単な変更 (図 47)

イメージのサイズ変更

(図 47) PR イメージのサイズ変更

  • 並べ替え、親の再設定、ページ管理が可能な強力なページ管理ウィンドウ。
  • 大規模な Wiki についてタイトルでページをフィルター処理する機能 (図 48)

Wiki メニュー

(図 48) PR Wiki メニュー

詳しくは、Wiki の概要に関するページをご覧ください。

  • Wiki を使用していて、意図しない変更を保存してしまうことがあります。 リビジョンの詳細に移動して [元に戻す] ボタンをクリックすることで、Wiki ページのリビジョンを戻すことができるようになりました (図 49)

Wiki の元に戻すボタン

(図 49) PR Wiki の元に戻すボタン

壊れたリンクからの Wiki ページの作成 Wiki を作成していると、存在しないリンクを含む目次を Wiki ページに作成した後 (図 50)、 これらのリンクをクリックして実際のページを作成することがあります。 従来、このようなシナリオでは、リンクが壊れていること、またはページが存在しないことを示す警告を表示していました。 現在は、これを Wiki の主流のシナリオとして処理し、ページの作成を許可するようになりました。

Wiki ページを作成する

(図 50) PR Wiki ページを作成する

Marketplace での Wiki 拡張機能は使われなくなりました。 Wiki 拡張機能を既に使っている場合は、こちらの移行ツールを使って、Wiki ページを新しい Wiki に移行できます。 詳しくは、migrate your existing wiki pages to the new Wiki (既存の Wiki ページの新しい Wiki への移行) に関する記事をご覧ください。

パッケージの管理

パッケージ管理のエクスペリエンスの更新

パッケージの URL が、GUID ではなく、パッケージ名とバージョンで動作するようになりました。 これにより、パッケージの URL を簡単に手作りできます (図 50)。 形式は次のとおりです。<TFS サーバー URL>/<プロジェクト|チーム>/_packaging?feed=<フィード>&package=<パッケージ>&version=<バージョン>&protocolType=<NuGet|Npm|Maven>&_a=package

パッケージ URL

(図 51) PR パッケージ URL

UserVoice でのこちらの提案に対応し、パッケージが削除されたバージョンを、すべてのフィード ユーザーに対して非表示にできるようになりました (図 52) (取り消し線付きのパッケージも表示されません)。

削除されたパッケージを非表示にする

(図 52) 削除されたパッケージを非表示にする

パッケージ詳細ページで実行できるすべてのアクションを、パッケージ一覧のコンテキスト メニューから実行できるようになりました。

パッケージ一覧の新しい [Last pushed](最終プッシュ日時)(図 53) には日付が表示され、最近更新されたパッケージが簡単にわかります。

最終プッシュ日時列

(図 53) 最終プッシュ日時列

Maven パッケージ

TFS 2018 から、Maven 成果物のホスティングがサポートされるようになりました (図 54)。 Maven 成果物を使うと、Java 開発者はコードとコンポーネントを簡単に共有できます。 パッケージ管理を使った Maven 成果物の共有方法については、getting started guide (開始ガイド) のページをご覧ください。

Maven パッケージ

(図 54) Maven パッケージ

新しい統合 NuGet タスク

NuGet の復元NuGet パッケージャーNuGet パブリッシャー__の各タスクが、__NuGet ビルド タスクにまとめられ、他のビルド タスク ライブラリと整合するようになりました。既定では、新しいタスクは NuGet 4.0.0 を使います。 それに従い、古いタスクは非推奨になったため、時間があるときに新しい NuGet タスクに移行することをお勧めします。 この変更は、結合されたタスクを使うことによってのみアクセスできる、以下で説明する機能強化の流れと一致するものです。

この作業の一環として、PATH で使用可能な NuGet のバージョンを管理し、新しい NuGet タスクによって使われる、新しい NuGet Tool インストーラー タスクもリリースされました。 したがって、新しいバージョンの NuGet を使うには、ビルドの先頭に NuGet Tool インストーラー タスクを追加するだけで済みます (図 55)

Nuget タスク

(図 55) NuGet タスク

NuGet の [Allow duplicates to be skipped](重複のスキップを許可する) オプション

多くの NuGet ユーザーから、パッケージのセットを生成しても、その一部しか更新しないことがある (したがって、バージョン番号が更新される) という指摘がありました。 NuGet ビルド タスクの新しい [Allow duplicates to be skipped](重複のスキップを許可する) オプションを使うと、タスクは、同じバージョンが既に使われている VSTS/TFS フィードにパッケージのプッシュを試みる場合に続行できます。

npm ビルド タスクの更新

Windows、Linux、Mac のどれで npm プロジェクトをビルドするときでも、新しい NPM ビルド タスクはシームレスに動作します。 また、npm installnpm publish の両方を簡単に行うことができるように、タスクの編成を変更しました。 install および publish について、プロジェクトの .npmrc ファイルに列記されているレジストリの資格情報をサービス エンドポイントに安全に保存できるように、資格情報の取得を単純化しました。 または、VSTS/TFS フィードを使っている場合は、フィードを選択できるようにして、その後ビルド エージェントによって使われる必要な資格情報を含む .npmrc が生成されます。

Maven が認証されたフィードをサポートするようになった

NuGet および npm とは異なり、Maven のビルド タスクはこれまで認証されたフィードで動作しませんでした。 VSTS/TFS フィードを簡単に使用できるように、Maven タスクが更新されました (図 56)

dotnet タスク

(図 56) dotnet タスク

dotnet タスクが認証されたフィード、Web プロジェクトをサポートする

dotnet タスクの次のメジャー バージョン (2.x) では、フィードバック要求の多くに対応し、しばらくの間追跡した一連のバグが修正されます。

  1. 最初に、dotnet はパッケージ管理などの認証されたパッケージ ソースをサポートするようになったので、プライベート パッケージ ソースからパッケージを復元するために NuGet タスクを使う必要はなくなりました。
  2. [プロジェクトへのパス] フィールドの動作が、タスクの 2.0 バージョンで変更されました。 以前のバージョンのタスクでは、指定されたパターンと一致するプロジェクト ファイルが見つからない場合、タスクは警告をログに記録した後、成功していました。 このようなシナリオでは、ビルドが成功したのに依存関係が復元されない理由を把握するのが困難な場合があります。 新しいタスクは、指定されたパターンに一致するプロジェクト ファイルが見つからない場合は失敗します。 これは他のタスクの動作と一致しており、簡単に理解して使うことができます。
  3. 以前のバージョンのタスクの publish コマンドでは、ユーザーが明示的に出力パスを指定した場合でも、プロジェクト ファイル名に従って名前を付けられたフォルダーにすべてのファイルを格納することで、出力パスが変更されていました。 このため、コマンドを連結するのが困難でした。 新しいタスクでは、ユーザーが出力パスのファイルを制御できるようになりました。

PATH で使用可能な dotnet のバージョンを管理し、新しい dotnet タスクによって使われる、新しい dotnet ツール インストーラー タスクもリリースされました。 したがって、新しいバージョンの dotnet を使うには、ビルドの先頭に dotnet ツール インストーラー タスクを追加するだけで済みます。

アカウント/コレクションの外部の作業

TFS サーバーまたは VSTS アカウントの外部のフィードを、それが別の VSTS アカウントまたは TFS サーバーの Package Management フィードか、または NuGet.org/npmjs.com、Artifactory、MyGet などの Package Management 以外のフィードかにかかわらず、簡単に使用できるようになりました (図 57)。 NuGet および npm に専用の__サービス エンドポイント__の種類により、正しい資格情報の入力が容易になり、ビルド タスクはパッケージ ダウンロード操作とパッケージ プッシュ操作の間でシームレスに動作できるようになりました。

使用するフィード

(図 57) 使用するフィード

VSTS/TFS フィード用のフィード ピッカー

ソース リポジトリにパッケージの元の場所が記録されるように、構成ファイル (NuGet.Config、.npmrc など) をチェックインすることを常にお勧めします。 ただし、これが望ましくない一連のシナリオが報告されているため、新しい [この VSTS/TFS フィードからのパッケージを使用する] オプションが追加されました。このオプションを使うと、フィードを選択し、そのビルド ステップに使われる構成ファイルを自動的に生成することができます (図 58)

フィード ピッカー

(図 58) フィード ピッカー

ビルドとリリース

XAML ビルドのサポートの削除

TFS 2015 では、Web ベースでクロスプラットフォームのビルド システムが導入されました。 TFS 2018 では、このモデルだけがサポートされています。 XAML ビルドは、TFS 2018 ではサポートされていません。 XAML ビルドを移行することをお勧めします。 まだ移行できる状態ではなく、XAML ビルドを引き続き使う必要がある場合は、TFS 2018 にアップグレードしないでください。

TFS 2018 にアップグレードする場合は次のようになります。

  • XAML ビルドのデータがチーム プロジェクト コレクション内にある場合は、XAML ビルド機能の削除に関する警告が表示されます。

  • TFS 2018 では、完了した XAML ビルドを表示することはできますが、新しいビルドをキューに入れることはできません。

  • TFS 2018 には XAML ビルド コントローラーまたはエージェントの新しいバージョンはなく、TFS 2018 で動作するように古いバージョンの XAML ビルド コントローラーまたはエージェントを構成することはできません。

XAML ビルドの使用終了計画について詳しくは、こちらのブログ投稿をご覧ください。

ビルド定義のインポートとエクスポート

ビルド定義は .json ファイルとして内部的に実装されるので、ファイルの履歴で変更に関する詳細を見ることができます。 ビルド定義からテンプレートを複製および作成することは既にできますが、多くのユーザーは、その CI ビルド ロジックをコピーし、別のチーム プロジェクトで再利用できることを望んでいます。 実際に、これは UserVoice で上位 10 件に入る要望でした。

それが可能になったことをお知らせします (図 59、図 60)

ビルド定義をエクスポートする

(図 59) ビルド定義をエクスポートする

ビルド定義をインポートする

(図 60) ビルド定義をインポートする

ビルド テンプレートに関する拡張機能

ビルド テンプレートを使うと、ユーザーがビルド プロセスの定義を始めるときのベースラインを作成できます。 これまで、製品には複数のテンプレートが付属し、ユーザーは新しいテンプレートをアカウントにアップロードできましたが、拡張機能の作成者が拡張機能の一部として新しいテンプレートを含めることはできませんでした。 このバージョンでは、拡張機能にビルド テンプレートを含めることができるようになりました。 例:

{  "id": "Template1", 
   "type": "ms.vss-build.template", 
   "targets": [ "ms.vss-build.templates" ], 
   "properties": { "name": "Template1" } }

完全な例については、https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension をご覧ください。

ヒント

この機能を使うと、同じカスタム テンプレートを提供してすべてのチーム プロジェクトで共有することができます。

拡張機能のタスクを非推奨にする

拡張機能のタスクを非推奨にできるようになりました。 そのためには、タスクの最新バージョンに次の変数を追加する必要があります。

"deprecated": true

ユーザーが非推奨のタスクを検索すると (図 61)、これらのタスクは一覧の最後に移動され、既定で折りたたまれる折りたたみ可能なセクションにグループ化されます。 定義で非推奨のタスクが既に使われている場合は、非推奨タスク バッジが表示され、ユーザーは代わりのタスクへの切り替えを促されます。

非推奨タスク バッジ

(図 61) 非推奨タスク バッジ

タスクの説明で言及することにより、ユーザーに代わりのタスクを伝えることができます (図 62)。 説明では、タスク カタログおよび既存のビルド/リリース定義の両方から正しい方向のタスクを使ってフォークをポイントします。

非推奨のタスクの説明

(図 62) 非推奨のタスクの説明

提供されたビルドのセクションでセクションの可視性を制御できる

従来、ビルド タスクとビルド概要セクションのある拡張機能を使用している場合は、そのビルドでビルド タスクを使用していない場合でも、ビルド概要セクションが表示されました。 現在は、次の行を拡張機能のコードに追加して値を true または false に設定することで、ビルド概要ページにそのセクションを表示するかどうかを選択できます。

VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);

Microsoft vsts-extension-samples リポジトリのサンプルをご覧ください。

変数グループのサポート

リリース定義で変数グループを使うことができましたが、ビルド定義でも使用できるようになりました。 詳しくは、creating a variable group (変数グループの作成) に関する記事をご覧ください。 この機能は、プロジェクト レベルのビルド/リリース変数およびビルド定義での変数グループに関する提案に基づいて優先的に開発されました。

Apple の証明書などのセキュリティで保護されたファイルの使用

汎用的なセキュリティで保護されたファイル ライブラリが追加されました (図 63)

セキュリティで保護されたファイル ライブラリ

(図 63) セキュリティで保護されたファイル ライブラリ

セキュリティで保護されたファイル ライブラリを使うと、署名証明書、Apple Provisioning Profiles、Android Keystore ファイル、SSH キーなどのファイルを、ソース リポジトリにコミットすることなくサーバーに格納できます。

セキュリティで保護されたファイルの内容は暗号化され、タスクから参照することにより、ビルド プロセスまたはリリース プロセスの間にのみ使うことができます。 セキュリティで保護されたファイルは、セキュリティの設定に基づいて、チーム プロジェクトの複数のビルド定義およびリリース定義で使用できます。 セキュリティで保護されたファイルは、ライブラリ セキュリティ モデルに従います。

この新しい機能を利用する Apple タスクもいくつか追加されました。

新しいリリース定義エディター

既定でオプトイン: 新しいリリース定義エディターはすべてのユーザーに対して既定でオプトインされます。 ユーザーまたは TFS 管理者は、プロファイル メニューの [プレビュー機能] オプションで、この機能をオフにすることができます。 詳しくは、「Enable preview features」(プレビュー機能を有効にする) をご覧ください。

引き続きビルドとリリースのエクスペリエンスの更新が行われており、新しいビルド定義エディターの後は、リリース定義エディターについて、エクスペリエンスをさらにわかりやすくし、使いにくさを解決し、新しい機能を追加することが予定されています。 新しいエディターの最も強力な機能の 1 つは、メンタル モデルを作成する機能、または環境への配置の進み具合を視覚化する機能です。 さらに、承認、環境、配置の設定が現在コンテキスト内にあり、簡単に構成できます (図 65)

パイプラインの視覚化

エディターのパイプライン (図 64) は、リリースでの配置の進捗状況をグラフィカル ビューで提供します。 成果物はリリースで使用されて、環境に配置されます。 環境のレイアウトとリンクは、各環境に定義されているトリガー設定を反映します。

パイプライン

(図 64) リリース パイプライン

コンテキスト内の構成 UI

成果物、リリース トリガー、配置前と配置後の承認、環境のプロパティ、配置の設定が現在コンテキスト内にあり、簡単に構成できます (図 65)

リリース構成

(図 65) リリース構成

展開テンプレートの概要

新しい環境を作成すると、簡単に作業を開始できるように、テンプレート (既製とカスタム) の一覧が表示されます (図 66)

展開テンプレート

(図 66) 展開テンプレート

タスクおよびフェーズ エディターの強化

新しいビルド定義エディターでのすべての機能強化が、リリース定義エディターでも使用できるようになりました (図 67)。 タスクを検索し、[追加] ボタンまたはドラッグ アンド ドロップを使って追加できます。 ドラッグ アンド ドロップを使って、タスクの順序を変更したりタスクを複製したりできます。

タスク エディター

(図 67) タスク エディター

[変数グループ]、[保有期間]、[オプション] タブ

変数グループのリンク/リンク解除 (図 68)、個々の環境の保有期間ポリシーの設定、リリース番号形式などのリリース定義レベルの設定の変更を、[オプション] タブから行うことができるようになりました。また、展開テンプレートとしての環境の保存、環境レベルのアクセス許可の設定、フェーズの順序の変更を、[タスク] タブで行うことができます。

変数グループ

(図 68) 変数グループ

環境レベルの操作を使って、テンプレートを保存し、セキュリティを設定します (図 69)

環境メニュー

(図 69) 環境メニュー

配置グループを使った VM の配置

Release Management は、堅牢で設定なしで使用できる複数のコンピューターの配置をサポートするようになりました。 アプリケーション全体の高可用性を確保しながら、複数のコンピューターの間で配置を調整し、ローリング更新を実行できます。

エージェント ベースの配置機能は、同じビルドと配置エージェントに依存します。 ただし、エージェント プールの一連のプロキシ サーバーにビルドと配置エージェントをインストールしてリモート ターゲット サーバーへの配置を行う現在のアプローチとは異なり、各ターゲット サーバーに直接エージェントをインストールして、それらのサーバーへのローリング配置を行います。 ターゲット コンピューター上の完全なタスク カタログを使うことができます。

1 つの配置グループは (図 70)、それぞれにエージェントがインストールされているターゲット (コンピューター) の論理的なグループです。 配置グループの集合は、単一コンピューターの開発、複数コンピューターの QA、UAT/Prod 用のコンピューターのファームなど、物理的な環境を表します。また、物理環境のセキュリティ コンテキストを指定します。

配置グループ

(図 70) 配置グループ

エージェントが登録されている任意の VM に対して、これを使うことができます。 また、VM のスピンアップ時にエージェントを自動インストールする Azure VM 拡張機能を備えた Azure に非常に簡単に登録することができます。 登録時には、Azure VM 上のタグを自動的に継承します。

配置グループを作成した後は、その配置グループで実行させたいことを構成するだけです (図 71)。 タグを使ってどのコンピューターで何を実行するかを制御し、ロールアウトの速さを制御できます。

配置グループの構成

(図 71) 配置グループの構成

配置を実行すると、対象のコンピューター グループ全体での進行状況がログに表示されます (図 72)

配置グループの進行状況

(図 72) 配置グループの進行状況

この機能は、Release Management に統合されています。 この使用に追加のライセンスは必要ありません。

タスク グループの参照

タスク グループを使うと、ビルド定義またはリリース定義に追加できるタスクのセットを定義できます。 これは、複数のビルドまたはリリースでタスクの同じグループを使う必要がある場合に便利です。 タスク グループのコンシューマーを追跡するため、タスク グループを参照しているビルド定義、リリース定義、タスク グループを表示できるようになりました (図 73)

タスク グループの参照

(図 73) タスク グループの参照

まだ参照されているタスク グループを削除しようとすると、警告とこのページへのリンクが表示されます。

タスク グループのバージョン管理

タスク グループを変更するときは、そのタスク グループを使っているすべての定義に変更が反映されるため、危険な場合があります。 タスク グループのバージョン管理を行うと、タスク グループのバージョンのドラフトやプレビューを行いながら、切り替えの準備ができるまで、最も重要な定義に安定したバージョンを提供できます。 ドラフトやイテレーションを行った後は、安定したバージョンを公開することができ、公開しながら、本質的に互換性に影響する変更の場合は、タスク グループをプレビュー (新しいメジャー バージョン) として公開することができます。 または、更新された安定したバージョンとして直接公開することもできます (図 74)

タスク グループの新しいメジャー (またはプレビュー) バージョンが利用可能なときは、新しいバージョンがあることが定義エディターに表示されます。 そのメジャー バージョンがプレビューの場合は、"試してみる" というメッセージも表示されます。 タスク グループがプレビューを終了すると、それを使用する定義が自動的に更新され、そのメジャー チャネルに移行します (図 75)

ドラフトとして保存する

(図 74) タスク グループをドラフトとして保存する

タスク グループをプレビューとして公開する

(図 75) タスク グループをプレビューとして公開する

タスク グループのインポートとエクスポート

タスク グループはプロジェクト内で再利用できますが、異なるプロジェクトやアカウントでタスク グループを再作成するのは面倒です。 タスク グループの Import/Export では (図 76)、リリース定義の場合と同じように、タスク グループを JSON ファイルとしてエクスポートし、必要な場所にインポートできます。 入れ子になったタスク グループも使用でき、最初にエクスポートするときに展開されます。

タスク グループをエクスポートする

(図 76) タスク グループをエクスポートする

サーバー側 (エージェントレス) タスクでの複数構成のサポート

サーバー側 (エージェントレス) タスクに対して可変乗数を指定することにより (図 77)、同じタスク セットを段階的に複数の構成で並列に実行できます。

エージェントレス タスクの複数構成

(図 77) エージェントレス タスクの複数構成

手動介入タスクでの変数のサポート

__手動で介入__タスクが (図 78)、タスクの実行時に、ユーザーがリリース プロセスの実行を再開または拒否できる時点で、ユーザーに示される指示テキスト内での変数の使用をサポートするようになりました。 リリース内で定義されていて利用可能な任意の変数を含めることができ、値は通知およびユーザーに送信されるメールで使われます (図 79)

手動で介入タスク

(図 78) 手動で介入タスク

手動介入保留ダイアログ

(図 79) 手動介入保留ダイアログ

ソース ブランチに基づいて環境へのリリースを制御する

新しいリリースが作成されたら (通常は、ソースのビルドが成功した後)、配置を自動的にトリガーするように、リリース定義を構成できます。 ただし、任意のビルドが成功したときではなく、ソースの特定のブランチからのビルドのみを配置したいことがあります。

たとえば、開発およびテスト環境にはすべてのビルドを配置しますが、運用環境には特定のビルドのみを配置するような場合です。 以前は、そのためには、2 つのリリース パイプラインを維持する必要がありました (開発およびテスト環境用に 1 つと、運用環境用に 1 つ)。

Release Management では、環境ごとの成果物フィルターの使用がサポートされるようになりました。 つまり、配置トリガー条件 (ビルドの成功や、新しいリリースの作成など) が満たされたときに、各環境に配置されるリリースを指定することができます。 環境の [配置条件] ダイアログの [トリガー] セクションで (図 80)、その環境への新しい配置をトリガーするビルドのソース ブランチとタグなど、成果物の条件を選びます。

[配置条件] ダイアログ

(図 80) [配置条件] ダイアログ

さらに、[リリース概要] ページには (図 81)、すべての "開始しなかった" 配置がその状態になった理由を示し、配置を開始する方法やタイミングを示唆する、ポップアップ ヒントが含まれます。

リリース概要のヒント

(図 81) リリース概要のヒント

成果物ソースとしての Git リポジトリのリリース トリガー

Release Management は、同じアカウント内の任意のチーム プロジェクトのリリース定義にリンクされている Git リポジトリの継続的配置トリガーの構成 (図 82) をサポートするようになりました。 これにより、新しいコミットがリポジトリに対して行われたときに自動的にリリースをトリガーできます。 また、コミットがリリースをトリガーする Git リポジトリ内のブランチを指定することもできます。

リリース トリガー

(図 82) リリース トリガー

リリース トリガー: Git リポジトリにプッシュされた変更の継続的配置

Release Management は常に、ビルドが完了したときの継続的配置を構成する機能を提供してきました。 しかし現在は、Git プッシュでの継続的配置を構成することもできます。 つまり、GitHub と Team Foundation Git リポジトリをリリース定義に成果物ソースとしてリンクした後、ビルドから生成されない Node.JS や PHP などのアプリケーションに対して自動的にリリースをトリガーし、継続的配置にビルド アクションが必要ないようにすることができます。

サーバー側タスクの機能強化

サーバー側タスク (サーバー フェーズ内で実行されるタスク) に対して 2 つの機能強化を行いました。

自動パイプラインの一部として汎用的な HTTP REST API (図 83) を呼び出すために使うことができる新しいタスクを追加しました。 たとえば、このタスクを使うと、Azure 関数を使う特定の処理を呼び出し、その完了を待機できます。

REST API タスク

(図 83) REST API タスク

また、すべてのサーバー側タスクに [管理オプション] セクション (図 84) が追加されました。 タスクの動作に、[有効][エラー時に続行][常に実行]、および [タイムアウト] の各オプションの設定が含まれるようになりました。

タスクの管理オプション

(図 84) タスクの管理オプション

[コード] ハブのリリース状態バッジ

今日、コミットが顧客の運用環境に配置されているかどうかを確認する場合は、最初に、どのビルドがコミットを使用しているかを明らかにした後、そのビルドが配置されているすべてのリリース環境を確認します。 このエクスペリエンスは、配置状態が [コード] ハブの状態バッジに統合されて、コードが配置されている環境の一覧が表示されるようになったことで、はるかに簡単になりました。 すべての配置について、配置の一部であった最新のコミットに状態が通知されます。 複数の環境の複数のリリース定義にコミットが配置される場合は、それぞれがバッジにエントリを持ち、環境ごとに状態が表示されます (図 85)。 これにより、配置に対するコードのコミットの追跡可能性が向上します。

リリース状態バッジ

(図 85) リリース状態バッジ

既定では、リリース定義を作成すると、配置の状態がすべての環境に通知されます。 ただし、配置状態を状態バッジに表示する環境を選択できます (たとえば、運用環境のみを表示する) (図 86)

配置オプション ダイアログ

(図 86) 配置オプション ダイアログ

成果物を追加するときのビルド定義メニューの機能強化

ビルド成果物をリリース定義に追加するとき、定義とフォルダー編成の情報を表示できるようになり、目的の定義の選択が容易になりました (図 87)。 これにより、フォルダーが異なる同じ名前のビルド定義を簡単に区別できます。

成果物を追加する

(図 87) 成果物を追加する

定義の一覧は、フィルター条件を含むものによってフィルター処理されます。

古いバージョンにリリース定義を戻す

現在、リリース定義を更新する場合、前のバージョンに直接戻すことはできません。 唯一の方法は、リリース定義の履歴を見て、変更の相違を見つけ、リリース定義を手動で編集することです。 新しいバージョンでは、[定義を元に戻す] 機能を使って (図 88)、リリース定義の [履歴] タブから古いバージョンのリリース定義を選んで戻すことができます。

リリース定義を元に戻す

(図 88) リリース定義を元に戻す

テスト

Microsoft Test Manager でのラボ センターと自動テスト フローのサポートの削除

ビルドと Release Management の発展により、TFS 2018 では XAML ビルドはサポートされなくなり、結果として、TFS での Microsoft Test Manager (MTM) の使用のサポートが更新されています。 自動テストのための MTM でのテスト センター/ラボ センターの使用は、TFS 2018 以降ではサポートされていません。 XAML ビルドおよびラボ センターから移行する準備ができていない場合は、TFS 2018 にアップグレードしないでください。

TFS 2018 にアップグレードすると次のような影響があります。

ラボ センター:
  • サポート対象から除外されました。
    • ラボ環境を作成および管理するためにテスト コントローラーを TFS に登録することはできません。
    • TFS に登録されている既存のテスト コントローラーはオフラインになり、既存のラボ環境は "準備不完了" と表示されます。
  • 推奨される代替方法:
自動テスト:
手動テスト:
  • すべての手動テスト シナリオは引き続き完全にサポートされます。 TFS 2018 で MTM を使って手動テストを実行することはできますが、ラボ環境を使って手動テストを実行することはできません。
  • すべての手動テスト シナリオについて、TFS の Web アクセスで [テスト] ハブを使うことを強くお勧めします。

作業項目リンク、イテレーション、区分パスに対する探索的テストの追跡可能性の機能強化

探索的テストを行っているチームからのフィードバックに基づき、Test & Feedback 拡張機能からバグ、タスク、またはテスト ケースを収集しながら、追跡可能性リンクの機能強化を行っています。 要件の検証中に作成されたバグとタスクは、チームの既定値ではなく、要件と同じ区分パスとイテレーションで作成されるようになります。 要件の検証中に作成されたテスト ケースは、作成したテスト ケースが要件に基づくテスト スイートに自動的に追加されるように、Parent <-> Child リンクではなく Tests <-> Tested By リンクでリンクされるようになります。 最後に、特にどの要件も検証されていないときに作成された作業項目は、スプリント計画が完了した後で現在のイテレーションに新しい作業項目が追加されないように、現在のイテレーションではなくチームの既定のイテレーションに記録されます。

テスト ハブでのテスト計画とテスト スイートのテスト ケース作業項目のフィルター処理

[結果][構成][テスト担当者] などの [テスト] フィールドでのフィルターと同様に、[タイトル][状態][担当者] などのテスト ケース作業項目のフィールドでフィルター処理できるようになりました (図 89)

テスト ケース フィルター

(図 89) テスト ケース フィルター

リリース環境とテスト実行のテスト傾向グラフ

VSTS ダッシュボードでテスト環境の状態を追跡できるよう、テスト結果トレンド ウィジェット (図 90)リリース環境のサポートを追加しています。 ビルドでテスト結果に対して行うのと同様の方法で、リリース環境のテスト合格率、合計、合格/不合格のテストの数、テスト期間を示す傾向グラフを作成できるようになりました。 [テスト実行] タイトル フィルターで、グラフをフィルター処理して環境内の特定のテスト実行を抽出することもできます。

テスト傾向グラフ

(図 90) テスト傾向グラフ

テスト実行およびテスト結果のコメントに対するマークダウン書式設定のサポート

マークダウン構文でのテスト実行およびテスト結果のコメントの書式設定のサポートを追加しています。 この機能を使って、書式設定されたテキストまたは URL へのクイック リンクをコメントに作成できます。 [結果概要] ページの [テスト結果] コメントを [分析の更新] で更新でき、[実行の概要] ページの [テスト実行] コメントを [テスト] ハブの [コメントの更新] で更新できます。

[ビルド] または [リリース] の概要ページ、または [テスト] ハブで、テスト結果を分析しながら、既存のバグを不合格になったテストに関連付けることができるようになりました。 これは、バグが既に登録されている既知の理由によりテストが不合格になっている場合に便利です。

SharePoint の TFS 拡張機能の廃止

TFS 2018 以降のバージョンでは、SharePoint の TFS 拡張機能はサポートされなくなります。 さらに、TFS サーバーと SharePoint サーバーの統合を構成するための画面は、Team Foundation 管理コンソールから削除されました。

今後、サーバー間の統合はサポートされず、パブリック API と拡張機能フレームワークを使って統合が行われます。

TFS/SharePoint 統合を構成してサーバーをアップグレードしている場合は、サーバー間統合を "使用しないアップグレード" のためのソリューションが提供されています。 アップグレード後も TFS SharePoint サイトは引き続き表示されますが、統合機能は無効になります。 詳細および手順については、こちらをご覧ください。

チーム ルームの廃止

最新の開発チームはコラボレーションに大きく依存します。 ユーザーは、アクティビティ (通知) を監視し、それについて話し合う (チャット) ための場所を望んでいます (そして必要としています)。 数年前にこの傾向を認識し、これらのシナリオをサポートするためのチーム ルームの構築に着手しました。 その後、多くのコラボレーション用ソリューションが市場に登場しました。 最も顕著なのは、Slack の発展です。 さらに最近では、Microsoft Teams の発表です。

TFS および Visual Studio Team Services と問題なく統合する優れたソリューションが増えたため、TFS 2018 および Visual Studio Team Services からチーム ルーム機能を削除する計画を 1 月に発表しました


既知の問題

TFS Database Import Service で RC リリースがサポートされていない

Visual Studio Team Services 用の TFS Database Import Service では、TFS の RC リリースからのインポートをサポートしていません。 このサービスを使用して Team Services にコレクション データベースをインポートする計画がある場合は、実稼働データベースをこの RC リリースにアップグレードしないでください。 アップグレードを行った場合は、このリリースの RTW バージョンを待ってアップグレードするか、あるいは以前の TFS バージョンで作成したデータベースのバックアップ コピーを復元してインポートします。

ビルド/リリースの Visual Studio Test v1 タスクは、Visual Studio 2017 Update 3 を使ってテストを実行できない

ビルド/リリースの Visual Studio Test v1 タスクは、Visual Studio 2017 Update 3 を使ってテストを実行できません。 タスクは、"vstest.console.exe ファイルの場所を特定できません" で失敗します。 回避するには、Visual Studio Test タスクのバージョン 2 を使います。