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

Last Update: 2017/06/27

最新の更新プログラムを確認するには、英語版の「Release Notes」をご覧ください。

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

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

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


フィードバック

皆様のご意見をお待ちしております。 問題は開発者コミュニティ ポータルで報告し、追跡できます。 ご提案がございましたら、Visual Studio Team Services 製品の更新プログラム サイトからお寄せください。


リリース日: 2017 年 6 月 26 日

このリリースの更新の概要

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

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


このリリースの新機能

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

作業項目の種類アイコン

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

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

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

WIT クエリのアイコン

(図 1) クエリの色付きアイコン

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

ボードの種類アイコン

(Figure 2) ボードの種類アイコン

配信計画

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

配信計画のマーケットプレース ページをご覧ください。拡張の詳細を確認し、インストールできます。

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

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

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

WIT ビルド リンク

(図 3) WIT ビルド リンク

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

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

作業項目の検索

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

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

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

作業項目検索

(図 4) 作業項目検索

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

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

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

ブランチ ポリシーの構成

(図 5) ブランチ ポリシーの構成

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

ポリシー ページ

(図 6) ポリシー ページ

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

手動ビルド

(図 7) 手動ビルド

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

手動ビルドのキュー

(図 8) 手動ビルドのキュー

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

必須のレビュー担当者のダイアログ

(図 9) 必須のレビュー担当者のダイアログ

必須のレビュー担当者のメモ

(図 10) 必須のレビュー担当者のメモ

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

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

ファイル ハブの機能強化

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

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

ファイル表示

(図 11) ファイル表示

ファイル比較

(図 12) ファイル比較

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

ファイル編集

(図 13) ファイル編集

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

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

Git グラフ

(図 14) Git グラフ

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

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

Git グラフ要素

(図 15) Git グラフ要素

コミットの Git タグを見る

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

タグ表示

(図 16) タグ表示

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

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

タグ詳細の作成

(図 17) タグ詳細の作成

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

タグ履歴の作成

(図 18) タグ履歴の作成

タグ ブランチ

(図 19) タグ ブランチ

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

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

変更セット ページ

(図 20) 変更セット ページ

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

変更セット ディスカッション

(図 21) 変更セット ディスカッション

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

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

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

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

(図 22) コミット フィルター処理の強化

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

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

リポジトリの選択ドロップダウン

(図 23) リポジトリの選択ドロップダウン

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

リポジトリのインポート完了

(図 24) リポジトリのインポート完了

Git LFS ファイル ロック

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

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

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

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

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

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

新しいツリー ビュー

(図 25) 新しいツリー ビュー

プル要求の機能強化

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

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

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

オートコンプリート機能

(図 26) オートコンプリート機能

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

CTA 承認

(図 27) CTA 承認

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

コメントに基づく措置

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

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

PR ヘッダー

(図 28) PR ヘッダー

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

[解決] ボタン

(図 29) [解決] ボタン

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

返信と解決

(図 30) 返信と解決

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

コメントの対処数

(図 31) コメントの対処数

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

フィルターの機能強化

(図 32) フィルターの機能強化

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

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

更新ビュー

(図 33) 更新ビュー

プル要求をユーザー別にフィルタリング

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

ユーザー別のフィルタリング

(図 34) ユーザー別のフィルタリング

プル要求ポリシーの回避時の理由が必須

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

回避ダイアログ

(図 35) 回避ダイアログ

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

回避メッセージ

(図 36) 回避メッセージ

プル要求をチームと共有

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

チームと PR を共有

(図 37) チームと PR を共有

チームのためのプル要求の機能強化

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

チームのための PR 機能強化

(図 38) チームのための PR 機能強化

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

プル要求コメントの既定の通知

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

既定の PR 通知

(図 39) 既定の PR 通知

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

パッケージ管理の機能強化

操作性が新しくなったパッケージ管理

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

パッケージ管理

(図 40) パッケージ管理

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

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

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

パッケージ管理 npm README

(図 41) パッケージ管理 npm README

NuGet 復元、コマンド、ツール インストーラー ビルド タスク

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

NuGet ツール インストーラー__では、__NuGet 復元__タスクと __NuGet コマンド タスクの両方で使用される NuGet バージョンを管理できます。 既定では、テスト済みの既知のバージョンがタスクで使用されます。 それをオーバーライドする場合、他の NuGet ビルド手順の前に __NuGet ツール インストーラー__手順を追加します。

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

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

NuGet コマンド

(図 42) NuGet コマンド

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

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

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

テンプレートの検索

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

テンプレート検索の構築

(図 43) テンプレート検索の構築

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

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

タスク検索の構築

(図 44) タスク検索の構築

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

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

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

プロセス パラメーター

(図 45) プロセス パラメーター

一部の組み込みテンプレート (Visual StudioMaven など) から新しいビルドを作成する場合、そのしくみを示す例を参照できます。

新しいエディターは他の面でもいくつか機能強化されています。たとえば、ソース設定を簡単に表示できるようになりました。

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

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

条件付きビルド タスク

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

条件付きビルド タスク

(図 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 を使用したときに、一貫性と予測可能性に優れた結果が得られます。

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

ヒント

以前のバージョンの Visual Studio しかないエージェントではなく、Visual Studio 2017 があるエージェントを含むプールと接続されているキューを必ず使用してください。

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

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

エージェント保守管理

(図 47) エージェント保守管理

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

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

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

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

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

iOS DevOps の機能強化

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

Apple App Store 接続

(図 48) Apple App Store 接続

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 ビルド概要に公開されます。

Jenkins 統合の機能強化

(図 49) Jenkins 統合の機能強化

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

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

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

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

Azure RG パラメーター

(図 50) Azure RG パラメーター

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

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

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

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

既定の成果物バージョン

(図 51) 既定の成果物バージョン

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

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

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

リリース レベルの承認

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

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

リリース レベルの承認

(図 52) リリース レベルの承認

Azure Government Cloud へのデプロイ

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

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

政府クラウド

(図 53) 政府クラウド

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

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

並列デプロイ

(図 54) 並列デプロイ

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

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

リリース管理の並列実行

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

並列実行サポート

(図 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 テスト タスク__を利用し、さまざまなモードでテストを実行します。単一エージェントに基づく実行や複数エージェントに基づく分散テスト実行です。あるいは、複数構成実行で、たとえば、さまざまなブラウザーでテストを実行します。

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

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

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

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

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

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

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

管理の機能強化

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

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

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

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

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

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

ユーザーは以上のサブスクリプションを解除できます。ユーザー プロファイル メニューの [通知] 設定を開き、該当するスイッチをオフにします。

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

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

拡張管理のアクセス許可

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

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

拡張機能管理のアクセス許可

(図 58) 拡張機能管理のアクセス許可

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

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

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

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

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

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

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


既知の問題

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

  • 問題:

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

  • 対応策 :

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


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