Team Foundation Server 2018 リリース ノート

---

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

---

Note

英語以外のバージョンからこのページにアクセスしていて、最新の内容を見たい場合は、このリリース ノートの英語版ページをご覧ください。 ページ フッターにある地球アイコンをクリックし、目的の言語を選択すると、このページの言語を変更できます。

---

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

Team Foundation Server 2018 の詳細については、Team Foundation Server の要件と互換性に関するページを参照してください。 他の TFS 2018 製品をダウンロードするには、visualstudio.com/downloads ページを参照してください。

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

---

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

TFS 2018 の新機能の概要

Team Foundation Server 2018 に数多くの新機能が追加されました。 主な特徴:

• Web のプロジェクト作成ウィザードおよびプロセス テンプレート マネージャーの機能を強化しました。
• 作業項目フォーム ヘッダーをカスタマイズできるようになりました。
• モバイル作業項目フォームを最適化しました。
• Git フォークのサポートを追加しました。
• GVFS で大規模な Git リポジトリを管理できます。
• Git タグのセキュリティを表示、フィルター処理、削除、および設定できます。
• ファイルのミニマップ、中かっこの位置揃え、および空白の表示/非表示の切り替えを Web コードの編集に追加しました。
• pull requestsに対して多くの機能強化を行いました。
• Wiki のエクスペリエンスが機能強化されて新しくなっています。
• Maven パッケージのサポートが追加されました。
• ビルド定義をインポート、エクスポート、一時停止することができます。
• 新しいリリース定義エディターが既定でオプトインします。
• 仮想マシンの配置で配置できます。
• 探索的テストの追跡可能性を機能強化しました。
• テストのバッチ処理を追加しました。
• テスト計画とテスト スイート用のグラフ ウィジェットを表示できるようになりました。

TFS 2018 の新機能のビデオ

XAML ビルド

元々、XAML ビルドは TFS 2018 RTW および Update 1 から削除されたものとして表示されていました。 ただし、それによって多くの顧客がアップグレードできなくなったり、アップグレードの完了後に再有効化のためサポートに連絡しなければならなくなりました。 TFS 2018 Update 2 では、XAML ビルドが有効になっていますが、推奨されていません。 つまり、XAML ビルドへの追加の投資はなく、Microsoft Test Manager (MTM) は XAML ビルドの使用を今後サポートしません。 新しいビルド定義形式のいずれかに変換することを強くお勧めします。 引き続き XAML コントローラーに接続して、TFS 2018 Update 2 で XAML ビルドを実行することもできます。 詳細

TFS 2018 RTW で削除された機能

• Microsoft Test Manager のラボ センターと自動テスト フローのサポートが削除されました。
• SharePoint の TFS 拡張機能を廃止しました。
• チーム ルーム機能を削除しました。

---

TFS 2018 の新機能の詳細

作業項目のトラッキング

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

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

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

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

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

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

ヒント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

バージョン管理

フォーク

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

(図 8) Git フォーク

GVFS

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

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

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

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

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

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

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

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

ファイルのミニマップ

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

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

角かっこの一致

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

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

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

ファイルを表示または編集するときに空白の表示/非表示を切り替えることができるようになりました。 差分をとるときに空白を切り替える機能はまだ開発中です。 空白を表示するには (図 13)、(F1 キーまたは右クリックで) コマンド パレットを開いて [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 編集は有効になっています。

Note

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

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

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

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

古いブランチを識別する

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

(図 16) 古いブランチ

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

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

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

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

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

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

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

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

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

(図 19) コミットの検索

コミット詳細ページのリッチになった pull request の吹き出し

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

(図 20) Pull request の吹き出し

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

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

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

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

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

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

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

(図 23) プッシュ ページ

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

(図 24) コミット ページ

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

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

Git タグを表示する

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

(図 25) Git タグの表示

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

Git タグを削除する

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

警告

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

(図 26) Git タグの削除

Git タグのフィルター処理

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

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

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

Git タグのセキュリティ

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

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

ヒント

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

pull requests 完了時に作業項目を自動的に完了させる

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

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

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

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

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

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

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

ファイル名で pull request ツリーをフィルター処理する

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

(図 32) pull request でのファイルまたはフォルダーの検索

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

(図 33) 検索結果

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

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

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

pull request の詳細でコードのコメントの元の差分を表示する

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

(図 35) 元の差分の表示

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

(図 36) 更新バッジ

折りたたみ可能な pull request のコメント

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

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

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

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

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

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

pull request の説明とコメントのタスク一覧

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

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

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

(図 41) タスク一覧

pull requests に "いいね!" コメントを付ける機能

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

(図 42) pull request に "いいね" コメントを付ける

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wiki

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

(図 48) PR Wiki ページ

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

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

(図 49) PR タイトル Wiki

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

(図 50) PR Wiki HTML タグ

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

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

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

(図 52) PR Wiki メニュー

• パワー ユーザー向けの Wiki のオフライン更新。

ヒント

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

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

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

壊れたリンクから Wiki ページを作成する

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

(図 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 です。

(図 55) PR パッケージ URL

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

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

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

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

(図 57) 最終プッシュ列

Maven パッケージ

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

(図 58) Maven パッケージ

新しい統合 NuGet タスク

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

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

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

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

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

(図 60) dotnet タスク

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

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

1. 最初に、dotnet は Package Management などの認証されたパッケージ ソースをサポートするようになったので、プライベート パッケージ ソースからパッケージを復元するために 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 に専用のサービス エンドポイントの種類により、正しい資格情報の入力が容易になり、ビルド タスクはパッケージ ダウンロード操作とパッケージ プッシュ操作の間でシームレスに動作できるようになりました。

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

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

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

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

ビルドとリリース

XAML ビルド

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

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

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

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

• TFS 2018 には新しいバージョンの XAML ビルド コントローラーまたはエージェントがありません。

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

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

• Visual Studio またはチーム エクスプローラー 2017 を使用して、XAML ビルド定義を編集するか、または新しい XAML ビルドをキューに入れる必要があります。

• 新しい XAML ビルド エージェントを作成する必要がある場合は、TFS 2015 ビルド エージェントのインストーラーを使用してそれらをインストールする必要があります。

ヒント

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

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

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

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

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

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

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

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

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

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

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

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

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

変数グループのサポート

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

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

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

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

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

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

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

• ユーティリティ: Install Apple Certificate

• ユーティリティ: Install Apple Provisioning Profile

ビルド定義の一時停止

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

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

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

ヒント

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

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

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

パイプラインの視覚化

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

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

コンテキスト内の構成 UI

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

(図 69) リリース構成

展開テンプレートの概要

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

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

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

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

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

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

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

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

Optionsタブから、変数グループ(図 73)へのリンク/リンク解除、個々の環境のアイテム保持ポリシーの設定、リリース番号形式などのリリース定義レベルの設定の変更ができるようになりました。環境をデプロイ テンプレートとして保存し、環境レベルのアクセス許可を設定し、Tasks タブ内でフェーズを並べ替えることもできます。

(図 73) 変数グループ

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

(図 74) 環境メニュー

配置グループを使った仮想マシンの配置

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

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

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

(図 75) 配置グループ

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

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

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

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

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

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

配置グループ UI の改良

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

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

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

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

タスク グループの参照

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(図 85) 手動介入タスク

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(図 91) REST API タスク

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

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

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

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

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

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

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

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

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

(図 95) 成果物の追加

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

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

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

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

個人用のリリース通知

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

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

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

(図 97) リリース通知

ヒント

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

テスト

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

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

TFS 2018 へのアップグレードの影響を以下で確認してください。

ラボ センター:

• サポートされなくなりました。
  • ラボ環境を作成および管理するためにテスト コントローラーを TFS に登録することはできません。
  • TFS に登録されている既存のテスト コントローラーはオフラインになり、既存のラボ環境は "準備不完了" と表示されます。
• 推奨される代替手段:
  • SCVMM TFS 拡張機能を使って SCVMM サーバーに接続し、仮想マシンを作成して管理し、その上でワークフローを実行できます。 詳しくは、ビルドとリリースでラボ管理操作を実行する方法についての記事をご覧ください。

自動テスト:

• サポートされなくなりました。
  • XAML のビルド、配置、テスト ワークフローや、MTM を使ったテスト計画からの自動テストの実行など、テスト コントローラーとラボ環境に依存する自動テスト ワークフローは、サポートされなくなりました。
• 推奨される代替手段:
  • ビルドとリリースで自動テストを実行することができます。
  • [テスト] ハブを使ってテスト計画から自動テストを実行することができます。

手動テスト:

• すべての手動テスト シナリオは引き続き完全にサポートされます。 TFS 2018 で MTM を使って手動テストを実行することはできますが、ラボ環境を使って手動テストを実行することはできません。
• すべての手動テスト シナリオについて、TFS の Web アクセスで [テスト] ハブを使うことを強くお勧めします。

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

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

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

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

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

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

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

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

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

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

不合格のテストに対する既存のバグへのリンクの追加

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

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

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

テストのバッチ処理

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

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

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

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

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

(図 101) テストの選択

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

(図 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)。

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

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

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

SharePoint の TFS 拡張機能の廃止

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

Note

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 月に発表しました。

---

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

皆様のご意見をお待ちしております。 開発者コミュニティで問題を報告して追跡し、スタック オーバーフローでアドバイスを得ることができます。

---

ページの先頭へ