Team Foundation Server 2018 リリース ノート

Last Update: 2017/11/22

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

Download the latest version of Team Foundation Server

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


TFS 2018 の新機能のビデオ


フィードバック

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


リリース日: 2017 年 11 月 15 日

概要: Team Foundation Server 2018 の更新プログラム

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 に自動的にリダイレクトされます。

作業項目フォーム ヘッダーのカスタマイズ

既存のコントロールを置換するか、またはプロセスに関連のないコントロールを非表示にして、作業項目フォームのヘッダー領域をカスタマイズできるようになりました。 これにより、領域パスをユーザー設定のチーム フィールドに置き換えたり、チームが "かんばん" に重点を置いている場合にイテレーションを非表示にしたり、理由をユーザー設定のフィールドに置き換えたりできます。 状態フィールドは非表示にすることも置き換えることもできません。

詳細については、WebLayout および Control 要素に関するドキュメントを参照してください。

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

完全なエンド ツー エンドのエクスペリエンスで、作業項目の外観が最適化されています (図 1)。 自分に割り当てられた項目、フォローしている項目、過去に表示した項目、最近編集した項目を携帯電話から簡単に操作できます。

Mobile work item query

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

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

Mobile work item form

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

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

Mobile navigation

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

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

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

Filtering on query

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

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

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

Hidden field

(図 5) かんばんカードの隠しフィールド

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

Update hidden field

(図 6) かんばんカードの隠しフィールドの更新

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

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

配信計画へのインラインでの追加

新機能のアイデアはいつ思いつくかわかりません。そこで、新機能を配信計画に簡単に直接追加できるようにしました (図 7)。 ホバー時の [新規アイテム] ボタンをクリックし、名前を入力し、Enter キーを押すだけです。 新機能は、領域のパスとイテレーション パスを想定して作成します。

Inline add on delivery plans

(図 7) 配信計画へのインラインでの追加

バージョン管理

フォーク

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

Git forks

(図 8) Git フォーク

GVFS

Git Virtual File System (GVFS) がサポートされるようになりました。 GVFS を使用すると、ファイル システム上での Git の動作を仮想化および最適化することにより、Git リポジトリを数百万のファイル規模に対応できるようにすることができます。

Web を使用してリポジトリにフォルダーを作成する

Web を介して Git および TFVC リポジトリにフォルダーを作成できるようになりました (図 9)フォルダー管理拡張機能に取って代わる機能です。フォルダー管理拡張機能は廃止処理が行われることになります。

フォルダーを作成するには、コマンド バーまたはコンテキスト メニューで [新規]、[フォルダー] の順にクリックします。

New folder option

(図 9) 新しいフォルダー オプション

TFVC の場合は、フォルダー名を指定し、チェックインします。 Git の場合、フォルダーを空にすることはできないので、ファイル名も入力する必要があります。必要に応じてファイルを編集し、コミットします。

さらに、Git の場合、[新しいファイル] ダイアログ (図 10) が強化され、サブフォルダーを作成するためのスラッシュを使用できるようになりました。

New file dialog

(図 10) [新しいファイル] ダイアログ

ファイルのミニマップ

表示または編集しながらファイルのミニマップを表示して、コードの概要を簡単に確認できるようになりました (図 11)。 ミニマップをオンにするには、(F1 キーまたは右クリックで) コマンド パレットを開き、[Toggle Minimap](ミニマップの切り替え) を選択します。

File minimap

(図 11) ファイルのミニマップ

中かっこの位置揃え

ファイルを編集したり、表示したりするときに、左側にガイドラインが表示され、中かっこの位置を簡単に揃えられるようになりました (図 12)

Bracket matching

(図 12) 中かっこの位置揃え

空白の表示/非表示の切り替え

ファイルを表示または編集するときに空白の表示/非表示を切り替えることができるようになりました。 差分をとるときに空白を切り替える機能はまだ開発中です。 空白を表示するには (図 13)、(F1 キーまたは右クリックで) コマンド パレットを開いて [Toggle White Space](空白の切り替え) を選択します。これにより、スペースとタブを区別することができます。

Toggle white space

(図 13) 空白の表示/非表示の切り替え

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

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

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

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

メモ

__プロジェクト概要ページ__からの README の編集には影響ありません。

Turn off web editing

(図 14) Web 編集をオフに設定

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

Web editing not allowed dialog

(図 15) Web 編集が許可されないダイアログ

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

古いブランチを識別する

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

Stale branches

(図 16) 古いブランチ

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

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

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

Search for deleted branches

(図 17) 削除されたブランチの検索

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

Restore deleted branches

(図 18) 削除されたブランチの復元

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

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

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

Search for a commit

(図 19) コミットの検索

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

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

Pull request callout

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

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

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

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

Find a file or folder

(図 21) ファイルまたはフォルダーの検索

Filtered view

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

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

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

Pushes page

(図 23) プッシュ ページ

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

Commits page

(図 24) コミット ページ

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

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

Git タグを表示する

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

View Git tags

(図 25) Git タグの表示

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

Git タグを削除する

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

警告

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

Delete git tags

(図 26) Git タグの削除

Git タグのフィルター処理

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

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

Filter Git tags

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

Git タグのセキュリティ

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

Git tag security

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

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

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

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

Complete linked work items

(図 29) リンクされた作業項目の完了

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

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

Reset votes setting

(図 30) 投票設定のリセット

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

Reset votes in timeline

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

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

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

Find file or folder in pull request

(図 32) プル要求でのファイルまたはフォルダーの検索

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

Find results

(図 33) 検索結果

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

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

PR comment filtering

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

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

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

View original diff

(図 35) 元の差分の表示

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

Update badge

(図 36) 更新バッジ

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

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

Hide comments

(図 37) コメントの非表示

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

Collapsed comments

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

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

Collapsed comment tooltip

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

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

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

Task list toolbar

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

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

Task list

(図 41) タスク一覧

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

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

Like pull request comments

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

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

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

Cancel auto-complete dialog

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

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

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

Path filtering for notifications

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

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

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

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

Improved email template

(図 45) 強化されたメール テンプレート

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

Email call-to-action

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

プッシュ通知用の電子メール テンプレートの更新

プッシュ通知は、明確かつ簡潔で、実行可能に最適化された新しい電子メールテンプレートに合わせて更新されました (図 47)。 件名は、プッシュ電子メールを明確に区別し、ブランチ、リポジトリ、および作成者を特定し、プッシュに含まれるコミットの数を要約するのに役立ちます。 このような変更により、これらの電子メール通知を管理するのに役立つルールとフィルターを簡単に作成することもできます。

電子メールの本文は、他の電子メールと一貫した内容になっており、電子メールが送信された理由、操作を開始した人、通知が発生した原因を強調しています。 プッシュ通知に特化して、リポジトリ、ブランチ、ファイル、およびコミットの詳細がすべて含まれており、受信者に変更の範囲について通知するのに役立ちます。 プッシュ通知に対するアクションの main 呼び出しは View Push です。これにより、通知を生成した特定のプッシュのプッシュ ビューが表示されます。

Push template

(図 47) プッシュ テンプレート

Wiki

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

Wiki page

(図 48) PR Wiki ページ

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

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

Title wiki

(図 49) PR タイトル Wiki

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

Wiki HTML tags

(図 50) PR Wiki HTML タグ

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

Image resize

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

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

Wiki menu

(図 52) PR Wiki メニュー

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

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

Wiki revert button

(図 53) PR Wiki の [元に戻す] ボタン

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

Create wiki page

(図 54) PR 作成 Wiki ページ

Wiki ページでのディープ リンクの設定

Wiki では、ページ内またはページ間にディープ リンクの設定セクションをサポートするようになりました。これは目次を作成する場合に非常に便利です。 次の構文を使用して、同じページまたは別のページにある見出しを参照できます。

  • 同じページ: [text to display](#section-name)
  • 別のページ: [text to display](/page-name#section-name)

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

パッケージの管理

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

パッケージの URL が、GUID ではなく、パッケージ名とバージョンで動作するようになりました。 これにより、パッケージの URL を簡単に手作りできます (図 55)。 形式は \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package です。

Package URL

(図 55) PR パッケージ URL

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

Hide deleted packages

(図 56) 削除されたパッケージの非表示

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

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

Last pushed column

(図 57) 最終プッシュ列

Maven パッケージ

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

Maven packages

(図 58) Maven パッケージ

新しい統合 NuGet タスク

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

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

Nuget task

(図 59) NuGet タスク

詳細については、Microsoft DevOps のブログで、「ビルドでの最新の 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 タスクが更新されました (図 60)

dotnet task

(図 60) dotnet タスク

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

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

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

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

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

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

Feeds to use

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

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

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

Feed picker

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

ビルドとリリース

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 ビルドの廃止予定の詳細については、TFS/Team Services 構築の自動化機能の進化に関するブログ記事を参照してください。

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

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

ついにこれが可能になったことをお知らせします (図 63)(図 64)

Export build definition

(図 63) ビルド定義のエクスポート

Import build definition

(図 64) ビルド定義のインポート

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

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

{  "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

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

Deprecated task badge

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

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

Deprecated task description

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

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

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

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

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

変数グループのサポート

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

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

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

Secure files library

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

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

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

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

ビルド定義の一時停止

ビルド定義を一時停止または無効にすることができるようになりました。 ビルド定義を変更するときに、完了するまで新しいビルドのキューを避けたい場合は、ビルド定義を無効にするだけで済みます。 同様に、エージェント マシンをアップグレードする予定がある場合は、ビルド定義を一時停止することもできます。これにより、VSTS は新しいビルド要求を引き続き受け入れますが、それらをキューに入れて保持し、定義を再開するまで実行しません。

タスクの入力検証をサポート

ビルド定義タスクにパラメーターを入力する場合、エラーが発生することがあります。 タスクのパラメーター入力検証では、タスクの作成者は適切な値が指定されるようにすることができます。 検証条件式は、タスク条件に使用される一般的な式構文に従います。このため、検証条件式では、URL、IPV4、電子メール、番号範囲、sha1、長さ、または一致など、タスク条件でサポートされている一般的な機能以外にもサポートされている関数を使用できます。

目標と使用の詳細については、vsts-tasks リポジトリ ページ を参照してください。

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

引き続きビルドとリリースのエクスペリエンスの更新が行われており、リリース定義エディターについて、エクスペリエンスをより直感的にし、使いにくさを解消して、新しい機能を追加することが予定されています。 新しいエディターの最も強力な機能の 1 つは、環境への展開の進み具合を視覚化する機能です。 さらに、承認、環境のプロパティ、配置の設定が現在コンテキスト内にあり、簡単に構成できます。

パイプラインの視覚化

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

Pipeline

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

コンテキスト内の構成 UI

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

Release configuration

(図 69) リリース構成

展開テンプレートの概要

組み込みの展開テンプレートはすべてプロセス パラメーターを備えています。このパラメーターを使用すれば、ユーザーはタスクの詳細を隅々まで確認しなくても、最も重要なパラメーターを指定することで簡単に作業を開始することができます (図 70)

Deployment templates

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

リリースおよび環境変数の管理の簡素化

リリースまたは環境変数を迅速に追加するにはリスト ビューを使用し、変数をスコープ間で同時に比較および編集するにはグリッド ビューを使用します (図 71)。 さらに、フィルターとキーワード検索を使用して、両方のビューで使用する変数セットを管理することができます。

Simplified management of variables

(図 71) 変数の管理の簡素化

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

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

Task editor

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

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

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

Variable groups

(図 73) 変数グループ

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

Environment menu

(図 74) 環境メニュー

詳細については、リリース定義エディターのドキュメント を参照してください。

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

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

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

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

Deployment groups

(図 75) 配置グループ

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

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

Configure deployment groups

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

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

Deployment group progress

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

この機能は、Release Management に統合されています。 その他のライセンスは不要です。

配置グループ UI の改良

引き続きビルドリリースのエクスペリエンスの更新が行われており、配置グループ ページについて、エクスペリエンスがさらに直観的になる予定です (図 78)。 ランディング ページから、配置グループ内のターゲットの正常性を確認できます。 また、個々 の配置グループのセキュリティを管理することも、配置グループ間の既定のアクセス許可を設定することもできます。

Deployment groups UI

(図 78) 配置グループの UI

配置グループ内のターゲットについて、概要、最近の配置、ターゲットの機能を表示できます (図 79)。 ターゲットに対してタグを設定し、各ターゲット上で実行するものを制御できます。 今後のリリースでは、配置グループに対してフィルターのサポートを追加する予定です。

Deployment groups UI tags

(図 79) 配置グループの UI のタグ

タスク グループの参照

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

Task group references

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

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

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

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

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

Save as draft

(図 81) ドラフトとしてのタスク グループの保存

Publish task group as preview

(図 82) プレビューとしてのタスク グループの公開

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

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

Export task group

(図 83) タスク グループのエクスポート

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

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

Multi configuration of agentless tasks

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

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

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

Manual intervention task

(図 85) 手動介入タスク

Manual intevention pending dialog

(図 86) [手動介入を保留中] ダイアログ

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

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

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

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

Deployment conditions dialog

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

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

Release summary tip

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

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

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

Release triggers

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

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

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

環境トリガーでのブランチ フィルター

新しいリリースの定義エディターでは、特定の環境に合わせて成果物の条件を指定できるようになりました。 このような成果物の条件を使用すると、特定の環境に配置する必要がある成果物をより詳細に制御できるようになります。 たとえば、運用環境の場合、マスター ブランチから生成されたビルドのみが配置されていることを確認したい場合があります。 このフィルターは、この条件を満たす必要があると考えられるすべての成果物に対して設定する必要があります。

リリース定義にリンクされている成果物ごとに複数のフィルターを追加することもできます (図 90)。 成果物の条件がすべて正常に満たされた場合にのみ、この環境への配置がトリガーされます。

Branch filters

(図 90) ブランチ フィルター

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

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

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

REST API task

(図 91) REST API タスク

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

Task control options

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

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

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

Release status badge

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

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

Deployment options dialog

(図 94) [配置オプション] ダイアログ

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

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

Add artifact

(図 95) 成果物の追加

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

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

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

Revert release definition

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

個人用のリリース通知

リリース通知が VSTS 通知設定のエクスペリエンスに統合されました。 リリースを管理するユーザーには、保留中のアクション (承認または手動介入) と重要な配置エラーが自動的に通知されるようになりました。 このような通知はオフにすることができます。そのためには、プロファイル メニューの [通知] 設定を開き、[Release Subscriptions](リリースのサブスクリプション) をオフに切り替えます。 カスタム サブスクリプションを作成して追加の通知をサブスクライブすることもできます。 管理者は、[チーム] 設定と [アカウント] 設定の下にある [通知] 設定からチームとアカウントのサブスクリプションを制御できます。

リリース定義の作成者は、承認と配置の完了に関する電子メールを手動で送信しなくてもよくなりました。

これは、複数のリリースの関係者と、通知を受け取りたいユーザー (承認者、リリース作成者、環境の所有者を除く) を有する大規模アカウントに特に便利です (図 97)

Release notifications

(図 97) リリース通知

詳細については、リリース通知の管理に関する投稿を参照してください。

テスト

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 リンクでリンクされるようになります。 最後に、特にどの要件も検証されていないときに作成された作業項目は、スプリント計画が完了した後で現在のイテレーションに新しい作業項目が追加されないように、現在のイテレーションではなくチームの既定のイテレーションに記録されます。

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

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

Test case filters

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

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

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

Test trend chart

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

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

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

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

テストの実行およびテスト結果への添付情報のアップロード

スクリーンショットやログ ファイルなどのファイルをテストの実行またはテスト結果に追加情報として添付することができます。 これまで、この機能は Microsoft Test Manager (MTM) クライアントからのみ使用でき、VSTS/TFS のテスト ハブと MTM クライアント間のコンテキストを切り替える必要がありました。

テストのバッチ処理

ビルド/リリース管理の Visual Studio テスト タスクでは、効率的な実行のためにテストをグループ化 (バッチ処理) する方法を制御するためのオプションが用意されています。 テストは次の 2 つの方法でグループ化できます。

  1. 実行に参加しているテストとエージェントの数に基づく方法。指定されたサイズのバッチ数になるように、テストを簡単にグループ化します。
  2. テストの過去の実行時間に基づく方法。過去の実行時間を考慮して、各バッチの実行時間がほぼ同じになるようにテストのバッチを作成します (図 100)。 短いテストの実行は組み合わせてバッチ処理されますが、長いテストの実行は個別のバッチに属する場合があります。 このオプションをマルチエージェント フェーズ設定と組み合わせて、合計テスト時間を最小限に抑えることができます。

Test batching

(図 100) テストのバッチ処理

VSTest タスクを使用した Web テストの実行

Visual Studio テスト タスクを使用して、Web テスト (Web パフォーマンス テストとも呼ばれる) を CI/CD パイプラインで実行できるようになりました。 Web テストは、タスク アセンブリの入力に、実行するテストを指定することで実行できます。 Web テストにリンクされた "関連付けられたオートメーション" を含む任意のテスト ケース作業項目は、タスクでテスト計画/テスト スイートを選択することで実行できます (図 101)

Test selection

(図 101) テストの選択

Web テストの結果は、テスト結果の添付情報として使用できるようになります (図 102)。 これは、Visual Studio でのオフライン分析用にダウンロードできます。

Test summary

(図 102) テストの概要

この機能は Visual Studio テスト プラットフォームの変更に左右され、ビルド/リリース エージェントに Visual Studio 2017 Update 4 がインストールされている必要があります。 Visual Studio の以前のバージョンを使用して Web テストを実行することはできません。

同様に、機能テストの実行タスクを使用して Web テストを実行することもできます。 この機能は、テスト エージェントの変更に左右され、Visual Studio 2017 Update 5 で使用することができます。

これをロード テストと組み合わせて使用する方法の例については、Load test your app in the cloud using Visual Studio and VSTS quickstart (Visual Studio および VSTS のクイック スタートを使用してクラウドでアプリのロード テストを行う) を参照してください。

テスト計画とテスト スイート用のグラフ ウィジェット

以前は、テスト ハブでテスト計画およびテスト スイートのグラフを作成し、それをダッシュボードにピン留めすることができました。 ウィジェットを追加したことで、ダッシュボードのウィジェット カタログから、テスト計画やテスト スイートのグラフを作成できるようになりました。 テストの作成状態またはテストの実行状態のグラフを作成することができます。 さらに、グラフ上に表示するデータが多い場合は、ウィジェットからグラフを追加することにより、より大きなグラフを作成することができます (図 103)

Chart widget

(図 103) グラフ ウィジェット

手動テストのために Chrome ブラウザーを使用してデスクトップ アプリに対するスクリーンショットおよび注釈をサポート

手動テストの上位推奨候補のいずれか 1 つに対するサポートを追加します。テスト ハブの Web テスト ランナーからデスクトップ アプリケーションのスクリーン ショットをキャプチャするというものです。 これまで、デスクトップ アプリのスクリーンショットをキャプチャするには、Microsoft Test Managerテスト ランナーを使用する必要がありました。 この機能を使用するには、テストとフィードバックの拡張機能をインストールする必要があります。 Chrome ブラウザーのサポートを公開しています。その後すぐに Firefox のサポートが公開されます。

SharePoint の TFS 拡張機能の廃止

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

メモ

SharePoint と統合するように構成された以前のバージョンから TFS 2018 にアップグレードする場合は、アップグレード後に SharePoint 統合を無効にする必要があります。そうしないと、TFS SharePoint サイトの読み込みエラーが発生します。

SharePoint サーバー上で統合を無効にできるソリューションを作成しました。 詳細については、The future of our TFS/SharePoint Integration (TFS/SharePoint の統合の将来) を参照してください。

チーム ルームの廃止

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

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


ページのトップへ