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

  • [アーティクル]

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

Note

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

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

Team Foundation Server の最新バージョンをダウンロードする

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

Team Foundation Server 2018 Update 2 への直接アップグレードは TFS 2012 以降からサポートされています。 TFS が TFS 2010 以前に展開されている場合は、TFS 2018 Update 2 にアップグレードする前に中間手順をいくつか実行する必要があります。 詳細については、下記の表と、TFS のインストール ページを参照してください。

TFS アップグレードのマトリックス
TFS アップグレードのマトリックス

重要

TFS 2018 Update 2 にアップグレードする前に、TFS 2018 RTM にアップグレードする必要はありません。

リリース ノート アイコンリリース日: 2018 年 5 月 7 日

TFS 2018 Update 2 にアップグレードできるようになりました。XAML コントローラーへの接続および XAML ビルドの実行は引き続き行うことができます。 TFS 2018 RTW および Update 1 で XAML ビルドのサポートが削除されたときに、一部のお客様はレガシ XAML ビルドをご使用になっている関係上、アップグレードができませんでした。ブロックを解除します。 TFS 2018 Update 2 ではレガシ ビルドに対応するために XAML ビルドをサポートしていますが、XAML ビルドは非推奨となっており、今後投資は行われませんので、新しいビルド定義形式への変換をお勧めします。

TFS 2018 Update 2 の新機能の概要

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

TFS 2018 Update 2 の新機能の詳細

各領域の機能の詳細を確認できます。

コード

ファイルを表示しているとき、通常、選択したブランチのヒントにバージョンが表示されます。 ヒントに表示されるファイルのバージョンは、新しいコミットで変わることがあります。 このビューからリンクをコピーした場合、URL にコミット SHA ではなく、ブランチ名のみが含まれるため、リンクが無効になることがあります。 それが今回の更新で、ファイル ビューを簡単に切り替え、URL を更新し、ブランチではなくコミットを参照できるようになりました。 "y" キーを押すと、現在のブランチのヒント コミットに表示が切り替わります。 その後、永続リンクをコピーできます。

最近削除されたリポジトリを API を介して復元する

ソース管理の以前のリポジトリを整理しているとき、間違って削除することがあります。 Git リポジトリが削除されてから 30 日経過していない場合、REST API でそのリポジトリを復元できます。 詳細については、一覧表示操作と復元操作に関する文書を参照してください。

SSH:追加の暗号または鍵のサポートと旧式の暗号の廃止

セキュリティと互換性を向上させるために、SSH でサポートされている暗号の一覧を更新しました。 OpenSSH の方針に合わせ、新しい暗号を 2 つ追加し、3 つを非推奨としました。 非推奨となった暗号はこのリリースでは引き続き動作します。 将来、使われなくなったときに削除される予定です。

追加:

  • AES128 CTR
  • AES256 CTR

非推奨:

  • AES128
  • AES192
  • AES256

リポジトリ設定を利用して上書きを回避し、パフォーマンスの低下を防ぐ

今回の更新プログラムには、Git の円滑な運営を維持するための新しいリポジトリ設定が 2 つあります。

大文字と小文字の区別の強制では、"File.txt" と "file.txt" が同じファイルを指す、サーバーの既定である大文字と小文字を区別するモードから、"File.txt" と "file.txt" が同じファイルである、Windows と macOS にとって使いやすいモードに切り替えられます。 この設定は、ファイル、フォルダー、ブランチ、タグに適用されます。 また、投稿者が誤って大文字と小文字が違うだけであるものを投稿しないようにすることができます。 投稿者の多くが Windows または macOS を実行しているときは、大文字と小文字の区別の強制を有効にすることをお勧めします。

ファイル サイズの制限では、設定したサイズ制限を新しいファイルや更新されたファイルが超えないようにします。 Git リポジトリの履歴に存在する大きなファイルの数が多くなるほど、複製やフェッチの操作のパフォーマンスが悪くなります。 この設定によって、制限を超えるファイルが間違って移入されることがありません。

ケースの適用

1000 個以上のファイルを変更するコミットのフィルター機能の強化

1000 個を超えるファイルを変更したコミットまたはpull requests からファイルを検索するのは非効率的でした。関心のあるファイルを見つけるために、 [さらに読み込む] リンクを数回クリックする必要がありました。 それが現在、ツリー ビューでコンテンツにフィルターを適用すると、読み込まれた最初の 1000 ファイルを表示するのではなく、コミットのすべてのファイルを対象に目的のファイルを検索するようになりました。 1000 個以上のファイルが変更されているときのコミット詳細ページのパフォーマンスも改善されています。

強制プッシュによって失われたコミットを見つける

Git 強制プッシュを実行したり、リモート参照をそれがローカル参照の親要素でなくても更新したりできます。そのとき、他のユーザーがコミットを失うことがあり、根本原因の特定が非常に難しくなることがあります。 新しいプッシュ ビューでは、コミットをなくすることに関連する問題の解決に役立つように、強制プッシュを目立つようにしました。

フォース プッシュ

強制プッシュ タグをクリックすると、削除されたコミットに移動します。

削除されたコミット

変更履歴に記録が追加されました

変更履歴ビューは、コード行を最後に変更したユーザーを特定するのに適しています。 しかしながら、場合によっては、コード行を以前変更したユーザーを確認する必要があります。 変更履歴の最新の拡張機能、コミットする前に変更履歴を表示するが便利です。 この名前が示すように、この機能を利用すると、特定の行を変更したバージョンの前のファイル バージョンに戻り、そのバージョンの変更履歴を表示できます。 引き続き過去のバージョンに戻り、選択したコード行を変更したファイルの各バージョンを見比べることができます。

[非難履歴]

相違ビューの [右端で折り返す] と [空白の表示/非表示]

ファイルの相違ビューアーで新しい機能が 2 つ利用できるようになりました。 [右端で折り返す] と [空白の表示/非表示] です。 [右端で折り返す] では、相違ビューに入っているとき、右端での折り返し設定を適用できます。 これは特に、頻繁に改行しないファイルを含む PR をレビューするときに便利です。マークダウン ファイルが良い例です。 空白の表示/非表示を切り替えるオプションは、行かファイルで空白が変わったときにのみ便利です。 この設定を切り替えると、相違で空白文字が表示され、強調されます (たとえば、スペースをドットで、タブを矢印で表示します)。

このような設定を管理するには、pull request エディターまたは相違ビューでエディターのユーザー設定歯車をクリックします。 [ファイル] ビューの右クリック メニューで [ユーザー設定] オプションを選択します。

エディター の歯車

[空白を表示し、差分を取ります] 、 [ワード ラップを有効にする] 、 [コードの折りたたみを有効にする] 、 [ミニマップの表示] など、さまざまなエディター機能から選択します。

エディターのパフォーマンス

Web ビューの場合、コードの折りたたみ (エディターによっては "アウトライン表示" と呼ばれています) も有効になります。 コードの折りたたみが有効になっているとき、マイナス記号をクリックすると、コード セクションが折りたたまれます。プラス記号をクリックすると、折りたたまれているセクションが展開されます。 F1 コマンド パレットにも、ファイル全体でさまざまなインデント レベルを折りたたむためのオプションがあります。大きなファイルを読む作業が簡単になります。

コード フォールディング

Git リポジトリのトラック コード プッシュによるビルドとリリース

[プッシュ] ページでマージ コミットのビルド/リリース ステータスを閲覧できるようになりました。 プッシュの横にあるステータスをクリックすることで、そのプッシュが含まれている特定のビルドまたはリリースが見つかり、成功を確認したり失敗を調査したりできます。

ci-cd 状態をプッシュします

電子メール通知のレンダリングされたマークダウン

リッチ書式設定、リンク、pull request (PR) の画像、説明、コメントの追加にはマークダウンが最適です。 PR の電子メール通知に、生コンテンツの代わりに、レンダリングされたマークダウンが表示されるようになり、読みやすくなりました。

インライン イメージはレンダリングされたインラインではありませんが (単にリンクとして表示されます)、将来的にはバックログに追加される予定です。

PR 通知マークダウン

Windows エクスプローラーから直接 TFVC コマンドを実行する

Windows のエクスプローラーに統合され、コントロールを軽くする TFVC Windows Shell Extension が TFS 2018 対応になりました。 このツールでは、Windows エクスプローラーのコンテキスト メニューで直接、さまざまな TFVC コマンドにアクセスできて便利です。

以前は TFS Power ツールに含まれていたこのツールが Visual Studio Marketplace でスタンドアロン ツールとしてリリースされました。

シェル拡張機能

pull requests に参加できるユーザーの管理

以前は、Git リポジトリを閲覧できる誰もがその pull requests を操作できました。 Microsoft は [pull requests への参加] という名称の新しいアクセス許可を追加しました。pull requests を作成したり、それにコメントを付けたりするためのアクセス許可を制御します。 以前読み取りアクセス許可を保持していたすべてのユーザーとグループには、この新しいアクセス許可も既定で与えられます。 この新しいアクセス許可を導入することで、管理者にとってさらに柔軟な管理が可能になります。 閲覧者グループを厳密に読み取り専用にする必要がある場合、 [pull requests への参加] アクセス許可を拒否できます。

詳細については、リポジトリ アクセス許可の設定に関するクイック スタート文書を参照してください。

Pull request のコメント通知にスレッド コンテキストが含まれる

多くの場合、pull request (PR) コメントの返信はかなり短く、変更が行われる予定であるか、既に行われていることを認めるものです。 Web ビューでこのようなコメントを閲覧するときは問題ありませんが、電子メール通知でコメントを読む場合、元のコメントのコンテキストが失われてしまいます。 シンプルに "私がそれを修正します" だけでは、何のことかわかりません。

今回から、PR コメントに返信があったときは常に、コメント電子メールのメッセージ本文に前の返信が含まれるようになります。 それによって、スレッド参加者は自分の受信トレイからコメントのコンテキストをすべて確認できます。Web ビューを開く必要がありません。

PR コメント通知スレッド

作業項目を完了にする設定

pull requests が完了したときに作業項目を完了にする機能に、既定の動作を制御する新しいリポジトリ設定が追加されました。 [pull requests で作業項目を完了するためにユーザー設定を記憶する] の新しい設定は既定で有効になり、リポジトリで今後 pull requests を完了するときに、ユーザーの最後の状態が適用されます。 新しい設定が無効になっている場合、リポジトリのすべての pull requests に対して [リンクされた作業項目をマージ後に完了する] オプションが既定で無効になります。 ユーザーは引き続き、PR の完了時にリンクされている作業項目を変更できますが、毎回選択する必要はありません。

Pull request のステータスの拡張性

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

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

status セクション

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

status policy add

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

状態ポリシー ダイアログ

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

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

Pull request サービス フックのマージ イベント

pull request サービス フックを利用した拡張機能にさらに細かな調整が加わり、マージ イベントにフィルターを適用できるようになりました。 マージが試行されるたびに、その成功と失敗に関係なく、イベントが発生します。 マージを試行した結果、失敗となった場合、失敗理由に関する詳細が含まれます。

PR サービスはマージ イベントをフックします

pull request による作業項目完了のエラー メッセージの改善

pull request で作業項目の完了を試行したとき、関連付けられている作業項目を完了状態に変更できないことがあります。 たとえば、特定のフィールドが必須になり、状態を変更する前にユーザー入力が必要になることがあります。 この動作を改善し、何かが作業項目の変更を阻止しているとき、ユーザーに通知が届くようにしました。ユーザーは必要な措置をとることができます。

エラー作業項目 PR

pull request のメンション

PR コメントと作業項目ディスカッションで pull requests をメンションできるようになりました。 PR のメンションは、作業項目のメンションに似ていますが、ハッシュ マーク # の代わりに感嘆符 ! が使用されます。

PR をメンションするときは必ず ! を入力します。対話式に最近の PR の一覧から PR を選択できます。 キーワードを入力して候補一覧を絞り込んだり、メンションする PR の ID を入力したりします。 PR がメンションされたら、ID と完全なタイトルと共にインラインでレンダリングされ、さらに PR の詳細ページにリンクされます。

pull request をメンションする

pull request ラベルを利用してレビュー担当者を支援する

pull request に関する追加情報をレビュー担当者に伝えることが重要になる場合があります。 たとえば、pull request が依然進行中であることや、予定されているリリースの修正プログラムのことなどです。そこで、"[WIP]" プレフィックスや "DO NOT MERGE" のように、タイトルにテキストを追加します。 ラベルという機能では、重要な詳細を伝える追加情報のタグを pull requests に付けることができます。これはまた、pull requests の整理に役立ちます。

PR 要求ラベル

ファイル名の変更後も Pull request のコメントが続けられる

pull request がアクティブの間にファイルの名前が変更されたり、ファイルを移動したりすることがあります。 以前は、名前を変更したファイルにコメントがあった場合、コードの最新のビューにそのコメントが表示されませんでした。 今回、コメント追跡機能を強化し、名前変更を追いかけるようにしました。名前を変更したファイルや移動したファイルの一番新しいバージョンにコメントが表示されます。

pull request のマージ コミットを表示する

Pull request の相違ビューでは、ソース ブランチで行われた変更が強調表示されます。 ただし、ターゲット ブランチを変更すると、相違ビューが予想とは異なる外観になることがあります。 pull request の "プレビュー" マージ コミットの相違を表示する新しいコマンド、 [マージ コミットを表示] を利用できるようになりました。 このマージ コミットは、マージの競合を確認し、pull request ビルドと共に使用するために作成されます。pull request が最終的に完了したときのマージ コミットの外観を反映します。 ターゲット ブランチが変更されたが相違で反映されていないとき、ソース ブランチとターゲット ブランチの両方で最終的な変更を確認するとき、マージ コミットの相違が役に立つことがあります。

pull request マージ コミットを表示する

[マージ コミットを表示] コマンドと連動して役立つもう 1 つのコマンドが、 [マージの再開] です (同じコマンド メニューにあります)。 pull request が最初に作成されてからターゲット ブランチが変更された場合、このコマンドを実行すると、新しいプレビュー マージ コミットが作成され、マージ コミットの相違ビューが更新されます。

最近使用したレビュー担当者

コードを同じ人物に何度もレビューしてもらっていたのであれば、今までより簡単にレビュー担当者を追加できるようになったことに気付くでしょう。 レビュー担当者を pull requests に追加するとき、レビュー担当者の入力ボックスにフォーカスを合わせると、最近追加されたレビュー担当者の一覧が自動的に表示されます。名前で検索する必要がありません。 自動的に表示された担当者を通常どおり選択します。

MRU レビュー担当者

pull request オートコンプリートの残りのポリシー条件の表示

ブランチ ポリシーを利用するチームにとってオートコンプリートは便利な機能ですが、オプション ポリシーを利用するとき、pull request の完了を防いでいるものが厳密にわからないことがあります。 それが今回、pull request にオートコンプリートを設定すると、完了を止めているポリシー条件の厳密な一覧が吹き出しボックスにわかりやすく表示されます。 各要件が満たされると、残りの要件がなくなり、pull request がマージされるまで項目が一覧から削除されます。

PR オートコンプリート リスト

pull requests のコメントに数式を含める

pull request のコメントに方程式や数学式を含める必要がありますか。 インラインとブロックの両方のコメント機能を利用し、コメントに KaTeX 関数を含めることができるようになりました。 詳細については、サポートされている関数の一覧をご覧ください。

数学を使用した PR マークダウン コメント

分岐のpull request 提案

トピック ブランチがリポジトリで更新されると、そのトピック ブランチの新しい pull request (PR) を作成しませんかという "提案" が表示されます。 この機能は、新しい PR を作成する際に非常に便利です。分岐のあるリポジトリで作業しているユーザーにも、この機能が有効になりました。 分岐でブランチを更新すると、分岐または上流リポジトリのいずれかで次回、コード ハブにアクセスしたときに、pull request の作成提案が表示されます。 "pull request の作成" リンクを選択すると、PR の作成ページに移動します。ソース ブランチ、ターゲット ブランチ、リポジトリが既に選択されています。

フォークの PR 提案

pull request ポリシーのパス フィルター

多くの場合、1 つのリポジトリには、ビルドを検証し、テストを実行するために、複数の継続的インテグレーション (CI) パイプラインでビルドされたコードが含まれます。 この統合ビルド ポリシーがパス フィルター対応となり、PR ごとに要求し、自動的にトリガーできる複数の PR ビルドを簡単に構成できるようになりました。 必要なビルドごとにパスを指定し、必要に応じて、トリガーと要件のオプションを設定します。

PR ポリシーのパス フィルター

ビルドに加え、状態のポリシーでも、パス フィルター オプションが利用できるようになりました。 これにより、カスタム ポリシーやサード パーティ ポリシーで特定のパスにポリシー適用を構成することができます。

作業

作業項目フォームのキーボード ショートカット

キーボード ショートカットを利用して自分自身に作業項目を割り当てたり (Alt + i)、ディスカッションに移動したり (Ctrl + Alt + d)、クイック リンクを作業項目にコピーしたり (Shift + Alt + c) できます。 新しいショートカットの完全な一覧を確認するには、作業項目フォームを開いて "?" と入力するか、または以下の表を参照してください。

作業項目フォームのキーボード ショートカット

最新の列のオプション

[バックログ] 、 [クエリ] 、 [テスト] ハブで作業項目グリッドの列を構成するための [列のオプション] ダイアログが更新され、新しいパネル設計を使用できるようになりました。 検索機能でフィールドを見つけたり、ドラッグ アンド ドロップで列を並べ替えたり、不要になった既存の列を削除したりできます。

最新化された列のオプション

クエリの最終実行者情報

プロジェクトの共有クエリ ツリーが大きくなると、クエリが使われなくなっているかどうかや、クエリを削除できるかどうかを判断するのが難しくなります。 共有クエリの管理を支援するために、クエリ REST API に新しいメタデータを 2 つ追加しました。最終実行者と最終実行日付です。クリーンアップ スクリプトを記述し、古くなったクエリを削除できます。

作業項目グリッドから HTML タグを取り除きました

お客様からのフィードバックに基づき、Web、Excel、Visual Studio IDE の作業項目クエリ結果ビューの複数行テキスト フィールドの動作を更新し、HTML 書式設定を削除しました。 複数行テキスト フィールドは、クエリに列として追加されるときに、プレーンテキストとして表示されるようになりました。 HTML は以下のように取り上げられていました。

HTML タグを削除する

以前は、クエリ結果は <div><b><u>Customer Value</u>... のようにレンダリングされていました。

クエリ演算子 Not In のサポートの追加

クエリ演算子 "In" をサポートするフィールドで、"Not In" がサポートされるようになりました。 ID 一覧に "Not In (含まれていない)" 作業項目や状態一覧に "Not In (含まれていない)" 作業項目を問い合わせるクエリを記述できます。いずれにおいても、多数の "Or" 句の入れ子を作成する必要はありません。

クエリ演算子に含まれていない

@MyRecentActivity と @RecentMentions のクエリ

ID フィールドの新しいクエリ マクロを 2 つ導入しました。重要な作業項目の検索に役立ちます。 @RecentMentions を利用すると、過去 30 日間に自分がメンションされた項目を表示できます。@MyRecentActivity を使用すると、最近表示または編集した作業項目を確認できます。

作業項目の追跡通知のカスタム フィールドとタグ フィルター

カスタム フィールドとタグの通知を、条件を使用して定義できるようになりました。これは、変更されたときだけでなく、特定の値に合致したときや、作業項目を設定できる、より信頼性の高い通知のセットを許可できます。

カスタム作業項目通知設定

担当作業項目ページのメンション サポート

[担当作業項目] ページに新しくメンション ピボットを追加しました。 このピボットの中で、過去 30 日以内で自分がメンションされた作業項目を確認できます。 この新しい表示を利用すれば、自分の入力を必要とする項目で迅速な措置をとり、自分が関連する会話を最新の状態に維持できます。

[自分の作業項目] に記載されている作業

この同じピボットは、Microsoft のモバイル エクスペリエンスを通じて利用することもでき、モバイルとデスクトップの両方で一貫性が維持されます。

メンションされた作業

プランにフィルターを適用する

Delivery Plans (デリバリー計画) 拡張機能で Microsoft の一般的なフィルタリング コンポーネントが使用されるようになりました。作業項目とボードに対して、Microsoft のグリッド フィルタリングと同じ操作性が与えられます。 このフィルタリング コントロールによって使い勝手が良くなり、チームの全員に一貫性のあるインターフェイスが与えられます。

プランのフィルター処理

更新されたプラン ナビゲーション

利用者の多くは特定のプランまたはプラン セットに関心があり、お気に入りを利用してコンテンツに簡単アクセスします。 第一に、プラン ハブを更新し、ディレクトリ ページではなく、最近アクセスしたプランに移動できるようにしました。 第二に、最近アクセスしたプランに移動したら、お気に入りピッカーを利用して別のプランに簡単に切り替えたり、階層リンクを利用してディレクトリ ページに戻ったりできます。

更新されたプランのナビゲーション

タスク ボードで要件/ユーザーを展開する/折りたたむ

スプリントのタスク ボードで、1 回のクリックですべての項目を展開するか、折りたたむことができるようになりました。

[折りたたみ] [タスク ボード] の展開

特定のユーザーにルールを回避するアクセス許可を与える

別のソースから作業項目を移行するとき、作業項目の元のプロパティをすべて保持することを組織が求めることが多々あります。 たとえば、バグを作成するとき、作成日と作成者の値を、それが最初に生成されたシステムから得た元の値のまま保持することがあります。

作業項目を更新する API に、このシナリオを可能にするルール回避フラグがあります。 以前は、その API 要求を行った ID がプロジェクト コレクション管理者グループに属する必要がありました。 ルール回避フラグを付けてこの API を実行するアクセス許可をプロジェクト レベルで追加しました。

バイパスルールの付与

ビルドとリリース

XAML ビルド

TFS 2015 では、Web ベースでクロスプラットフォームのビルド システムが導入されました。 TFS 2018 RTW または Update 1 では XAML ビルドがサポートされませんが、TFS 2018 Update 2 では XAML ビルドが再有効化されました。 XAML ビルドを移行することをお勧めします。

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

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

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

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

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

複数フェーズ ビルドの機能強化

これまで、フェーズを利用してビルド手順を整理したり、各フェーズで異なる要求を利用し、異なるエージェントを対象にしたりできました。 フェーズをビルドする機能がいくつか追加され、次のことが可能になりました。

  • フェーズごとに異なるエージェント キューを指定します。 つまり、たとえば次のことが可能になります。

  • 並列実行によりテストを速く実行します。 "マルチエージェント" として構成された並列処理と "VSTest" タスクが含まれるフェーズでは、構成されているエージェント カウント全体でテスト実行が自動的に並列処理されるようになりました。

  • 各フェーズで OAuth トークンにアクセスするスクリプトを許可するか、拒否します。 つまり、たとえば、ビルド フェーズでスクリプト実行を許可して REST API で VSTS と通信し、同じビルド定義で、テスト フェーズでスクリプト実行をブロックできます。

  • 特定の条件下でのみフェーズを実行します。 たとえば、前のフェーズが成功したときにのみ実行したり、メイン ブランチでコードをビルドしているときにのみ実行したりするようにフェーズを構成できます。

詳細については、「Phases in Build and Release Management」 (ビルドおよびリリース管理のフェーズ) を参照してください。

リポジトリに変更がない場合、予定されているビルドをスキップする

ご要望が多かったため、コードに変更がない場合、予定されていたビルドを実行しないように指定できるようになりました。 スケジュールにオプションを指定することでこの動作を制御できます。 既定では、(同じスケジュールからの) 最後に予定されているビルドが終わり、リポジトリに変更がない場合、新しいビルドを予定に入れません。

GitHub Enterprise からの継続的インテグレーションによるビルド

バージョン管理に GitHub Enterprise を利用している場合、継続的インテグレーション (CI) ビルドを実行するための統合が改善されています。 以前は、外部 Git コネクターを利用したコード変更はポーリングに限定されていました。サーバーの負荷が増え、ビルドのトリガーが遅れることがありました。 それが今回、GitHub Enterprise が公式にサポートされ、チーム CI ビルドがすぐにトリガーされるようになりました。 また、LDAP や組み込みアカウントなど、さまざまな認証方法を利用して接続を構成できます。

GitHub Enterprise ビルド ソース オプション

ビルドまたはリリース中にセキュア ファイルをエージェントにダウンロードできる

新しいセキュア ファイルのダウンロード タスクでは、VSTS セキュア ファイル ライブラリから暗号化されているファイルを (エージェント コンピューターに) ダウンロードできます。 ファイルがダウンロードされると、復号され、エージェントのディスクに格納されます。 ビルドまたはリリースが完了すると、ファイルはエージェントから削除されます。 VSTS で安全に暗号化され、保護されている、証明書や秘密鍵など、取り扱いに慎重を要するファイルをビルドやリリースで利用できます。 詳細については、セキュア ファイルに関する文書を参照してください。

Apple プロビジョニング プロファイルをソース リポジトリからインストールできる

Apple プロビジョニング プロファイルのインストール タスクでは、VSTS セキュア ファイル ライブラリに格納されているプロビジョニング プロファイルを (エージェント コンピューターに) インストールすることが既に可能になっています。 プロビジョニング プロファイルは、iOS、macOS、tvOS、watchOS 向けなど、Apple アプリに署名し、パッケージ化する目的で、Xcode によって使用されます。 今回、プロビジョニング プロファイルをソース コード リポジトリからインストールできるようになりました。 ファイルのセキュリティを強化するために、セキュア ファイル ライブラリの利用をお勧めしています。この改善は、ソース管理に既に格納されているプロビジョニング プロファイルに対処するものです。

Apple プロビジョニング

ビルド タグを利用し、ビルドまで GitHub ソースを追跡する

GitHub または GitHub Enterprise からのビルドは関連コミットに既にリンクされています。 そのコミットを構築したビルドまでコミットを追跡できることは、同じくらい重要です。 TFS でソース タグ付けを有効にすることで、この追跡が可能になりました。 ビルド定義で GitHub リポジトリを選択するとき、タグを付けるビルドの種類とタグの形式を選択します。

タグ ソースのオプション

次に、GitHub または GitHub Enterprise リポジトリにビルド タグが表示されるのを確認します。

GitHub のタグ付けされたソースの例

ビルドおよびリリース中、特定の Java 開発キット (JDK) をインストールできる

特定の Java プロジェクトをビルドする場合、特定の JDK が必要になるが、それをエージェント コンピューターで利用できないことがあります。 たとえば、以前のバージョンや異なるバージョンの IBM、Oracle、オープン ソースの JDK がプロジェクトで必要になることがあります。 Java ツール インストーラー タスクは、ビルドまたはリリース中にプロジェクトが必要とする JDK をダウンロードし、インストールします。 ビルドまたはリリースの期間に対して JAVA_HOME 環境変数が適宜設定されます。 ファイル共有、ソース コード リポジトリ、Azure Blob Storage を使用して、Java ツール インストーラーに特定の JDK を使用できます。

Xcode ビルド構成の改善

Xcode タスクが新しいメジャー バージョン (4.*) で更新されました。Xcode のビルド、テスト、パッケージ化の構成が改善されます。 Xcode プロジェクトに 1 つの共有スキームがある場合、そのスキームが自動的に使用されます。 インライン ヘルプが追加されました。 xcrun パッケージ化など、非推奨の機能が Xcode タスクのプロパティから削除されました。 既存のビルドおよびリリース定義を変更し、この最新 4.* バージョンの Xcode タスクを使用する必要があります。 新しい定義については、前の Xcode タスク バージョンの非推奨の機能が必要な場合、定義の中でそのバージョンを選択できます。

リリース ゲート

継続的監視は、DevOps パイプラインの重要な部分です。 あるリリースのアプリが展開後、正常であることを確認することは、展開プロセスの成功と同じくらい重要です。 企業は、稼働中のアプリが正常であることを自動検出し、顧客が報告する出来事を追跡記録するさまざまなツールを導入します。 これまでは、リリースを奨励する前に、全システムのアプリの正常性を承認者が手動で監視する必要がありました。 しかし、リリース管理では、継続的な監視をリリース パイプラインに統合できるようになりました。 この統合を利用すると、システムではアプリの正常性を伝えるあらゆる信号が繰り返し問い合わされ、すべてが同時に合格した時点でリリースが再開されます。

最初に、リリース定義で展開前ゲートまたは展開後ゲートを定義します。 各ゲートでは、アプリの監視システムに対応する 1 つまたは複数の正常性信号を監視できます。 "Azure モニター (アプリケーション分析情報) アラート" と "作業項目" には、組み込みゲートを利用できます。 Azure の機能から提供される柔軟性を利用し、他のシステムと統合できます。

ゲート付きリリース

実行時に、リリースはすべてのゲートからサンプルを集め、それぞれから正常性信号を集めます。 同じ間隔ですべてのゲートから集めた信号が合格するまで、各間隔でサンプリングが繰り返されます。

サンプリング間隔

新しい展開の場合、十分な情報が利用できないため、監視システムからの最初のサンプルは正確ではないことがあります。 "評価前の遅延" オプションを選択すると、すべてのサンプルが合格しても、この期間はリリースが進行しません。

ゲートのサンプリングの間、エージェントまたはパイプラインは使用されません。 詳細については、リリース ゲートに関する文書を参照してください。

成果物を選択的に展開し、リリースをトリガーする

複数の成果物ソースをリリース定義に追加し、リリースをトリガーするように構成できます。 いずれかのソースに新しいビルドが利用できるようになると、新しいリリースが作成されます。 リリースをトリガーしたソースに関係なく、同じ展開プロセスが実行されます。 トリガーするソースに基づいて展開プロセスをカスタマイズできるようになりました。 自動的にトリガーされたリリースについては、リリースをトリガーした成果物ソースを識別する目的で、リリース変数 Release.TriggeringArtifact.Alias にデータが入力されるようになりました。 これはタスク条件、フェーズ条件、タスク パラメーターで使用し、プロセスを動的に調整できます。 たとえば、環境を介して変更された成果物ソースのみを展開できます。

エンティティ固有セキュリティの管理

以前、ロール ベースのセキュリティでは、セキュリティ アクセス ロールが設定されるとき、展開グループ、変数グループ、エージェント キュー、サービス エンドポイントのハブ レベルでユーザーまたはグループにロールが設定されました。 特定のエンティティの継承のオン/オフが切り替えられるようになりました。セキュリティを好みに合わせて構成できます。

[セキュリティ] ダイアログ

複数の環境を承認する

リリースの承認管理が簡単になりました。 並列で展開される複数の環境に同じ承認者を置くパイプラインの場合、現在のところ、承認者は承認ごとに対応する必要があります。 この機能を利用すると、保留中の複数の承認を同時に完了できるようになりました。

複数の環境を承認する

リリース テンプレートの拡張性

リリース テンプレートを使用すると、リリース プロセスの定義を始めるときのベースラインを作成できます。 以前は、自分のアカウントに新しいベースラインをアップロードできましたが、現在は、作成者がその拡張にリリース テンプレートを含めることができます。 GitHub リポジトリに例があります。

条件付きのリリース タスクおよびフェーズ

条件付きビルド タスクと同様に、特定の条件に一致した場合にのみタスクまたはフェーズを実行できるようになりました。 これはロールバック シナリオのモデル化に役立ちます。

組み込みの条件でニーズが満たされない場合、あるいはタスクまたはフェーズの実行タイミングをより細かく制御する必要がある場合、カスタムの条件を指定できます。 条件は関数の入れ子セットとして表現します。 エージェントは最も内部の関数を評価し、それから外方向に評価を進めます。 最終的な結果はブール値であり、タスクを実行するかどうかをその値が決定します。

条件付きリリース フェーズ

サービス エンドポイントの要求履歴

サービス エンドポイントでは、外部サービスとリモート サービスに接続し、ビルドまたは展開のタスクを実行できます。 エンドポイントはプロジェクト スコープで構成され、複数のビルドおよびリリース定義の間で共有されます。 サービス エンドポイントの所有者に、エンドポイントを利用したビルドと展開が統合形式で表示されるようになりました。監査と管理の向上に役立ちます。

エンドポイント要求の履歴

Git と GitHub の成果物の種類の既定プロパティが編集可能に

成果物にリンクが作成された後でも、Git と GitHub の成果物の種類の既定プロパティを編集できるようになりました。 これは特に、安定したバージョンの成果物のブランチが変更されているとき、将来の継続的デリバリーでそのブランチを利用し、成果物の最新版を取得する必要があるというシナリオで役立ちます。

編集可能な成果物のプロパティ

リリース ビューから手動で環境を一括展開する

あるリリースの複数の環境に同時に展開するアクションを手動でトリガーできるようになりました。 これによって、あるリリースで構成や展開に失敗した環境を複数選択し、1 回の操作ですべての環境に再展開できます。

一括デプロイ

Jenkins プロジェクトの使い勝手が改善されました。

まず、Jenkins 複数ブランチ パイプライン プロジェクトをリリース定義の成果物ソースとして利用できるようになりました。

次に、以前は Jenkins サーバーのルート フォルダーからのみ Jenkins プロジェクトを成果物としてリンクできましたが、それが今回、フォルダー レベルで整理されている Jenkins プロジェクトを利用できるようになりました。 ソース一覧にはフォルダー パスと共に Jenkins プロジェクトの一覧が表示されます。そこから成果物ソースとして利用するプロジェクトを選択できます。

Jenkins フォルダー レベル

成果物ソースとしての Docker Hub または Azure Container Registry

この機能では、Docker Hub レジストリまたは Azure Container Registry (ACR) に格納されているイメージをリリースで利用できます。 ACR の geo レプリケーション機能を利用してリージョンごとに新しい変更をロールアウトする、運用環境のみのイメージが含まれるコンテナー レジストリから環境 (運用など) に展開するなどの補完シナリオに向けた最初の一歩がこれです。

リリース定義の成果物の [ + 追加] で、Docker Hub または ACR を第 1 等成果物として構成できるようになりました。 現在のところ、リリースは手動でトリガーするか、別の成果物でトリガーする必要がありますが、間もなく、レジストリへの新しいイメージのプッシュに基づくトリガーを追加する予定です。

Dockerhub 成果物ソース

既定の成果物バージョン

バージョン管理の成果物をリリース定義にリンクするとき、既定バージョンの選択肢が複数になりました。 特定のコミット/変更セットを構成するか、既定のブランチから最新版を選択するように構成できます。 通常、最新版を選択するように構成しますが、選択肢があることは特に、将来のすべての継続的展開に成果物のゴールデン版を指定する必要がある一部の環境で役立ちます。

既定の成果物バージョン

リリース トリガー ブランチの機能強化

ビルド定義に指定されている既定のブランチに基づいてリリース トリガー フィルターを構成できるようになりました。 これは特に、既定のビルド ブランチがスプリントのたびに変わり、リリース トリガー フィルターをリリース定義全体で更新する必要がある場合に役立ちます。 ビルド定義で既定のブランチを変更するだけで、すべてのリリース定義でそのブランチが自動的に使用されるようになりました。 たとえば、チームでスプリント リリース ペイロードごとにリリース ブランチを作成している場合、ビルド定義でペイロードを更新し、新しいスプリント リリース ブランチを指すようにします。リリースでそのブランチが自動的に選択されます。

リリース トリガー

パッケージ管理成果物のリリース トリガー

新しいバージョンのパッケージが公開されたとき、新しいリリースが自動的に作成されるように、リリース定義でパッケージ管理成果物にトリガーを設定できるようになりました。 詳細については、リリース管理のトリガーに関する文書を参照してください。

変数グループの範囲を特定の環境に設定する

以前は、変数グループをリリース定義に追加すると、リリース定義に含まれる変数はリリースのあらゆる環境で利用できました。 今回、変数グループの範囲を特定の環境に設定できるようになりました。 ある環境では利用できるが、同じリリースの他の環境では利用できないように設定できます。 このような機能は、SMTP メール サービスなど、環境間で異なる外部サービスを利用しているときに役立ちます。

リンク変数グループ

Azure Container Registry と Docker Hub から自動的にリリース

コンテナー化されたアプリを展開するとき、コンテナー イメージはコンテナー レジストリに最初にプッシュされます。 プッシュの完了後、コンテナー イメージを Web App for Containers または Kubernetes クラスターに展開できます。 Docker Hub または Azure Container Registry を成果物ソースとして追加することで、この 2 つに格納されているイメージの更新でリリースの自動作成を有効にできるようになりました。

ソースとしてのAzure Container Registry

Jenkins 成果物の既定バージョンを指定する

成果物が複数のリリースを自動トリガーしているとき、リリース定義に保存されている既定バージョンがすべての成果物に対して選択されます。 以前は、Jenkins 成果物には既定バージョンの設定がありませんでした。そのため、Jenkins を第二成果物として利用し、リリースに継続的配置トリガーを設定することはできませんでした。

今回、次のようなよくある選択肢を使って、Jenkins 成果物に既定のバージョンを指定できるようになりました。

  • Latest
  • リリース作成時に指定する
  • 特定のバージョン

Jenkins 成果物の既定のバージョン

拡張機能からリリース ゲートを投稿する

リリース ゲートでは、情報に基づく承認をリリース パイプラインに追加できます。 展開の前後に一連の正常性信号が繰り返し収集され、リリースを次の段階に進めるべきかどうかが判断されます。 一連の組み込みゲートが与えられますが、これまでは他のサービスと統合する手段として "Invoke Azure function" (Azure 呼び出し関数) をお勧めしていました。 今回の更新で、他のサービスと統合し、マーケットプレース拡張機能からゲートを追加する道筋が簡単になります。 カスタム ゲート タスクを投稿することで、リリース定義の作成者に効率的にゲートを構成してもらうことができるようになりました。

ゲート タスクの作成については、こちらで詳細をご覧いただけます。

配置グループを使用した仮想マシンに対するデプロイのスケーリング

堅牢で、すぐに使えるマルチマシン デプロイを提供する配置グループが、汎用的に使用可能になりました。 配置グループを使用すれば、アプリケーション全体の高可用性を確保しながら、複数のサーバーの間で配置を調整し、ローリング更新を実行できます。 また、Azure または任意のクラウド上のオンプレミスまたは仮想マシンにサーバーをデプロイでき、さらには、デプロイされた成果物をエンドツーエンドで、サーバー レベルまで追跡できます。

エージェント ベースの配置機能は、既に使用可能になっている同じビルドと配置エージェントに依存します。 配置グループ フェーズで、ターゲット コンピューター上の完全なタスク カタログを使用できます。 拡張性の観点から、プログラムによるアクセスに対して配置グループとターゲットの REST API を使用することもできます。

Package

アップストリーム ソースを利用し、パブリック パッケージをシームレスに利用する

nuget.org と npmjs.com でアップストリーム ソースが利用できるようになりました。 利点としては、たとえば、保存されているパッケージをアップストリーム ソースから管理 (一覧から削除、非推奨設定、非公開設定、削除など) できます。また、使用するアップストリーム パッケージがすべて確実に保存されます。

npmjs upstream

TFS フィードの保持ポリシー

これまで、TFS パッケージ フィードには、古くて使用されていないバージョンのパッケージを自動的に片付ける機能がありませんでした。 結果的に、パッケージを頻繁に公開するユーザーの場合、NuGet パッケージ マネージャーやその他のクライアントで、いくつかのバージョンを手動で削除するまで、フィード クエリが遅くなることがありました。

今回、TFS フィードの保持ポリシーを有効にしました。 保持ポリシーによって、リテンション期間しきい値に達したときに、最も古いバージョンのパッケージが自動的に削除されます。 ビューに昇格したパッケージは無期限に保持され、実稼働または組織全体で使用されているバージョンを保護できます。

保持ポリシーを有効にするには、フィードを編集し、 [保持ポリシー] セクションの [パッケージごとの最大バージョン数] に値を入力します。

保持

パッケージ管理のフィルター処理

[パッケージ] ページが更新され、Microsoft の標準ページ レイアウト、コマンド バー コントロール、新しい標準フィルター バーが利用できるようになりました。

パッケージ UX 統合フィルター バー

バッジを利用してパッケージを共有する

オープン ソース コミュニティでは、リポジトリの README でパッケージの最新版にリンクされているバッジを使用するのが一般的です。 今回、フィードでパッケージのバッジを作成できるようになりました。 フィード設定で [パッケージ バッジの有効化] オプションを選択し、パッケージを選択し、 [バッジの作成] をクリックします。 バッジ URL を直接コピーしたり、パッケージの詳細ページにバッジをリンクさせる事前生成マークダウンをコピーしたりできます。

パッケージ バッジを作成する

以前のパッケージ バージョンの一覧を 1 ページ全体にまとめました

Microsoft はパッケージ管理を更新し、前のパッケージ バージョンの一覧をパッケージ詳細ページの階層リンク ピッカーに移動しましたが、更新後のパッケージ管理についてはたくさんのフィードバックが届いております。 今回、新しくバージョン ピボットを追加しました。これは以前のバージョンに関する詳細を表示する機能であり、バージョン番号を簡単にコピーしたり、以前のバージョンのリンクを簡単に取得したりできます。

バージョンの一覧

パッケージ一覧でパッケージ バージョンの品質を表示する

パッケージ一覧では、各パッケージ バージョンのビューからその品質を簡単に確認できるようになりました。 詳細については、リリース ビューに関する文書 を参照してください。

パッケージ リスト内のビュー

Gulp、Yarn、その他の認証済みフィードのサポート

今日の npm タスクは認証済み npm フィードと (パッケージ管理や、npm Enterprise および Artifactory などの外部レジストリで) シームレスに連動していますが、以前は、そのタスクでも認証済みフィードに対応していない限り、Gulp などのタスク ランナーや Yarn などの代替 npm クライアントを使用するのが困難でした。 そこで新しい npm Authenticate ビルド タスクを追加しました。このタスクは、後続のタスクが認証済みフィードを正常に利用できるように、.npmrc に資格情報を追加します。

認証フィード

パッケージ フィードの既定のアクセス許可にプロジェクト管理者を追加

以前は、フィードを作成すると、作成者であるユーザーがフィードの所有者のみとして設定されました。その結果、大きな組織の場合、そのユーザーが別のチームに所属したり、組織を離れたりすると、管理上面倒な問題を発生させることがありました。 この単一障害点を取り除くために、フィードを作成するとき、ユーザーの現在のプロジェクト コンテキストを利用してプロジェクト管理者グループを取得し、さらにフィードの所有者に設定するようになりました。 あらゆるアクセス許可と同様に、フィード設定ダイアログを利用してこのグループを削除したり、フィード アクセス許可をさらにカスタマイズしたりできます。

パッケージをリサイクルし、復元する

使われていないパッケージを削除することでパッケージ一覧が整理されますが、間違って削除してしまうこともあります。 今回、削除したパッケージをごみ箱から復元できるようになりました。 削除したパッケージはごみ箱に 30 日間保持されます。この間、必要に応じてパッケージを復元できます。

パッケージのごみ箱

以前、パッケージ ハブにあるパッケージの URL を共有できましたが、使い勝手が良くないことが多々ありました。URL にプロジェクトを含める必要がありましたが、リンクを利用するユーザーにそのプロジェクトが該当することもあれば、該当しないこともあるからです。 今回の更新で、受信者にアクセス許可が与えられているプロジェクトを自動的に選択する URL を利用して、パッケージを共有できるようになりました。

形式は次のとおりです。`https://<TFSserverURL>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package`

`<TFSserverURL>` を除くすべてのパラメーターが任意ですが、パッケージを指定する場合、プロトコルの種類を指定する必要があります。

Test

Visual Studio テスト タスクには完全版の Visual Studio が不要に

ビルド/リリースの Visual Studio テスト タスクでタスクを実行するには、エージェントに Visual Studio を用意する必要があります。 運用環境でテストを実行するために、あるいは複数のエージェントにテストを単に配布する目的で Visual Studio をインストールするのではなく、新しい Visual Studio テスト プラットフォーム インストーラー タスクを使用してください。 このタスクでは、nuget.org のテスト プラットフォームが取得され、それがツール キャッシュに追加されます。 このインストーラー タスクによって vstest の要求が満たされ、エージェントに完全な Visual Studio をインストールしなくても、定義にある後続の Visual Studio テスト タスクが実行されます。

タスク カタログから、定義にインストーラー タスクが追加されます。

プラットフォーム インストーラー タスク

インストーラー経由で取得されたデータを利用するように、後続の Visual Studio テスト タスクを構成します。

プラットフォームのバージョンをテストする

Note

制限事項:NuGet のテスト プラットフォーム パッケージでは、現時点、コード化された UI のテストを実行できません。 コード化された UI のテストへの対応は未処理の仕事として残っています。 NuGet のテスト プラットフォーム パッケージはプラットフォーム非依存ですが、VSTest タスクでは現在のところ、.NET コア テストを実行できません。 .NET コア テストを実行するには、'dot net' タスクを使用してください。

機能テストの実行タスクとテスト エージェントの展開タスクが非推奨に

昨年、ビルド、リリース、テストでエージェントを統合する事業が始まりました。 これは、テスト エージェントの展開タスクと機能テストの実行タスクに基づいて WinRM を使用することに付随するさまざまな問題に対処するためでした。 次を含む、テスト関連のあらゆるニーズに Visual Studio テスト (VSTest) タスクを利用することもできます。

  • 単体テスト
  • 機能 (UI/非 UI) テスト
  • MSTest ベースのテスト
  • サードパーティ フレームワークベースのテスト
  • アセンブリベースのテスト仕様またはテスト計画/テスト スイートによるテストの実行
  • 1 つのエージェント テスト実行と複数のエージェントに対するテストの配布

エージェントを統合する手法では、管理者は CI/CD で使用されるあらゆるコンピューターを共通の方法で管理することもできます。

Visual Studio テスト タスク

この機能を有効にするために、次のような重要な項目を可能にしています。

上記すべてが揃ったところで、テスト エージェントの展開タスクと機能テストの実行タスクを非推奨にする用意ができました。 非推奨のタスクを使用する既存の定義が引き続き機能する間に VSTest の使用に移行することをお勧めします。継続的に拡張される機能を最大限に活用してください。

大量のテスト結果を絞り込む

テスト アセットは時間と共に蓄積し、大規模なアプリケーションではテストの数が短期間で数万単位に増加します。 チームは大量のテスト結果を生産的に閲覧しながら、テストの欠陥、関連付けられる根本原因、問題の所有を特定する効率的な方法を求めるものです。 それを可能にするために、ビルドとリリースの [テスト] タブに新しいフィルターを 3 つ追加しました。 [テスト名] 、 [コンテナー] (DLL)、 [所有者] (コンテナー所有者) です。

テスト名でテストをフィルター処理する

さらに、既存の結果フィルターでは、複数の結果をフィルター処理する機能を提供するようになりました。 本質的に、さまざまなフィルター条件が蓄積されていきます。 ユーザーとしてコミットしたばかりの変更のテスト結果を確認する場合は、 [コンテナー] (DLL の名前)、 [所有者] (DLL 所有者)、 [テスト名] 、またはそれらすべてでフィルター処理して、対応する結果を取得できます。

テスト結果をフィルター処理する

不安定なテストを特定する

テストは不安定になることがあります。ある実行で失敗した後、何も変更しなくても別の実行で合格したりします。 不安定なテストは挫折の要因になりかねません。テストの効果に対する信頼性を失わせ、エラーやバグを見逃す原因になります。 今回の更新で、不安定なテストの問題に対処する解決策の最初の一手が導入され、 エラーを出したテストを再実行するように Visual Studio テスト タスクを構成できるようになりました。 テスト結果は、最初にエラーを出したテストと再実行で合格になったテストを示します。 今後の更新では、データに基づくテストと順序指定テストの再実行に対応する予定です。

Visual Studio テスト タスクは、エラーが広範囲に及ぶ場合にテストの再実行を回避する目的で、エラーを出したテストを再実行する最大試行数とエラーのしきい値パーセンテージを調整できます。たとえば、全テストの 20% 未満でエラーが出た場合にのみテストを再実行します。

失敗したテスト セクションを再実行する

[ビルドとリリース] の [テスト] タブでは、結果に "再実行に成功" を指定してテスト結果を絞り込み、実行中に不安定な動作を見せたテストを特定できます。 このフィルター適用で、再実行で合格したテストごとに最後の試行が表示されます。 概要ビューも変更され、[テストの合計] の下に [再実行に成功 (n/m)] が表示されるようになりました。n は再実行で合格したテストの数であり、m は合格したテストの合計数です。 全試行の階層表示は今後の数回のスプリントで導入する予定です。

失敗したテスト結果を再実行する

プレビュー機能を改善し、Visual Studio テスト タスクによって生成されたさまざまな種類のログに対応

VSTest タスクを機能強化し、エラーを出したテストの標準出力と標準エラーに対応するさまざまなログ ステートメントによって生成されたログを発行するようにしました。 また、プレビュー機能を改善し、テキストとログ ファイルの形式を表示したり、ログ ファイル内で検索したりできるようにしました。

Wiki

お気に入りの Wiki ページをタイトル、コンテンツ、コード、作業項目で検索できます。 Wiki 検索の詳細は Microsoft DevOps ブログでご確認いただけます。

Wiki はさまざまなコンテンツに利用できます。 Wiki からコンテンツを印刷し、空いている時間に読んだり、紙とペンでコメントを追加したり、さらには VSTS プロジェクトの外部の人間にオフライン PDF コピーを見せたりすると便利なことがあります。 それが今回、ページのコンテキスト メニューをクリックし、 [ページの印刷] を選択するだけになりました。

Wiki メニューの印刷ページ オプション

Note

現在のところ、この機能は Firefox に対応していません。

キーボード ショートカットを利用し、簡単に Wiki ページに貢献する

Wiki でショートカットを利用して一般的な編集作業を行ったり、アクションを表示したりできるようになりました。キーボードのみの使用で速くなりました。

ページを表示しているとき、次のようなショートカットでページを追加したり、編集したり、サブページを作成したりできます。

Wiki ビューのキーボード ショートカット ポップアップ

ページを編集しているとき、簡単に保存したり、保存して閉じたり、単純に閉じたりできます。

Wiki のキーボード ショートカットの編集ポップアップ

以上のショートカットに、太字の Ctrl + B、斜体の Ctrl + I、リンク作成の Ctrl + K など、標準の編集ショートカットが加わります。詳細については、キーボード ショートカットの全一覧をご覧ください。

コード リポジトリ マークダウンのリッチ マークダウン レンダリング

コード リポジトリでリッチ形式の README.MD ファイルを作成できるようになりました。 コード リポジトリで MD ファイルをマークダウン レンダリングするとき、HTML タグ、ブロック引用、絵文字、画像のサイズ変更、数式を利用できるようになりました。 Wiki のマークダウン レンダリングとコードの MD ファイルには類似性があります。

Wiki で数式に対応

アプリケーションで数式や方程式が扱われる場合、LaTeX 形式を利用して Wiki にそれらを入れることができるようになりました。

Wiki の数学

Wiki で作業項目を参照する

Wiki ページで作業項目を参照できるようになりました。'#' を押すと、最近アクセスした作業項目の一覧が表示されるので、関心のある作業項目を選択します。 これは特に、リリース ノート、エピック、仕様、作業項目を参照する必要があるその他のページを記述するときに便利です。

Wiki で作業項目を参照する

作業項目を Wiki に、Wiki を作業項目にリンクさせることができるようになりました。 作業項目を Wiki にリンクさせ、エピック ページ、リリース ノート、計画コンテンツを作成すれば、Wiki ページに関連付けられている作業項目を追跡し、エピック ページの何パーセントが完了しているかを検証できます。

Wiki から作業項目をリンクする

リンクされた作業項目は Wiki ページに表示されます。

Wiki ページのリンクされた作業項目

新しい種類のリンク "Wiki ページ" を介して作業項目から Wiki ページへのリンクを追加します。

作業項目から Wiki にリンクする

Ctrl + S で Wiki ページを保存する

Wiki ページを簡単に保存する方法があれば良いというご要望が Microsoft の元に届いています。 そこで今回、キーボード ショートカットの Ctrl + S だけでページと既定の改訂メッセージを保存し、編集を続行できるようにしました。 独自の改訂メッセージを追加する場合、保存ボタンの横にあるシェブロン (V 字のような形) をクリックしてください。

Wiki の保存

Wiki のリッチ コンテンツを HTML として貼り付ける

Confluence、OneNote、SharePoint、MediaWiki など、あらゆるブラウザーベースのアプリケーションから Wiki のマークダウン エディターにリッチ テキストを貼り付けることができるようになりました。 これは特に、複合テーブルなどのリッチ コンテンツを作成し、それを Wiki で表示する人にとって便利な機能です。 コンテンツをコピーし、HTML として貼り付けるだけで完了です。

HTML としての Wiki リッチ コンテンツ

キーボードを利用して Wiki でページを移動する

初期の Wiki では、キーボードを利用してページを並べ替えたり、親ページを変更したりすることができず、キーボード操作を好む人にとって不便でした。 それが今回、Ctrl キーを押しながら Up キーまたは Down キーを押すことでページを並べ替えられるようになりました。 また、親ページを変更できるようになりました。ページのコンテキスト メニューにある [ページの移動] をクリックし、移動する新しい親ページを選択してください。

Wiki ページの移動

Wiki ページの移動ダイアログ

フィルター テキストの強調表示

Wiki のナビゲーション ウィンドウにフィルターを適用すると、ページの階層全体が表示されます。 たとえば、"foobar" というタイトルでページを絞り込むと、フィルター適用後のナビゲーション ウィンドウにすべての親ページも表示されます。 フィルター適用後の一連の結果には "foobar" というタイトルではないページも表示されるため、困惑することがあります。 それが今回、Wiki でコンテンツにフィルターを適用すると、検索対象のテキストが強調表示されるようになりました。フィルターの適用対象のタイトルとそうではないタイトルがはっきりわかります。

Wiki でテキストの強調表示をフィルター処理する

あらゆるコード ナビゲーション ウィンドウで同様の動作が行われます。 たとえば、pull requests、コミット、変更セット、シェルブセットのファイル ナビゲーション ウィンドウです。

PR でテキストの強調表示をフィルター処理する

Wiki ページの編集中にコンテンツをプレビューする

ユーザーはコンテンツの編集中、たいてい Wiki ページを複数回プレビューすることがデータによって示されています。 ページを編集するたびに、平均 1 ～ 2 回は [プレビュー] をクリックします。 結果として、編集作業が遅くなり、最適以下の状態で作業していることになります。特に、マークダウンが初めての人は時間を無駄にします。 それが今回、編集中、ページのプレビューを表示できるようになりました。

Wiki プレビュー

全般

プロファイル カード

TFS には、特定の個人に関連付けられている情報が表示される領域が複数存在します。ある人によって作成されたpull requests、ある人に割り当てられている作業項目などですが、これに限りません。 しかしながら、個人自身に関する情報は限られた部分しか与えられません。 新しいプロファイル カードは、TFS の既存のプロファイル カードに代わるものです。 この新しくなったプロファイル カードでは、自分の TFS アカウント内でユーザーとやりとりし、ユーザーに関する情報を知ることができます。 既定の電子メールや IM クライアントとの統合によって、Active Directory (AD) ユーザーはプロファイル カードから直接、電子メールを送信し、チャットを開始できます。 AD ユーザーは、プロファイル カード内で組織の階層も確認できます。 プロファイル カードはプロジェクト ホーム ページ内で (チーム メンバー セクション、バージョン管理、作業項目、Wiki セクションで) 連絡先カード アイコン、プロファイル写真、コメント内のユーザー名をクリックしてアクティブにできます。

プロファイル カード

円の中のアバター

サークル アバター (円の中にアバターが入っているもの) が導入されました。 サービスのすべてのプロファイル写真が正方形ではなく、円の中に表示されるようになりました。 たとえば、この変更の結果、pull request は下のように表示されるようになりました (アバターが正方形ではなく円に入っていることにご注意ください)。

サークル アバター

プロジェクト タグ

重要なキーワード (タグ) をプロジェクトに付けることができるようになりました。 タグはプロジェクトのホーム ページから直接、簡単に追加したり、削除したりできます (管理者が行います)。ユーザーはプロジェクトの目的や範囲を今までより詳しく、かつすぐに理解できます。 プロジェクト タグの活用方法については、たくさんの計画を用意しています。当サイトを定期的にチェックし、最新情報を入手してください。

プロジェクト タグ

お気に入りグループの順序を変更する

各グループ ヘッダーの上向き矢印と下向き矢印を利用し、アカウントの [お気に入り] ページのグループの順序を変更できるようになりました。

お気に入りグループの順序を変更する

フィードバックと提案

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

ページの先頭へ