Team Foundation Server 2017 Update 2 のリリース ノート

---

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

---

---

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

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

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

---

リリース日: 2017 年 7 月 24 日

Team Foundation Server 2017 Update 2 の新機能の概要

Team Foundation Server 2017 Update 2 には、新たに大きな価値が追加されました。 主な特徴:

• 作業項目では、作業項目の種類に関連付けられたアイコンが表示されるようになりました。
• 配信計画を導入しました。
• 作業項目の検索で作業項目を検索できます。
• ブランチ ポリシーの構成操作が新しくなりました。
• pull request がさまざまな面で改善されました。
• Git 履歴を視覚化する Git グラフが追加されました。
• Git タグを追加し、表示できるようになりました。
• パッケージ管理の操作が新しくなりました。
• ビルド定義エディターの操作が新しくなりました。
• Azure Web Apps への展開時のプログラムがさまざまな面で更新されました。
• コンテナーの展開がさまざまな面で改善されました。
• 条件付きビルド タスクを導入しました。
• 面倒な設定なしで通知機能が利用できるようになりました。

新機能の詳細をすべて確認できます。機能領域別に機能改善を表示してください。

• 作業項目のトラッキング
• バージョン管理
• Pull requests
• パッケージの管理
• ビルドとリリース
• テスト
• ウェアハウス
• 管理
• Microsoft Teams の統合

---

TFS 2017 Update 2 の新機能の詳細

作業項目トラッキングの機能強化

作業項目の種類アイコン

Microsoft はお客様にとって便利な製品を作ることを世界中のお客様に約束しております。 その取り組みの一環として、キーボードの配列から視覚的なデザイン/レイアウトに至るまで、さまざまな利便性問題を見つけ、対処しています。

作業項目のトラッキングでは、これまでほぼ色だけで作業項目の種類を伝えていました。 しかしながら、色の識別が困難なお客様や弱視のお客様にとっては似たような色の区別が難しくなる場合がありました。 すべてのお客様が作業項目の種類をもっと簡単に確認できるように、作業項目の種類の視覚的言語にアイコンを導入しました。 ユーザーは作業項目の種類をカスタマイズできます。Microsoft のアイコン ライブラリから選択してください。

バックログ/クエリ グリッドで種類を伝えていたカラー バーが色付きアイコンに代えられました (図 1) 。

ボードのカードに種類アイコンが導入されました (図 2) 。

デリバリー計画

配信計画は、チーム間で程度に差のない可視性とチーム間調整を支援する組織ツールです。繰り返しベースの予定表で作業状態を追跡記録します。 アカウントのプロジェクト全体からあらゆるチームまたはバックログ レベルを含めるように計画を調整できます。 さらに、計画にフィールドの条件を利用すると、ビューをさらにカスタマイズできます。また、マーカーで重要な日付を強調表示できます。 

拡張機能の詳細を表示し、インストールするには、配信計画についてのマーケットプレース ページをご確認ください。

インターネットから切断されている TFS インスタンスを所有しているユーザーの場合、VSTS Marketplace プレースに移動しなくても、Web アクセスの [拡張機能の管理] オプションから配信計画を直接使用できます。 [拡張機能の管理] から [ローカルの拡張機能の参照] をクリックし、 [配信計画] を選択して [インストール] をクリックします。 詳細については、プレインストールされた拡張機能に関するドキュメントを参照してください。

作業項目とビルドの自動リンク

ビルド定義にこの設定が新しく追加されたことで、作業を組み込んだビルドを、大量のビルドから手作業で検索しなくても、追跡記録できます。 ビルドと作業項目が正しく関連付けられると、作業項目フォームの開発セクションに自動的に表示されます。

この機能を有効にするには、ビルド定義の [オプション] の下にある設定を切り替えます (図 3) 。

古い作業項目フォームの非推奨

新しい作業項目フォームには概ね肯定的な意見が寄せられており、Microsoft がホストするアカウントで現在、100% 採用されています。 VSTS の利用者様に好評をいただいているこの機能をオンプレミスのお客様にもご利用いただきたく、古い作業項目フォームと古い拡張性モデルの非推奨を決定しました。 計画の詳細については、Microsoft アプリケーション ライフサイクル管理ページをご覧ください。

作業項目の検索

作業項目の検索機能では、あるコレクションの全プロジェクトを対象に高速かつ柔軟に全作業項目を検索できます (図 4) 。 作業項目の検索のフル テキスト検索エンジンを利用すれば、すべての作業項目フィールドを対象に語句を簡単に検索し、関連する作業項目を効率的に見つけることができます。 作業項目フィールドでインライン検索フィルターを利用すると、作業項目の 1 つのリストに簡単に絞り込むことができます。

検索サービスを TFS で構成すると、他に何もインストールしなくても検索を開始できます。 作業項目の検索機能でできること:

• プロジェクト全体を検索する: 自分のチームおよびパートナー チームのバックログで検索します。 プロジェクトをまたいで全作業項目を検索する機能を利用し、組織の作業項目全体から検索します。 プロジェクトや区分パスのフィルターを利用し、検索を絞り込みます。
• すべての作業項目フィールドを対象に検索する: すべての作業項目フィールド (カスタム フィールドを含む) を対象に検索し、関連する作業項目をすばやく簡単に見つけます。 全フィールドを対象にフル テキスト検索を実行し、関連する作業項目を効率的に見つけます。 スニペット ビューには、一致が見つかった箇所が示されます。
• 特定の領域で検索する: 作業項目フィールドでクイック インライン検索フィルターを使用すると、作業項目が 1 つのリストに数秒で絞り込まれます。 候補リストのドロップダウンを利用すれば、さらに簡単に検索を実行できます。 たとえば、AssignedTo:Chris WorkItemType:Bug State:Active のような検索を実行すると、Chris という名前のユーザーに割り当てられているアクティブなバグがすべて見つかります。
• 作業項目トラッキングとの統合を活用する: 作業項目検索インターフェイスには、作業ハブでおなじみのコントロールが組み込まれており、表示、編集、コメント、共有などの操作が可能です。

バージョン コントロールの機能強化

新しくなったブランチ ポリシー構成

ブランチ ポリシーの構成画面のデザインを変更し、優れた機能をいくつか新しく追加しました (図 5) 。  最も強力な機能の 1 つは、ブランチ フォルダーにポリシーを設定する機能です。  これは [ブランチ] ビューで設定できます。ブランチ フォルダーを選択し、コンテキスト メニューから [ブランチ ポリシー] を選択します。  

これで新しいポリシー構成 UX が開きます。この画面でポリシーを設定し、ブランチ フォルダー内の全ブランチに適用できます (図 6) 。  

ビルド ポリシーを使用している場合、1 つのブランチに複数のビルドを構成できるようになりました。  自動または手動のトリガーを指定するオプションも追加されました (図 7) 。 実行に時間がかかる自動化テスト実行のようなものには手動トリガーが役立ちます。1 回実行するだけで pull request が完了します。  ビルド ポリシーには表示名もあります。これは、複数のビルドを構成している場合に便利です。

手動トリガーのポリシーを構成したら、それを実行できます。pull request の [ポリシー] セクションにある [ビルドをキューに挿入] オプションを選択してください (図 8) 。

必須のレビュー担当者ポリシーのために (図 9) 、ポリシーの適用時に pull request タイムラインに追加するメモを指定する管理者向けの機能を追加しました (図 10) 。

アクティブなコメントなしの新しいポリシー

pull requests の全コメントが新しいコメント ポリシーで対処されていることを確認します。 このポリシーを有効にすると、アクティブなコメントは PR の完了をブロックし、全コメントの解決を強制します。 レビュー担当者が、PR 作成者にコメントを残したが、pull request は承認した場合でも、マージを希望する作成者がコメントを見逃すことがないので安心です。

ファイル ハブの機能強化

ファイル ハブのプログラムをいくつかの面で更新し、表示機能と編集機能を改善しました。

表示に関しては、ピボットを追加しました。ピボットを利用すると、現在のフォルダーの README を表示したり (図 11) 、マークダウン ファイルをプレビューしたり、ファイルを前のバージョンと比較したり (図 12) 、注釈を表示したりできます。

>

編集に関しては、変更をプレビューしたり、コメントを簡単に追加したり、新しいブランチにコミットしたり、作業項目をリンクしたりできるようになりました (図 13) 。

Git リポジトリを視覚化する

リポジトリやファイルのコミット履歴を表示しながらグラフを表示できるようになりました。 この機能により、Git グラフを利用し、Git リポジトリのすべてのブランチやコミットの関係を頭で簡単に理解できます (図 14) 。 このグラフでは、すべてのコミットが位相幾何学的に表示されます。

Git グラフの主要要素 (図 15) :

1. Git グラフは右揃えです。そのため、既定のブランチや選択したブランチに関連付けられているコミットは右に表示され、グラフの残りの部分は左に表示されます。
2. マージ コミットは、最初の親と 2 番目の親につながれた灰色の点で表されます。
3. 通常のコミットは青色の点で表されます。
4. コミットの親コミットが次の 50 コミットでビュー ポートに表示されない場合、コミット接続が実行されます。 矢印をクリックすると、コミットがその親コミットに接続されます。

コミットの Git タグを見る

チームが Git タグを利用し、リポジトリの履歴に特定の点を付けている場合、作成したタグがコミットに表示されます。 コミット リスト ビューと詳細ページで特定のコミットのタグを表示できます (図 16) 。

コミットにタグを追加する

コマンド ラインからタグを作成し、リポジトリにタグをプッシュする代わりに、コミットに移動し、タグを追加できるようになりました (図 17) 。 タグの作成ダイアログでは、リポジトリに他の参照をタグ付けすることもできます。

コミット リスト ビューにはコンテキスト メニューもあります (図 18) 。 コミット詳細ページに移動してタグや新しいブランチを作成する必要がありません (図 19) 。

変更セット ページとシェルブセット ページの更新

TFVC の変更セット ページとシェルブセット ページを現代風に変更しました。 いずれのページも、補助技術を利用するユーザーのために、さらに便利になっています。 新しいページには、変更セットの表題と、作成者など、変更セットに関する情報を含む新しいヘッダーも追加されました (図 20) 。

変更セット ページとシェルブセット ページのいずれにも、新しいマークダウン ディスカッション コントロールが追加されました (図 21)。マークダウンにコメントを入力したり、ユーザーを @mention したり、# を利用して作業項目を関連付けたり、ファイルや画像を簡単に添付したりできます。

コミット フィルター処理の強化

高度なフィルター処理オプションを利用し、コミット履歴結果をフィルター処理できるようになりました (図 22) 。 コミットのフィルター処理基準:

• すべての履歴
• すべての履歴と簡略化されたマージ
• 最初の親
• 簡易履歴 (既定のフィルター処理設定)

TFVC から Git にリポジトリをインポートする

同じアカウントで TFVC リポジトリから Git リポジトリにコードを移行できます。 移行を開始するには、リポジトリの選択ドロップダウンから [リポジトリのインポート] を選択します (図 23) 。

個々のフォルダーまたはブランチを Git リポジトリにインポートできます。あるいは TFVC リポジトリ全体 (ブランチを除く) をインポートできます (図 24) 。 また、最大 180 日間の履歴をインポートできます。  

Git LFS ファイル ロック

Git LFS ファイル ロック機能を追加しました。 この機能により、チームで大きな比較できないファイルを扱うとき、2 人以上で同じファイルを同時に編集しようとしても作業が失われることがありません。 ユーザーがファイルの編集を始めるには先にロックし、そのロックがサーバーに通知される必要があります。 他のユーザーがロックを試行するとサーバーに拒否されるので、そのファイルで既に作業している人がいることを理解できます。 この機能を利用する場合、Git LFS 2.1 以降にアップグレードしてください。

Git コミット コメントで新しいディスカッション コントロールを使用

Git コミットに残される簡易コメントで新しいディスカッション コントロールが使用されるように更新しました。 これでこのようなコメントがマークダウン対応になり、Git と TFVC の両方について、Web でのあらゆるコード コメント機能が完全なものになり、最先端の操作性が与えられます。

新しいツリー ビュー コントロール

Pull Request ファイル ビュー、Git コミット詳細、Git プッシュ詳細、TFVC シェルブセット詳細、TFVC 変更セット詳細、TFVC 変更セット ハブ、Git 履歴ハブが更新され、新しいツリー ビュー コントロールが追加されました (図 25) 。  ツリー ビューはいくつかの面で改善され、使いやすくなりました。  まず、空のフォルダー ノードを自動的に圧縮する圧縮ツリー ビューを表示するようにビューを変更しました。可能な限りたくさんのファイルが表示されます。  

また、コメントがもっと簡潔に、スペースに無駄なく表示されるようになりました。 コメント付きのファイルの場合、コメント スレッドごとに子項目が表示されます。そのスレッドを作成したユーザーのアバターが表示されます。  新しいコメント スレッドと返信のあるコメント スレッドには青い点が付きます。また、返信数が表示されます。

pull request の機能強化

PR の作成者とレビュー担当者の操作呼び出しの改善

チームでブランチ ポリシーを利用する場合、pull request を表示するとき、厳密にどのようなアクションが必要になるのか、判断が難しい場合があります。 主要な操作呼び出しが [完了] ボタンの場合、完了準備ができているということなのでしょうか。 PR ビューでは、ページを閲覧している人に関する情報、設定されているブランチ ポリシーに関する情報を利用し、そのユーザーに最も道理にかなう操作呼び出しが表示されるようになりました。

ポリシーが設定されているがまだ承認されていないとき、 [完了] ボタンを押すと (図 26) 、オートコンプリート機能の使用が奨励されるようになりました。  ポリシーがブロックされている場合、PR を完了できることはおそらくないでしょう。そのため、ポリシーがやがて承認されたときに PR を完了するオプションが与えられています。

レビュー担当者に関しては、PR の完了より承認を望むことが多いでしょう。そのため、承認していない場合、主要な CTA として [承認] ボタンがレビュー担当者に表示されます (図 27) 。

承認後、レビュー担当者が PR を完了する役割も担う場合、 [完了] (または [オートコンプリート] ) ボタンが CTA としてレビュー担当者に強調表示されます。

コメントに基づく措置

PR に相当な数のコメントが付いている場合、すべての会話を追跡記録することは難しくなります。 コメント管理で役に立つように、さまざまな拡張機能で対処していた項目の解決プロセスを簡略化しました。

• すべての PR のヘッダーに、解決されたコメントの数が表示されるようになりました (図 28) 。

• 対処済みのコメントは 1 回のクリックで解決できます (図 29) 。 

• 解決中にコメントを追加する場合、1 回のクリックで返信し、解決できます (図 30) .

• 全部対処されるまで、コメントが解決されるたびに数が増えます (図 31) 。

• 概要のフィルターを機能強化しました。コメントのさまざまな状態別にフィルター処理したり、フィルター オプションごとにコメント数を表示したりできます (図 32) 。

更新ビューのリベースと強制プッシュ

[Pull Request の詳細] ビューの [更新] タブが改善され、強制プッシュの発生時やベース コミットの変更時に情報を表示するようになりました (図 33) 。  この 2 つの機能は、PR の完了前にトピック ブランチでリベースが変更された場合、非常に役に立ちます。  レビュー担当者は情報が十分に与えられ、現状を正確に理解できるようになります。

Pull request をユーザー別にフィルタリング

pull requests が見つけやすくなりました。 新しいフィルター処理オプションが追加され、特定の作成者により作成された PR や特定のレビュー担当者に割り当てられた PR を見つけることができます (図 34) 。 作成者またはレビュー担当者フィルターからユーザーを選択すると、一覧が更新され、フィルターに一致する PR だけが表示されます。 

pull request ポリシーの回避時の理由が必須

pull request ポリシーを回避するとき、理由を指定する必要があります。  回避を選択すると、 [pull request の完了] ダイアログに [理由] フィールドが表示されます (図 35) 。

理由を入力し、pull request を完了とすると、[概要] にメッセージが表示されます (図 36)。

pull request をチームと共有

Pull Request を共有するという行為はレビュー担当者に通知する方法として便利です (図 37) 。  今回のリリースでは、チームとグループのためのサポートが追加されました。1 回の手順で関係者全員に pull request を通知できます。

チームのための pull request の機能強化

複数のチームに属している場合、すべてのチームに割り当てられているすべての PR が [自分の Pull Requests] ビューに一覧表示されます (図 38) 。 つまり、 [自分のPull Requests] ビューだけで、自分に与えられたすべての PR を確認できます。

今後のリリースでは、 [コード] の [Pull Requests] ハブにチームを追加し、1 つのプロジェクトで与えられているすべての PR を簡単に表示できるようにする予定です。

pull request コメントの既定の通知

コメント通知が新しくなり、PR に常に最新の会話が表示されるようになりました (図 39) 。  自分が作成した PR については、あるユーザーが新しいコメント スレッドを追加したり、既存のスレッドに返信を追加したりしたとき、自動的に通知が届きます。 他のユーザーの PR にコメントすると (コメント スレッドを作成したり、コメント スレッドに返信したりすると)、その後返信があったときに通知が届きます。  

このような通知機能は、難しい設定の要らないサブスクリプションに含まれています。 [通知] 設定ページで変更できます。 

Package Management の機能強化

操作性が新しくなった Package Management

Package Management を更新した結果、操作がさらに簡単になりました。ユーザーから報告があった問題に対処しています。また、今後予定されているパッケージ ライフサイクル機能のための場所が用意されました (図 40) 。  更新の詳細については、Updated experience (新しくなった操作性) ページを参照してください。

パッケージ管理に npm README とダウンロード ボタンを追加

パッケージに README.md を含む npm パッケージの README が表示されるようになりました (図 41) 。 README は、パッケージに関する知識をチームが記録し、共有する際に役立ちます。

コマンド バーの [ダウンロード] ボタンで npm パッケージをダウンロードすることもできます。

NuGet 復元および NuGet コマンド ビルド タスク

NuGet インストーラー (NuGet 復元に名称変更) タスクが大幅に更新されました。また、新しい NuGet タスクとして、NuGet コマンド が追加されました。 最も注目に値するところでは、NuGet コマンド タスクと NuGet 復元タスクで nuget.exe 4.0.0 が既定で使用されるようになりました。

NuGet 復元は、Visual Studio ビルド手順の前にパッケージを復元するという最も一般的なシナリオに合わせて最適化されました。 1 つの NuGet フィードを共有する小規模プロジェクトのサポートも改善されました。チーム サービス フィードを選択し、自動生成された NuGet.Config に追加できるようになりました。

より複雑な NuGet 操作のために、NuGet コマンド タスクであらゆるコマンドや引数セットを指定できるようになりました (図 42) 。

ビルドとリリースの機能強化

新しいビルド定義エディター

ビルド定義エディターのデザインを変更しました。さらに直観的な操作が可能になり、いくつかの弱点が修正され、新しい機能が追加されました。 テンプレートの使用、タスクの追加、設定の変更が簡単になったと考えております。 また、プロセス パラメーターを使用できるようになりました。最も重要なデータを簡単に指定できるようになりました。タスク内をあちこち閲覧する必要がありません。

テンプレートの検索

必要なテンプレートを探して適用するか、空のプロセスから始めます (図 43) 。

タスクを簡単に見つけ、必要な場所に追加する

使用するタスクを検索します。見つかったら、左側で現在選択されているタスクの後に追加できます。あるいは、必要な場所にドラッグ アンド ドロップすることができます (図 44) 。

タスクはドラッグ アンド ドロップで移動することもできます。あるいは、Ctrl キーを押しながらドラッグ アンド ドロップすると、タスクをコピーできます。

プロセス パラメーターを利用し、主要な引数をタスクに渡す

ビルド定義やテンプレートを利用する場合、プロセス パラメーター (図 45) を利用すれば、最も重要なデータを簡単に指定できます。タスク内をあちこち閲覧する必要がありません。

一部の組み込みテンプレート (Visual Studio や Maven など) から新しいビルドを作成する場合、そのしくみを示す例を参照できます。   新しいエディターは他の面でもいくつか機能強化されています。たとえば、ソース設定を簡単に表示できるようになりました。

新しいエディターで最初のビルド定義を作成するためのチュートリアルが必要な場合、初心者のための CI/CD ページをご覧ください。

詳細については、2017 ユーザー エクスペリエンス ページをご覧ください。

複数バージョンの拡張機能タスク

拡張機能の作成者は、特定のタスクについて複数バージョンの拡張機能を作成できるようになり、運用環境にあるメジャー バージョンごとに修正プログラムを出荷できます。

「Reference for creating custom build tasks within extensions」(拡張機能内でのカスタム ビルド タスクの作成に関するリファレンス) をご覧ください。

条件付きビルド タスク

整頓作業や異常時のメッセージ送信などのビルド タスクをさらに制御するために、4 つの選択肢が組み込まれ、実行するタスクをより制御できるようになりました (図 46) 。

特定のブランチ上でのみタスクを実行するなど、特定のトリガーでさらに細かく操作するために、カスタム条件を作成できます。

and(failed(), eq(variables['Build.Reason'], 'PullRequest'))

タスクを実行する条件の指定方法に関するページをご覧ください。

コンテナー ベースのアプリケーションを構築し、デプロイするための組み込みタスク

今回のリリースでは、Docker 拡張のほとんどのタスクが改善され、既定でこの製品に入りました。新しいタスクとテンプレートが導入され、一連のコンテナー シナリオの実現が簡単になりました。

• Docker: Docker イメージをビルド、プッシュ、実行するか、Docker コマンドを実行します。 このタスクは Docker または Azure コンテナー レジストリで利用できます。 ACR による組み込みのサービス プリンシパル認証を利用できるようになり、さらに使いやすくなりました。
• Docker-Compose: 複数コンテナー Docker アプリケーションをビルド、プッシュ、実行します。 このタスクは Docker または Azure コンテナー レジストリで利用できます。
• Kubernetes: kubectl コマンドを実行して、Azure Container Service で Kubernetes クラスターをデプロイ、構成、更新します。
• Service Fabric: Service Fabric クラスターにコンテナーをデプロイします。 Service Fabric は現在、クラウドで Windows コンテナーを実行するために最適な選択肢です。

Azure Web App デプロイ更新

Azure Web App のさまざまな機能を強化しました。

• Azure App Service デプロイ タスクでは、Java WAR ファイル、Node.js、Python、PHP アプリケーションをデプロイできます。
• Azure App Service デプロイ タスクでは、コンテナーを利用し、Azure Web App for Linux にデプロイできます。
• Azure Portal の継続的デリバリー機能が強化され、ノード アプリケーション対応になりました。
• Azure App Service 管理タスクが、Azure App Service の開始、停止、再開、スロット スワップに追加されました。 また、サイト拡張をインストールし、必須の PHP または Python バージョンを有効にしたり、IIS Manager または Application Insights をインストールしたりできるようになりました。

また、CI/CD を構成するための CI/CD サポートを最新版の Azure CLI に導入しました。 次に例を示します。

az appservice web source-control config --name mywebapp --resource-group mywebapp_rg --repo-url https://myaccount.visualstudio.com/myproject/_git/myrepo --cd-provider vsts --cd-app-type AspNetCore

.NET Core タスクがプロジェクト ファイルに対応

最新の更新プログラムでは、project.json に加え、*.csproj ファイルをサポートするように .NET コア タスクを機能強化しています。 ビルド エージェントで Visual Studio 2017 を使用し、csproj ファイルで .NET コア アプリケーションを開発できるようになりました。

SSH デプロイ機能強化

SSH によるファイルのコピー ビルド/リリース タスクで、宛先パスにチルダ (\~) を使用できるようになりました。リモート ユーザーのホーム ディレクトリにファイルをコピーする作業が簡単になりました。   また、コピーするファイルが見つからないときにビルド/リリースを実行しないオプションが追加されました。

SSH ビルド/リリース タスクの利用時、リモートの Linux または macOS コンピューターで Windows 行末のスクリプトを実行できるようになりました。

ビルドまたはリリース中に SSH キーをインストールする

SSH キーのインストール (プレビュー) という新しいプレビュー タスクでは、ビルドまたはリリースの前に SSH キーがインストールされ、ビルドまたはリリースの完了時にエージェントから削除されます。 インストールしたキーは、Git リポジトリまたはサブモジュールからコードを取得するとき、デプロイ スクリプトを実行するとき、SSH 認証を必要とするその他の操作を実行するときに使用できます。 今後、この機能はパスフレーズやその他の機能に対応するように改善される予定です。

Visual Studio 2017 が指定されているがエージェントにない場合、タスクが失敗する

Visual Studio ビルド タスクと MSBuild タスクでは、特定のバージョンの Visual Studio を選択できます。 今までは、Visual Studio 2017 バージョンを利用できない場合、次に利用できるバージョンが自動的に選択されていました。

この動作を変更しています。 Visual Studio 2017 を選択したがエージェントにない場合、ビルドは失敗します。

この変更を行った理由:

• .NET Core のような新しい種類のアプリは以前のビルド ツールでコンパイルされません。 Visual Studio 2017 以降を必要とします。

• まったく同じバージョンの Visual Studio を使用したときに、一貫性と予測可能性に優れた結果が得られます。

• ビルド タスクがフォール バックすると、解釈が難しいコンパイル エラーが発生することがあります。

プライベート エージェントの自動ワークスペース クリーンアップ

古くなった作業ディレクトリやリポジトリを定期的にクリーンアップするようにエージェント プールを構成できるようになりました (図 47) 。 たとえば、プールでは、ビルドやリリースの定義が削除された後に残されたワークスペースが削除されます。

このオプションを利用すると、プライベートのビルドまたはリリース エージェントがディスク領域不足になる可能性が減ります。 この保守管理は (コンピューター単位ではなく) エージェント単位で行われます。そのため、1 台のコンピューターに複数のエージェントがある場合、ディスク領域問題に遭遇する可能性があります。

ビルド エージェントのアップグレード状態

エージェントがアップグレードされるとき、キューとプールの管理ポータルにアップグレードの状態が表示されるようになりました。

使用されていないコンピューターでプライベート エージェントを選択する

ビルドまたはリリースをプライベート エージェントに割り当てるとき、コンピューター名が決定要素として使用されるようになりました。 結果的に、ジョブを割り当てるとき、ビジー状態のコンピューターのエージェントより、アイドル状態のコンピューターのエージェントが優先されます。

パイプライン キュー

エージェント ベースの価格モデルから、パイプライン ベースの価格モデルに移行しました。 この新しいモデルでは、ユーザーは自分のアカウントで構成されているパイプラインの数と同じ数のビルドまたはリリースを同時に実行できます。 この制限を超えて追加したビルドおよびリリースは、キューに入れられて、前のビルドおよびリリースが完了するのを待機します。 パイプライン キュー機能は、ビルドまたはリリースの現在の状態に関する詳しい情報をユーザーに提供します。

パイプライン キューの起動時には、次の情報を確認できます。

1. パイプラインによる実行を待っているビルドおよびリリースと、待機キュー内でのそれぞれの位置。 2. 使用可能なパイプラインを使って現在実行されているビルドおよびリリース。

ビルド/リリースがパイプラインを待機している間に、ビルド/リリース ログ ページ内からこのビューを直接起動し、パイプライン キュー内での現在位置や他の詳細を検索することもできます。

ビルドの概要でのリリース アクション

[リリース] アクションを [ビルド] 概要アクション バーで使用できるようになり、ビルドのリリースを簡単に作成できます。

変数グループのセキュリティ

変数グループのセキュリティを、作成者や管理者などの一連のロールで管理できるようになりました。

既定では、次のロールが割り当てられます。

• 共同作成者に対しては作成者ロール
• プロジェクト コレクション管理者、プロジェクト管理者、ビルド管理者、リリース管理者に対しては管理者ロール
• 有効なプロジェクト ユーザーに対しては閲覧者ロール

すべての変数グループまたは特定の変数グループについて、既定の設定をオーバーライドできます。

iOS DevOps の機能強化

Apple App Store 拡張は 2 段階認証 (2 要素認証) 対応になりました。また、ビルドを外部テスターに公開できるようになりました (図 48) 。

Apple 証明書のインストール (プレビュー) は、後続の Xcode または Xamarin.iOS ビルドで使用するために、エージェントに P12 署名証明書をインストールする新しいビルド タスクです。

Apple プロファイルのインストール (プレビュー) は、後続の Xcode または Xamarin.iOS ビルドで使用するために、エージェントにプロビジョニング プロファイルをインストールする新しいビルド タスクです。

MSBuild、Xamarin.Android、Xamarin.iOS ビルド タスクでは、Visual Studio for Mac ツール セットでビルドできるようになりました。

Java コード カバレッジの機能強化

コード カバレッジ結果の発行ビルド タスクでは、ビルドの一環として Cobertura または JaCoCo のコード カバレッジが報告されます。   [概要ファイル] フィールドと [レポート ディレクトリ] フィールドにワイルドカードや minimatch パターンを指定できるようになりました。ビルドによってパスが変わる場合、ビルド基準でファイルやディレクトリを解決できます。

Maven と SonarQube の機能強化

Maven ビルド タスクで、SonarQube プロジェクトを指定できるようになりました。分析結果に関して、Maven pom.xml ファイルに指定されているものとは異なる場合に役立ちます。

Jenkins 統合の機能強化

Jenkins キュー ジョブ ビルド/リリース タスクで、Team Services に Jenkins コンソール出力を表示しているとき、Jenkins マルチブランチ パイプライン ジョブを実行できるようになりました (図 49) 。   パイプライン結果が Team Services ビルド概要に公開されます。

Azure 仮想マシン スケール セットのデプロイ

デプロイに使用されている一般的なパターンは、アプリケーションのバージョンごとにマシンのフル イメージを作成し、それをデプロイするというものです。 その作業を簡単にするために、不変のマシン イメージの作成タスクを新しく用意しました。 このタスクでは Packer を利用し、アプリケーションとすべての必須要件をデプロイした後にマシン イメージを生成します。 このタスクではデプロイ スクリプトと Packer 構成テンプレートのいずれかを利用し、マシン イメージを作成し、それを Azure Storage アカウントに保存します。 このイメージは、この種類の不変イメージ デプロイと連動する Azure 仮想マシン スケール セット デプロイに利用できます。

Azure リソース グループ デプロイのテンプレート パラメーターのオーバーライド

Azure リソース グループ デプロイ タスクでは現在のところ、ユーザーは template.json と parameters.json を選択し、特定の構文に従い、テキスト ボックスのオーバーライド パラメーター値を提供します。 この機能が強化され、編集とオーバーライドを可能にするグリッドでテンプレート パラメーターが表示されるようになりました (図 50) 。 この機能を使用するには、オーバーライド パラメーター フィールドの横にある ... をクリックします。ダイアログが開き、テンプレート パラメーター、既定値、入力可能値 (テンプレートとパラメーターの .json ファイルに定義されている場合) が提示されます。 この機能を利用するには、ソースで CORS ルールを有効にする必要があります。 テンプレートとパラメーターの json ファイルが Azure Storage BLOB にある場合、「zure Storage Services documentation」(Azure Storage サービス ドキュメント) を参照して CORS を有効にしてください。

複数のリリース トリガー、ブランチ、タグ フィルター

リリース管理では、種類が “ビルド” の複数の成果物ソースに CD トリガーを設定できるようになりました。 追加すると、指定の成果物ソースで新しい成果物バージョンが利用できるようになったとき、新しいリリースが自動的に作成されます。 リリースをトリガーするとき、新しいビルドのソースにするソース ブランチも指定できます。 また、タグ フィルターを設定し、リリースをトリガーするビルドをさらに絞り込むことができます。

リリースの成果物ソースの初期値設定

定義で成果物ソースをリンクするとき、リリースでデプロイする既定の成果物バージョンをユーザーは定義できます (図 51) 。 リリースが自動的に作成されると、すべての成果物ソースの既定バージョンがデプロイされます。

デプロイの依頼者と承認者の職掌分散

以前は、環境の所有者は、リリースを環境にデプロイする行為の承認をリリース作成者に禁止できました。 しかしながら、別のユーザーが作成したリリースのデプロイを手動で開始し、自分で承認できました。

デプロイの作成者を別個のデプロイ ユーザー ロールととらえることでこの欠陥が解消されました。 リリース作成者とデプロイ作成者のいずれかにデプロイの承認を禁止できます。

リリース レベルの承認

別の環境に正常にデプロイされた後に自動的にトリガーされたデプロイの自動承認を選択できるようになりました (図 52) 。 1 つ 1 つすべてのデプロイを承認しないことを選択した場合、(承認者が同じ) 一連のデプロイの承認を 1 回で完了できます。

たとえば、Dev という環境と Test という環境がある場合、事前デプロイの承認者は "userA" と "userB" に設定されています。いずれにもデプロイの承認が要求されます。 Test のポリシーが下の画像のように設定されている場合、デプロイ中、userA と userB が Dev だけを承認すれば十分となります。 Test へのデプロイは自動承認されます。 Test へのデプロイが手動でトリガーされる場合、正しく承認するには、デプロイの前に承認が必要になります。

Azure Government Cloud へのデプロイ

政府クラウドで Azure サブスクリプションをご利用のお客様は、国内のクラウドを対象とするように Azure Resource Manager サービス エンドポイントを構成できるようになりました。

この機能により、Release Management を利用して、政府クラウドにホストされている Azure リソースに同じデプロイ タスクを使用してアプリケーションをデプロイできます (図 53) 。

並行デプロイの最大数の設定

この機能では、複数の保留リリースを特定の環境にデプロイする方法を制御できます (図 54) 。 たとえば、QA 環境でリリース パイプラインがビルドを検証するとき、ビルドの生成率がデプロイの完了率より速ければ、並列で検証されるように複数のエージェントと同じ数のビルドを構成できます。 つまり、生成されたビルドが 1 つ 1 つ検証され、待ち時間は利用できるエージェントの数に依存します。 この機能では、検証を最適化できます。最も新しい n 個のビルドを検証し、古いデプロイ要求をキャンセルできます。

手動介入タスクのタイムアウト機能強化

保留開始後、指定したタイムアウト機能強化期間と 60 日間のいずれかが先に到達したときに手動介入タスクを自動的に却下または再開できるようになりました。  タイムアウト値はタスクのコントロール オプション セクションで指定できます。 

リリース管理の並列実行

リリース管理で、あるフェーズに並列実行オプションを指定できるようになりました (図 55) 。 このオプションを選択すると、フェーズ乗数オプションとして複数構成と複数エージェントのいずれかを利用し、フェーズがファンアウト (展開) されます。

複数構成:このオプションを選択すると、複数構成値ごとにフェーズが実行されます。 たとえば、2 つの異なる地域に同時にデプロイする場合、値 "east-US, west-US" を含む [変数] タブに定義されている変数 ReleasePlatform を使用すると、フェーズが並列実行されます。1 つは値 "east-US" で、もう 1 つは値 "west-US” で実行されます。 複数エージェント:このオプションを選択すると、複数のエージェントの 1 つまたは複数のタスクでフェーズが並列実行されます。

Azure Portal における Web アプリのデプロイの履歴

リリース管理では、App Service デプロイ タスクを利用してデプロイを完了したとき、Azure App Service のデプロイ ログが更新されるようになりました。 [App Service] ブレードで [継続的デリバリー] オプションを選択すると、Azure Portal でデプロイの履歴を表示できます。

テストの機能強化

エージェント フェーズを利用したテスト実行

Visual Studio テスト タスクを利用し、自動化されたテストをエージェント フェーズを利用して実行できるようになりました (図 56) 。

ビルド、リリース、テストの自動化エージェントが統一されました。 これには、次のような利点があります。

1. テストに必要であれば、エージェント プールを活用できます。
2. ニーズに基づき、同じ Visual Studio テスト タスクを使用して、さまざまなモードでテストを実行します。モードには、単一エージェントベースの実行、複数エージェントベースの分散されたテスト実行、または複数構成の実行があり、これらのモードを使用して、異なるブラウザーなどでテストを実行します。

詳細については、アプリケーション ライフサイクル管理に関するこの投稿をご覧ください。

自動化されたテストのオンデマンド トリガー

テスト ハブでは、テスト計画やテスト スイートから自動化されたテストをトリガーできるようになりました (図 57) 。 テスト ハブから自動化されたテストを実行するには、リリース環境でテストをスケジュール実行する場合と同様の設定が必要になります。 Run automated tests from test plans (自動化されたテストをテスト計画から実行) テンプレートを利用し、リリース定義に環境を設定し、自動化されたテストを実行するテスト計画を関連付ける必要があります。 環境を設定し、テスト ハブから自動化されたテストを設定する方法についてはこのドキュメントをご覧ください。詳細な説明があります。

ウェアハウスの機能強化

Analysis Services キューブ処理でのパフォーマンスの向上

vDimWorkItemTreeOverlay ビューのパフォーマンスが向上されました。このビューは、リンクに基づいて作業項目ツリー階層ディメンションを作成する場合に使用します。 このビューは System.LinkTypes.Hierarchy リンクに依存していますが、処理時間について他のリンク (System.LinkTypes.Related など) も影響していることがわかりました。 データの読み取り量を制限している他の種類のリンクをスキップするようにビューを最適化しました。 この変更により、特定のウェアハウスの処理時間が大幅に短縮されます。

大文字と小文字の区別のあるスキーマの調整

ウェアハウス データベースのスキーマは、スキーマの調整プロセスにおいて、接続されているすべてのコレクション データベースからのフィールドを結合して作成されます。 以前は、すべての比較で大文字と小文字が区別されていたため、管理者はフィールド参照名を厳密に一致させる必要がありました。 この場合、大文字と小文字に少しの違いがあっても問題になっていました。 このリリースでは、そのような相違に対してプロセスが寛容になりました。

管理の機能強化

通知時に電子メールの受信者を結合する

同じ電子メール通知の受信者が宛先にまとめて表示され、1 回のメールで送信されるようになりました。 以前は、個別の電子メールが各受信者に送信されていました。 そのため、誰が通知を受け取ったか判別できず、電子メールでイベントについて知らせることは困難でした。 この機能は、Out-of-the-Box サブスクリプションと複数の受信者を宛先にできるチーム サブスクリプションに適用されます。 たとえば、pull request のすべてのレビュー担当者には、pull request が変更されたとき、1 件のメールが送信されるようになりました。

電子メール受信者の結合についてはこのページをご覧ください。

面倒な設定の要らない通知

ユーザーとチームに直接関連するアカウントで動きがあったとき、該当するユーザーとチームに自動的に通知が届くようになりました。たとえば、次のタイミングで送信されます。

• 作業項目がユーザーに割り当てられたとき。
• ユーザーまたはチームがレビュー担当者として pull request に追加されたとき。
• ユーザーまたはチームがレビュー担当者になっている pull request が更新されたとき。
• 別のユーザーが pull request コメントに返信したとき。
• ユーザーが要求したビルドが完了したとき。
• 拡張機能がインストールまたは要求されたとき (管理者のみ)。

ユーザー プロファイル メニューの [通知] 設定に移動して、該当するトグルをオフに切り替えることで、ユーザーは以上のサブスクリプションを解除できます。

アカウント管理者は 1 つまたは複数の自動サブスクリプションを無効にできます。設定歯車からコレクション レベルの [通知] ハブを開いてください。 "..." アクションの下にある [無効にする] をクリックすると、サブスクリプションが無効になります。 サブスクリプションを無効にすると、ユーザーの個人通知設定ページから表示が消えます。

面倒な設定の要らない通知の詳細についてはここをご覧ください。

拡張管理のアクセス許可

管理者は、コレクションの拡張機能を管理するアクセス許可をユーザーやグループに与えることができるようになりました (図 58) 。 以前は、コレクション管理者 (Project Collection Administrators グループのメンバーなど) のみが拡張要求を確認し、拡張機能をインストール、無効化、アンインストールできました。 

このアクセス許可を与えるには、管理者は Marketplace メニューを開き、拡張機能の管理を選択して拡張機能管理ハブに移動します。それから、セキュリティ ボタンをクリックします。

拡張機能がインストールされたときや注意が必要なときなどに通知を受け取る

管理者または拡張機能を管理する資格が与えられているユーザーには、拡張機能がインストール、アンインストール、有効化、無効化されたとき、あるいは注意が必要なとき、自動的に通知が届くようになりました。 これは、複数のユーザーが拡張機能の管理を担当するような大規模デプロイで特に役立ちます。 管理者はこのような通知をオフにできます。プロファイル メニューの [通知] 設定を開き、拡張機能のスイッチをオフにします。

管理者は拡張機能関連のイベントに独自のサブスクリプションを定義することもできます。 たとえば、拡張機能が更新されるたびに管理者が通知を受け取るように定義できます。

ユーザーも、拡張機能要求に関する自動通知をオフにできるようになりました。

詳細アクセス レベルにサブスクライバーを追加することを TFS 管理者に許可する

詳細アクセス レベルは Team Foundation Server の将来のバージョンから削除されます。 ただし、削除されるまでは、MSDN Platform と Visual Studio Test Professional のサブスクライバーを詳細アクセス レベルに追加する権限が更新プログラム 2 で TFS 管理者に与えられる予定です。

Visual Studio Enterprise サブスクライバーは詳細ではなく Visual Studio Enterprise アクセス レベルに追加してください。 Test Manager 拡張を購入している場合、購入したチーム プロジェクト内のユーザー ハブで引き続きこれを管理してください。

Microsoft Teams の統合

Microsoft Teams を使用して共同作業を行っている組織は、チームのチャネル内で TFS のプロジェクトからアクティビティを確認できるようになりました。 これにより、チームは Microsoft Teams で作業しながら、関連する作業項目の変更、pull requests、ビルド、リリースなどについて最新の情報を取得することができます。 詳細については、こちら を参照してください。

---

既知の問題

作業項目フォームが Web で正しくレンダリングされない

• 問題:

  Web クライアント用ではなく、Visual Studio クライアント用に、複数値のコントロールなどのカスタム コントロールをインストールしている場合、作業項目フォームが Web で正しくレンダリングされません。

• 対応策 :

  コントロールを最新バージョンに更新する必要があります。 不足しているコントロール要素を含まない Web レイアウトを追加する必要があります。 TFS 2017 Update の最新の複数値コントロールは、TFS 作業項目追跡用のカスタム コントロールにあります。 レイアウトに関する詳細については、「すべての FORM XML 要素のリファレンス (TFS 2015)」ページをご覧ください。

TFS のバージョンが、最終リリースではなく RC2 である

• 問題:

  2017 年 8 月 1 日より前に TFS 2017 Update 2 をダウンロードしてインストールをした場合は、RC2 バージョンを所有しています。

• 対応策 :

  これは、2017 年 8 月 1 日に修正されたインストール リンクに断続的な問題があったことが原因です。 TFS 2017 Update 2 をもう一度ダウンロードして、この最終リリースをインストールしてください。

Team Foundation Server 2017 についてお客様から報告された問題をご覧ください。

---

フィードバックと提案

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

---

ページの先頭へ