Team Foundation Server 2017.0.1 Team Foundation Server 2017.0.1


英語以外のバージョンからこのページにアクセスしていて、最新の内容を見たい場合は、このリリース ノートの英語版ページをご覧ください。If you are accessing this page from a non-English language version, and want to see the most up-to-date content, please visit this Release Notes page in English.


このページの下部で、ページの言語を切り替えることができます。You can switch the page language at the bottom of this page. アイコンをクリックするか、言語を検索するか、使用できる言語の一覧から選択します。Click the icon, search for your language, or select from the list of available languages.

Team Foundation Server 2017.0.1 リリース日: 2018 年 2 月 28 日Team Foundation Server 2017.0.1 Release Date: February 28, 2018

Team Foundation Server 2017.0.1 の新機能What's New in Team Foundation Server 2017.0.1

この更新プログラムでは、潜在的なクロス サイト スクリプト (XSS) の脆弱性およびその他のセキュリティの脆弱性を修正します。This update fixes potential cross site scripting (XSS) and other security vulnerabilities. 詳細については、ブログ記事を参照してください。See the blog post for more information. これは完全なアップグレードです。したがって、TFS 2017.0.1 に直接アップグレードすることができます。It is a full upgrade, so you can upgrade directly to TFS 2017.0.1.

ボタンをクリックして Team Foundation Server 2017.0.1 をダウンロードします。Click the button to download Team Foundation Server 2017.0.1.

Download the Team Foundation Server 2017

他の関連ダウンロードについては、ダウンロードのページをご覧ください。To learn more about other related downloads, see the Downloads page.

Team Foundation Server 2017 リリース日: 2016 年 11 月 16 日Team Foundation Server 2017 Release Date: November 16, 2016

この記事では、Team Foundation Server 2017 に関する情報を紹介します。In this article, you will find information regarding Team Foundation Server 2017. このリリースには、最新の機能の技術革新や改良が組み込まれています。This release includes our most recent feature innovations and improvements. Team Foundation Server 2017 では要件が変更されていることにご注意ください。Note that the requirements have changed for Team Foundation Server 2017. 詳細については、Team Foundation Server の要件と互換性に関するページを参照してください。You can find more details on the Team Foundation Server Requirements and Compatibility page. これが予期したリリース ノートではない場合、最新バージョンのリリース ノートにアクセスしていることに注意してください。If these were not the release notes you were expecting, you have reached the release notes for the most current version.

Team Foundation Server 2017 の新機能What's New in Team Foundation Server 2017?

既知の問題Known Issues

新機能What's New

コード検索は、すべてのコードで高速かつ柔軟で、正確な検索を提供します。Code Search provides fast, flexible, and accurate search across all your code. コードベースは、複数のプロジェクトとリポジトリに展開および分割されるので、必要とするものを見つけることがますます難しくなります。As your codebase expands and is divided across multiple projects and repositories, finding what you need becomes increasingly difficult. チーム間の共同作業およびコード共有を最大限活用できるよう、コード検索で、すべてのプロジェクトにわたって存在する関連情報を迅速かつ効率的に見つけることができます。To maximize cross-team collaboration and code sharing, Code Search can quickly and efficiently locate relevant information across all your projects.

API の実装の例の検出やその定義の参照からエラー テキストの検索に至るまで、コード検索は、すべてのコード探索やトラブルシューティングの必要に応じてワンストップ ソリューションを提供します (図 1)From discovering examples of an API's implementation, browsing its definition, to searching for error text, Code Search delivers a one-stop solution for all your code exploration and troubleshooting needs (Figure 1).

コード検索は、次のものを提供します。Code Search offers:

  • 1 つ以上のプロジェクトの検索Search across one or more projects
  • セマンティックの順位付けSemantic Ranking
  • 豊富なフィルター処理Rich filtering
  • コードの共同作業Code collaboration
Code Search
"*(図 1) コード検索*"*(Figure 1) Code Search*

詳細については、「コード全体の検索」をご覧ください。For details, see Search across all your code.

パッケージの管理 Package Management

パッケージを使用すると、組織全体でコードを共有できます。大規模な製品を作成したり、共通の共有フレームワークに基づいて複数の製品を開発したりできるほか、再利用できるコンポーネントとライブラリを作成して共有できます。Packages enable you to share code across your organization: you can compose a large product, develop multiple products based on a common shared framework, or create and share reusable components and libraries. パッケージのホスト、指定したメンバーとのパッケージの共有、チーム ビルドとリリース管理からのアクセスの簡易化によって、パッケージ管理 (図 2) ではコードの共有が容易になります。Package Management (Figure 2) facilitates code sharing by hosting your packages, sharing them with the people you select, and making them easily accessible to Team Build and Release Management.

パッケージ管理では NuGet パッケージが Team Foundation Server で直接ホストされるため、別個の NuGet サーバーまたはファイル共有をホストする必要がなくなります。Package Management eliminates the need to host a separate NuGet server or file share by hosting NuGet packages directly in your Team Foundation Server. NuGet 3.x および NuGet 2.x レガシ クライアントがクラス最高レベルでサポートされます。It has best-in-class support for NuGet 3.x as well as support for NuGet 2.x legacy clients. 既存の TFS インフラストラクチャ、チーム、アクセス許可とシームレスに連動するため、ID の同期や、複数の場所でのグループの管理などに対応する必要がありません。チーム ビルドとの統合も容易なため、継続的インテグレーション ワークフローの中でパッケージを作成して使用できます。It works seamlessly with your existing TFS infrastructure, teams, and permissions, so there’s no need to deal with synchronizing identities, managing groups in multiple places, etc. It also integrates easily with Team Build so you can create and use packages in continuous integration workflows.

詳細については、「Package Management overview」 (パッケージ管理の概要) を参照してください。For more details, see the Package Management overview.

Package Management
"*(図 2) パッケージ管理*"*(Figure 2) Package Management*

アジャイルの機能強化 Agile Improvements

Team Foundation Server 2017 では、作業項目とかんばんボードに新しい機能が追加されました。In Team Foundation Server 2017, we've added new features and functionality to work items and Kanban boards.

新しい作業項目の形式New work item form

新しい作業項目 (図 3) の形式の外観が更新されています。The new work item (Figure 3) form has a new look and feel. また、いくつかの優れた新機能も追加されています。It also adds some great new features:

  • 豊富な作業項目のディスカッション エクスペリエンス。A rich work item discussion experience.
  • 添付ファイルに対するドラッグ アンド ドロップ操作のサポート。Drag and drop support for attachments.
  • 機能強化された履歴エクスペリエンス (履歴/監査)。Improved history experience (History & auditing).
  • コードとビルドの統合が向上しました。Improved code and build integration.
  • 状態の色分け表示。State coloring.
  • 応答性に優れたデザイン。Responsive design.


新しい作業項目のフォームは、新しいコレクションのみの既定です。The new work item form is the default for new collections only. 既存のコレクションを移行する場合は、管理設定から新しい作業項目のフォームを有効にする必要があります。If you’re migrating an existing collection you will have to enable the new work item form from the admin settings. 詳細については、「Manage roll out of the new web form」 (新しい Web フォームのロールアウトを管理する) を参照してください。For more information, see Manage roll out of the new web form.

New WIT Form
"*(図 3) 新しい WIT のフォーム*"*(Figure 3) New WIT Form*

作業項目のフォローFollow a work item

フォームの新しい "フォロー" ボタン (図 4) をクリックするだけで、単一の作業項目に対する変更を追跡するためのアラートをセットアップできるようになりました。You can now setup an alert for tracking changes to a single work item just by clicking on the new "Follow" button (Figure 4) in the form. 作業項目をフォローすると、フィールドの更新、リンク、添付ファイル、コメントなどの作業項目が変更されたときに通知を受け取ることができます。When you follow a work item, you'll be notified any time the work item changes – including field updates, links, attachments, and comments.

New WIT Form
"*(図 4) 新しい WIT のフォーム*"*(Figure 4) New WIT Form*

詳細については、「Follow a work item (作業項目のフォロー)」を参照してください。For details, see Follow a work item.

かんばんボードのライブ更新Kanban board live updates

かんばんボードをライブ更新できるようになりました。Your Kanban board is now live!

かんばんボードで最新の状況を知るために 1 日に何度も F5 キーを押していませんか。Have you been hitting F5 to figure out what's going on throughout the day with your Kanban board? 以下のスクリーンショットのアイコンを試してみてください (図 5)Try the icon in the screenshot below (Figure 5).

Kanban live updates
"*(図 5) かんばんのライブ更新*"*(Figure 5) Kanban live updates*

チーム内のだれかがボード内で作業項目を作成、更新、または削除すると、すぐにボードがライブ更新されます。When anyone in your team creates, updates, or deletes a work item on the board, you will receive live updates on your board immediately. また、管理者が新しい列の追加やバックログでのバグの有効化など、ボードやチーム レベルの更新を行うと、ボードを最新表示してボードのレイアウトを更新するように通知が届きます。Also, if the administrator makes board or team level updates such as adding a new column or enabling bugs on backlog, you will be notified to refresh the board to update your board layout. かんばんボードにあるタワーのアイコンをオンにするだけで、チームとの共同作業を始められます。All you need to do now, is enable the tower icon on your Kanban board and start collaborating with your team.

詳細については、「Kanban basics (かんばんの基礎)」を参照してください。For more information, see Kanban basics.

チェックリストの機能強化Checklist improvements

チェックリストの機能がいくらか強化されています。We’ve made several improvements to how Checklists work.

チェックリストのタイトルが、ハイパーリンクとして表示されるようになりました (図 6)Checklists titles now appear as hyperlinks (Figure 6). タイトルをクリックして、作業項目フォームを開くことができます。You can click on the title to open the work item form.

Checklist improvements
"*(図 6) チェックリストのハイパーリンク*"*(Figure 6) Checklist hyperlinks*

また、チェックリストは、コンテキスト メニューをサポートするようにもなりました。コンテキスト メニューから、チェックリスト項目を開いたり、編集したり、削除したりすることができます (図 7)Checklists now also support context menus that allow you to open, edit, or delete checklist items (Figure 7).

Checklist context menu
"*(図 7) チェックリストのコンテキスト メニュー*"*(Figure 7) Checklist context menu*

詳細については、「Add task checklists (タスク チェックリストの追加)」を参照してください。For details, see Add task checklists.

エピックおよび機能ボードのドリルダウンEpic and Feature Board Drill-down

エピックおよび機能ボードをドリルダウンできるようになりました (図 8)You now have the ability to drill down on your Epic and Feature boards (Figure 8). チェックリスト形式により、作業を簡単に完了済みとしてマークすることができます。完了済みの作業と未完了の作業の比較を便利なバード アイ ビューから表示することができます。The checklist format lets you easily mark work as completed, and provides a handy bird’s eye view of the completed versus outstanding work.

Epic Feature drilldown
"*(図 8) エピック機能のドリルダウン*"*(Figure 8) Epic Feature drilldown*

詳細については、かんばんの機能とエピックに関するページを参照してください。For more information, see Kanban features and epics.

ボードの注釈の有効化/無効化Turning board annotations on/off

ボード上のカードに表示する追加情報の管理容易性が向上しています。We are giving you more control of the additional information that shows on the cards on your boards. かんばんカードに表示する注釈を選択できるようになりました (図 9)You can now select annotations that you want to view on your Kanban cards (Figure 9). コメントを選択解除するだけで、かんばんボードのカードで非表示にすることができます。Simply unselect an annotation and it will disappear from the cards on your Kanban board. ここで最初に紹介する 2 つの注釈は、子作業項目 (この例のタスク) とテスト注釈です。The first two annotations to show up here are child work items (tasks in this example) and the Test annotation.

Turn on/off board annotations
"*(図 9) ボードの注釈のオン/オフ*"*(Figure 9) Turn on/off board annotations*

詳細については、「Customize Cards (カードのカスタマイズ)」を参照してください。For more information, see Customize Cards.

書式のクリア コマンドClear formatting command

作業項目のすべてのリッチ テキスト コントロールに新しいコマンドが追加されました。そのコマンドを使用して、選択したテキストからすべての書式をクリアすることができます。We’ve added a new command to all rich text controls on work items that lets you clear all formatting from selected text. もしかしたらこれまで、元に戻すことができない (あるいはクリアできない) 書式設定済みテキストをこのフィールドにコピー アンド ペーストすることで苦労してこられたかもしれません。私もそうでした。If you’re like me, you’ve probably been burned in the past by copying and pasting formatted text into this field that you can’t undo (or clear). これからは、テキストを強調表示し、書式のクリア ツールバー ボタンを選択するだけで (または CTRL を押しながらスペースバーを押すだけで)、テキストを既定の形式に戻すことができます。Now you can simply highlight any text, select the Clear Formatting toolbar button (or press CTRL+Spacebar), and you'll see the text return to its default format.

かんばんボードでのフィルター処理Filtering in Kanban board

ユーザー、イテレーション、作業項目タイプ、およびタグのフィルターを設定して、かんばんボードをカスタマイズします (図 10)Personalize your Kanban boards by setting filters on users, iterations, work item types, and tags (Figure 10). これらのフィルターは有効なままとなり、カスタマイズされたボードを表示できるようになります。複数のデバイスから接続するときも同様です。These filters will persist so that you can view your personalized board, even when you connect from multiple devices.

Filtering in Kanban
"*(図 10) かんばんでのフィルター処理*"*(Figure 10) Filtering in Kanban*

チーム メンバーは、ボードをフィルター処理して、特定の親作業項目での進捗状況を表示することもできます。Team members can also filter their boards to view progress accruing to a specific parent work item. たとえば、ユーザーは、機能にリンクされているユーザー ストーリーを表示したり、エピックにロールアップされる 2 つ以上の機能にわたる作業を表示したりすることができます。For example, a user can view user stories that are linked to a feature, or view work across two or more features that roll up to an epic. この機能は、チェックリストによく似ており、さまざまなバックログ レベルに対する可視性をもたらす取り組みでのもう 1 つのステップです。This feature, much like Checklists, is one more step in our effort to bring visibility through to the different backlog levels.

詳細については、かんばんボードのフィルター処理に関するページを参照してください。For details, see Filter Kanban board.

新しい作業項目の既定のイテレーション パスDefault iteration path for new work items

[クエリ] タブまたは新規作業項目ダッシュボード ウィジェットから新規作業項目を作成する際、その作業項目のイテレーション パスは常に現行イテレーションに設定されます。When you create a new work item from the Queries tab or from the New Work Item dashboard widget, the iteration path of that work item is always set to the current iteration. すべてのチームがこれを望むとは限りません。これはバグがタスク ボードに即座に表示されることを意味するからです。This is not what all teams want, because it will mean that bugs could show up on the task board immediately. この機能強化により、チームが既定のイテレーション パス (特定の 1 つまたは現在のイテレーション) を選択できるようになりました。それを新しい作業項目に使用する必要があります。With this improvement, teams can choose the default iteration path (a specific one or the current iteration) that should be used for new work items. チームの管理領域に移動し、既定のイテレーションを選択してください。Navigate to the administration area for your team to choose a default iteration.

詳細については、「Customize area and iteration paths」 (区分とイテレーション パスのカスタマイズ) のページを参照してください。For more information, see the Customize area and iteration paths page.

CheckBox コントロールCheckbox control

作業項目に Checkbox コントロールを追加できるようになりました (図 11)You can now add a checkbox control to your work items (Figure 11). この新しいフィールド型 (Boolean) は、通常のフィールドのすべてのプロパティを持ち、プロセス内の任意の型に追加することができます。This new field type (Boolean) has all the properties of normal fields and can be added to any type in your process. カードまたはクエリ結果に表示される場合、値は True/False として表示されます。When displayed on cards or in a query result, the value is shown as True/False.

Checkbox control
"*(図 11) CheckBox コントロール*"*(Figure 11) Checkbox control*

詳細については、フィールドのカスタマイズに関するページを参照してください。For details, see Customize a field.

タグの一括編集Tags bulk editing

一括編集用のダイアログ ボックスを使用して、複数の作業項目へのタグの追加および複数の作業項目からのタグの削除を行えるようになりました (図 12)You can now add and remove tags from multiple work items using the bulk edit dialog (Figure 12).

Bulk edit dialog
"*(図 12) 一括編集用のダイアログ*"*(Figure 12) Bulk edit dialog*

詳細については、作業項目へのタグの追加に関するページを参照してください。For details, see Add tags to work items.

新しい拡張ポイントNew extension points

ボードおよびバックログ ページに新しい貢献ポイントを追加しました。これにより、[ボード] タブ、[バックログ] タブ、[容量] タブの横にピボット タブとして拡張機能を書き込むことができるようになりました。We’ve added a new contribution point on the board and backlog pages to allow you to write extensions as a pivot tab next to Board/Backlog/Capacity tabs.

バックログに対する新しい拡張ポイントを公開しました。We have exposed a new extension point on the backlog. 拡張機能では右側にあるウィンドウを使用することができます。ここで、マッピングおよび作業の詳細は最新の情報となります (図 13)Extensions can target the pane on the right side, where mapping and work details are today (Figure 13).

Backlog extension points
"*(図 13) バックログの拡張ポイント*"*(Figure 13) Backlog extension points*

拡張機能の詳細については、「Extension Points (拡張ポイント)」を参照してください。For more information on extensions, see Extension Points.

電子メールの機能強化Email improvements

TFS によって送信される作業項目の警告、フォロー、@mention 電子メールの書式設定と使いやすさが大幅に改良されました (図 14)We’ve significantly improved the formatting and usability of work item alerts, follows, and @mention emails sent by TFS (Figure 14). 電子メールで、見出しに一貫性が保たれるようになり、また操作呼び出しがわかりやすくなり、さらに書式設定が改善されました。これにより、メールの情報がより使いやすく、よりわかりやすくなりました。Emails now include a consistent header, a clear call to action, and improved formatting to make sure the information in the mail is easier to consume and understand. また、これらすべての電子メールは、モバイル デバイスでも見やすく表示されるよう設計されています。Additionally, all these emails are being designed to ensure they render well on mobile devices.

Email improvements
"*(図 14) 電子メールの機能強化*"*(Figure 14) Email improvements*

詳細については、作業項目の警告に関するページを参照してください。For more information, see Work item alerts.

作業項目テンプレートWork item templates

豊富な作業項目テンプレートを作成する機能を、ネイティブの Web エクスペリエンスに直接追加しました (図 15)We added the ability to create rich work item templates directly into the native web experience (Figure 15). この機能は、これまで Web での使用が非常に制限されており、この新しいフォームで、Visual Studio のパワー ツールを介してしか利用できませんでした。This capability was previously very limited in the web, and only available in this new form through a Visual Studio power tool. チームでは、共通のフィールドをすばやく変更するためのテンプレート セットを作成し管理することができるようになりました。Teams can now create and manage a set of templates for quickly modifying common fields.

Work item templates
"*(図 15) 作業項目テンプレート*"*(Figure 15) Work item templates*

詳細については、作業項目テンプレートに関するページを参照してください。For details, see Work item templates.

Project Server の統合がサポートされなくなりましたProject server integration no longer supported

Team Foundation Server 2017 以降のバージョンでは、Project Server の統合がサポートされなくなりました。Team Foundation Server 2017 and later versions no longer support Project Server integration. RC2 の時点では、Project Server の統合がインストールされた TFS データベースのアップグレードを実行すると、次の警告が表示されます。As of RC2, if you upgrade a TFS database that has Project Server integration configured, you'll receive the following warning:

このデータベースに対しては、Project Server の統合が構成されています。Team Foundation Server 2017 以降のバージョンでは、Project Server の統合がサポートされなくなりました。We have detected that you have Project Server integration configured for this database. Team Foundation Server 2017 and later versions no longer support Project Server integration.

アップグレード完了後、Project Server の統合は動作しなくなります。After upgrade, the Project Server integration will no longer operate.

今後は、パートナーによって統合ソリューションが提供されるようになります。Going forward, we will be relying on Partners to provide integration solutions.

この変更の詳細については、トピック 「TFS と Project Server の同期」 を参照してください。For more information on this change, please read the following topic: Synchronize TFS with Project Server.

ダッシュボードとウィジェットの機能強化 Dashboards and Widgets Improvements

Team Foundation Server 2017 では、クエリ タイル ウィジェットやプル要求ウィジェットなどの複数のウィジェットが機能強化されています。Team Foundation Server 2017 has made improvements on multiple widgets, such as the Query Tile and Pull Request widgets.

再設計されたウィジェット カタログRedesigned widget catalog

増えゆくウィジェットに対応し、全体的なエクスペリエンスを機能強化するために、ウィジェット カタログが再設計されました (図 16)We’ve redesigned our widget catalog to accommodate the growing set of widgets and deliver a better overall experience (Figure 16). 新しい設計では、検索エクスペリエンスが機能強化されており、ウィジェット構成パネルのデザインに合うようスタイルが変更されています。The new design includes an improved search experience and has been restyled to match the design of our widget configuration panels.

Widget catalog
"*(図 16) ウィジェットのカタログ*"*(Figure 16) Widget catalog*

詳細については、「Widget Catalog (ウィジェットのカタログ)」を参照してください。For more details, see Widget Catalog.

ウィジェットの更新Widget updates

クエリ タイル ウィジェットは最大 10 個の条件付き規則をサポートするようになりました。また、色を選択できるようになりました (図 17)The Query Tile widget now supports up to 10 conditional rules and has selectable colors (Figure 17). これは、必要になる可能性があるヘルスおよび/またはアクションを識別するためにこれらのタイルを KPI として使用するときに便利です。This is extremely handy when you want to use these tiles as KPIs to identify health and/or action that may be needed.

Dashboard updates
"*(図 17) ダッシュボードの更新*"*(Figure 17) Dashboard updates*

プル要求ウィジェットは、ユーザーがウィジェットの高さを制御できるよう、複数のサイズをサポートするようになりました。The Pull Request widget now supports multiple sizes, allowing users to control the height of the widget. 私たちは、出荷するほとんどのウィジェットについてサイズ変更できるよう取り組んでいます。詳細については、ここをご覧ください。We’re working on making most of the widgets we ship resizable, so look for more here.

新規作業項目ウィジェットで、作成している最も一般的なタイプを強制的に何度もドロップダウン リストから選択する代わりに、既定の作業項目タイプを選択できるようになりました。The New Work Item widget now allows you to select the default work item type, instead of forcing you to select the most common type you’re creating over and over from the drop-down list.

WIT グラフ ウィジェットのサイズを変更できるようにしました。We've made the WIT chart widgets resizable. これにより、ユーザーは、WIT グラフの元のサイズに関係なく、ダッシュ ボードで WIT グラフの展開ビューを表示することができます。This allows users to see an expanded view of any WIT chart on the dashboard regardless of its original size.

チーム メンバー ウィジェットが更新され、メンバーをチームに追加しやすくなりました (図 18)The Team Members widget has been updated to make it easier to add somebody to your team (Figure 18).

Widget Update
"*(図 18) ウィジェットの更新*"*(Figure 18) Widget Update*

チームは、ダッシュ ボードのクエリ結果ウィジェットのサイズを構成して、より多くの結果を表示できるようになりました。Teams can now configure the size of the dashboard's Query Results widget, allowing it to display more results.

[スプリントの概要] ウィジェットが再設計され、チームは作業が順調に進んでいるかどうかを簡単に確認できるようになりました。The Sprint Overview widget has been redesigned making it easier for teams to see if they're on track.

[現在のユーザーに割り当て済み] ウィジェットにより、ユーザーはダッシュボード コンテキストから離れなくても自分に割り当てられた作業を管理することができます (図 19)The Assigned to Me widget helps users manage the work assigned to them without leaving the dashboard context (Figure 19). この目的に特化したウィジェットを提供することにより、チーム管理者は、16 回未満のクリック操作で、この機能を追加することができるため、コンテキストの切り替えもタイプ入力も必要ありません。By providing a widget dedicated to this purpose, team admins can add this functionality to their dashboards with 16 fewer clicks, no context switches and no typing required. ユーザーは自分に割り当てられた作業を、ウィジェットのコンテキスト内で表示、並べ替え、フィルター処理、管理することができるようになりました。Users can now view, sort, filter, and manage the work assigned to them within the widget context.

Assigned to me
"*(図 19) 現在のユーザーに割り当て済み*"*(Figure 19) Assigned to me*

ダッシュボード REST APIDashboards REST APIs

REST API を使用して、プログラムによってダッシュボードで情報を追加、削除、および取得できるようになりました。You can now use REST APIs to programmatically add, delete, and get information on a dashboard. また、API を使用して、ダッシュボードのウィジェットまたはウィジェットのリストの情報を追加、削除、更新、置換、および取得することもできます。The APIs also let you add, remove, update, replace, and get information on a widget or a list of widgets on a dashboard. このドキュメントは、Visual Studio オンライン ドキュメントから入手できます。The documentation is available on Visual Studio online docs.

許容ダッシュボードPermissible dashboards

管理者以外のユーザーがチームのダッシュ ボードを作成し管理できるようになりました。Non-admin users can now create and manage team dashboards. チーム管理者は、ダッシュ ボード マネージャーを通じて管理者以外のユーザーのアクセス許可を制限することができます。Team admins can restrict non-admin permissions through the dashboard manager.

詳細については、「Dashboards (ダッシュボード)」を参照してください。For more information, see Dashboards.

Git の機能強化 Git Improvements

Team Foundation Server 2017 では、Git にいくつか大きな変更が加えられています。Some major changes have been made in Git for Team Foundation Server 2017. [ブランチ] ページが再設計されており、“スカッシュ マージ” という新しいオプションが登場しています。Included are a redesign of the Branches page and a new option to “squash merge”.

再設計された [ブランチ] ページRedesigned Branches page

[ブランチ] ページが全体的に再設計されています。The Branches page has been completely redesigned. このページには、自分が作成、プッシュ、またはお気に入りに入れたブランチを表示する、"自分のもの" のピボットがあります (図 20)It has a "mine" pivot that shows the branches you created, pushed to, or favorited (Figure 20). 各ブランチには、ビルドおよびプル要求状況、およびその他のコマンド (削除など) が表示されます。Each branch shows its build and pull requests status, as well as other commands like Delete. ブランチ名にスラッシュがある場合 ("features/jeremy/fix-bug" など)、ブランチがツリー形式で表示されるため、ブランチの大規模な一覧を簡単に参照できます。If there is a slash in a branch name, like "features/jeremy/fix-bug", it's shown as a tree, so it's easy to browse through a large list of branches. ブランチの名前がわかっている場合は、検索してすぐに見つけることができます。If you know the name of your branch, you can search to find the one you want quickly.

Redesigned branches page
"*(図 20) 再設計された [ブランチ] ページ*"*(Figure 20) Redesigned branches page*

ブランチの詳細については、「Manage branches (ブランチの管理)」を参照してください。For more details on branches, see Manage branches.

新しいプル要求エクスペリエンスNew pull request experience

このリリースでは、プル要求エクスペリエンスについて、いくつかの大きな更新が行われました。具体的には、非常に強力な各種機能が追加され、新しいコメント用のエクスペリエンスが採用され、UI が全体的に更新されました。The pull request experience has some major updates this release, bringing some really powerful diff capabilities, a new commenting experience, and an entirely refreshed UI.

詳細については、「Review code with Pull Requests (プル要求によるコードのレビュー)」を参照してください。For more details, see Review code with Pull Requests.

#####再設計された UIRedesigned UI プル要求を開くと、外観が新しくなったことがすぐにわかります (図 21)When opening a pull request, the new look and feel is evident immediately (Figure 21). すべての重大な状態とアクションを要約するヘッダーを再構成して、エクスペリエンスのどのビューからもそれらの情報にアクセスできるようにしました。We've reorganized the header to summarize all the critical state and actions, making them accessible from every view in the experience.

Pull request header
"*(図 21) プル要求ヘッダー*"*(Figure 21) Pull request header*

#####概要Overview 概要では PR 説明が強調表示されるようになりました。これにより、以前よりもフィードバックを送信しやすくなります (図 22)The Overview now highlights the PR Description and makes it easier than ever to give feedback (Figure 22). 上部の最新のアイテムと共にイベントとコメントが表示され、レビュー担当者は最新の変更とコメントを前面中央で確認できます。Events and comments are shown with the newest items on top to help reviewers see the latest changes and comments front and center. ポリシー、作業項目、およびレビュー担当者はすべて詳細に提供され、より明確および簡潔に表示できるように再構成されています。Policies, work items, and reviewers are all provided in detail and reorganized to be more clear and concise.

Pull request overview
"*(図 22) プル要求の概要*"*(Figure 22) Pull request overview*

#####ファイルFiles このリリースで提供する最大の新機能は、プル要求に対して行われた過去の更新を確認できることです (図 23)The biggest new feature in this release is the ability to see past updates made to a pull request (Figure 23). 前のプレビューでは、PR に変更内容が反映された時点でコメントを正しく追跡する機能をリリースしました。In previous previews, we released the ability to properly track comments as a PR is updated with changes. しかし、この場合、更新履歴を確認することは必ずしも容易ではありません。However, it's not always easy to see what's between updates. [ファイル] ビューでは、新しいコードが PR にプッシュされるたびに変更内容を正確に確認できるようになりました。In the Files view, you can now see exactly what changed each time new code is pushed to your PR. これは、特定のコードに対してフィードバックを送信し、そのコードがどのように変更されたかを正確に確認したい場合に便利です。レビューで他のすべての変更と区別して確認できるからです。This is very useful if you've given feedback on some code and want to see exactly how it changed, isolated from all the other changes in the review.

Pull request files
"*(図 23) プル要求ファイル*"*(Figure 23) Pull request files*

#####更新Updates PR が時間の経過と共にどのように変化しているかを示すには、新しい [更新] ビューを使用します (図 24)The new Updates view is used to show how the PR is changing over time (Figure 24). [ファイル] ビューには、ファイルが時間の経過と共にどのように変更されたかが表示され、[更新] ビューには各更新で追加されたコミットが表示されます。Where the Files view shows how the files have changed over time, the Updates view shows the commits added in each update. 強制的なプッシュがこれまでに発生している場合、[更新] ビューには過去の更新内容が履歴として引き続き表示されます。If a force push ever happens, the Updates view will continue to show the past updates as they occurred in history.

Pull request updates
"*(図 24) プル要求の更新プログラム*"*(Figure 24) Pull request updates*

#####マークダウンと絵文字が使用されるようになったコメントComments, now with markdown and emoji あらゆる説明でマークダウンの豊富な機能 (書式設定、構文が強調表示されたコード、リンク、画像、絵文字など) を使用できます (図 25)Use the full power of markdown in all your discussions, including formatting, code with syntax highlighting, links, images, and emoji (Figure 25). また、コメント コントロールには、よりユーザーにとって使いやすい編集エクスペリエンスがあります。これにより、複数のコメントを一度に編集 (および保存) できるようになりました。The commenting controls also have a more user friendly editing experience allowing multiple comments to be edited (and then saved) at one time.

Pull request comments
"*(図 25) プル要求のコメント*"*(Figure 25) Pull request comments*

#####プル要求のレビュー担当者の追加と削除Add and remove reviewers in pull requests プル要求からレビュー担当者を追加および削除しやすくなりました。It's now easier to add and remove reviewers from your pull requests. プル要求にレビュー担当者またはグループを追加するには、レビュー担当者のセクションで [検索] ボックスに名前を入力するだけです。To add a reviewer or group to your pull request, simply enter their name into the search box in the Reviewers section. レビュー担当者を削除するには、[レビュー担当者] セクションでタイルの上に移動し、X をクリックして削除します (図 26)To remove a reviewer, hover over their tile in the Reviewers section and click the X to remove them (Figure 26).

Add reviewers in pull requests
"*(図 26) プル要求のレビュー担当者の追加*"*(Figure 26) Add reviewers in pull requests*

#####ビルドおよびプル要求追跡可能性の機能強化Improved build and pull request traceability ビルドとプル要求の間の追跡可能性が機能強化され、PR からビルドまたはその逆に移動しやすくなりました。The traceability between builds and pull requests has improved, making it easy to navigate from a PR to a build and back. プル要求によってトリガーされるビルドのビルド詳細ビューで、ソースが、ビルドをキューに置いたプル要求へのリンクを表示するようになりました。In the build details view for a build triggered by a pull request, the source will now show a link to the pull request that queued the build. [ビルド定義] ビューで、プル要求によってトリガーされたビルドはすべて、"トリガー" 列のプル要求へのリンクを提供します。In the Build Definitions view, any build triggered by a pull request will provide a link to the pull request in the "Triggered By" column. 最後に、[ビルド エクスプローラー] ビューに、ソース列のプル要求が一覧表示されます。Finally, the Build Explorer view will list pull requests in the source column.

#####プル要求に対するコメント追跡Comment tracking for pull requests VSTS のプル要求が機能強化されました。これにより、コメントが追加されてからファイルが変更された場合、ファイルに残っているコメントを適切な行に表示するようになりました。Pull requests in VSTS have been improved to show comments left in files on the proper line, even if those files have been changed since the comments were added. 以前、ファイルの内容が変更された場合でも、コメントは常に、それが最初に追加されたファイルの行に表示されていました。すなわち、10 行目のコメントならば、常に 10 行目に表示されていました。Previously, comments were always shown on the line of the file where they were originally added, even if the file contents changed—in other words, a comment on line 10 would always be shown on line 10. 最新の機能強化により、コメントは、ユーザーの期待どおりに該当するコードの後に表示されます。たとえば、10 行目にコメントを追加し、その後、ファイルの先頭に 2 つの新しい行を追加した場合、コメントは 12 行目に表示されるようになります。With the latest improvements, the comments follow the code to show what the user expects—if a comment was added on line 10, and two new lines were subsequently added to the beginning of the file, the comment will be shown on line 12.

コメントが 13 行目にある場合の変更例を次に示します (図 27)Here's an example change with a comment on line 13 (Figure 27):

Comment tracking
"*(図 27) コメントの追跡*"*(Figure 27) Comment tracking*

コードに変更を加えたことで、元のコメントを含む行が 13 行目から 14 行目に移動した場合でも、コメントは期待どおりの場所 (14 行目) に表示されます (図 28)Even after the code has changed to shift the line with the original comment from 13 to 14, the comment is appearing in the expected place on line 14 (Figure 28).

Comment tracking with change
"*(図 28) コメントの変更の追跡*"*(Figure 28) Comment tracking with change*
ポリシーで待機しているプル要求のオート コンプリートAuto-complete pull requests waiting on policies

分岐ポリシー ( を使用して分岐を保護しているチームは、オート コンプリート アクションを確認することが必要になります。Teams that are using branch policies to protect their branches will want to check out the auto-complete action. 多くの場合、プル要求の作成者は PR をマージする準備ができていても、ビルドが終了しなければ [完了] をクリックすることができません。Many times, the author of a pull request will be ready to merge their PR, but they're waiting on a build to finish before they can click Complete. その他に、ビルドが渡されても、最終的な承認を発行していないレビュー担当者が 1 人存在する場合もあります。Other times, the build is passing, but there is one reviewer that hasn't given the final approval. このような場合、オート コンプリート アクションを使用することで、作成者は、ポリシーがすべて承認されたら直ちに自動的に完了するように PR を設定することができます (図 29)In these cases, the auto-complete action lets the author set the PR to automatically complete as soon as the policies are all approved (Figure 29).

"*(図 29) オートコンプリート*"*(Figure 29) Auto-complete*

手動のコンプリート アクションと同様に、作成者にはマージ コミットのメッセージをカスタマイズし、適切なマージ オプションを選択する機会があります (図 30)Just like the manual complete action, the author has a chance to customize the message of the merge commit and select the appropriate merge options (Figure 30).

"*(図 30) オートコンプリートのダイアログ*"*(Figure 30) Autodialog*

オート コンプリートを設定すると、PR には、オート コンプリートが設定された状態であり、ポリシーが完了するのを待機していることを確認するバナーが表示されます (図 31)Once auto-complete has been set, the PR will display a banner that confirms that the auto-complete is set and waiting for policies to complete (Figure 31).

Auto-complete confirmation
"*(図 31) オートコンプリートの確認*"*(Figure 31) Auto-complete confirmation*

すべてのポリシーの条件が満たされると (たとえば、ビルドが完了した場合、またはその最終的な承認が発行された場合)、指定したオプションとコメントによって PR はマージされます。When all the policies have been met (e.g., the build completes, or that final approval is granted), the PR will be merged using the options and comments specified. 予想どおり、ビルド エラーが発生したか、またはレビュー担当者が承認していない場合は、ポリシーが渡されるまで PR はアクティブのままとなります。As expected, if there is a build failure or the reviewer doesn't approve, the PR will remain active until the policies are passing.

スカッシュ マージ プル要求Squash merge pull requests

プル要求が完了したときに、スカッシュ マージというオプションを選択できるようになりました (図 32)When completing a pull request, you now have the option to squash merge (Figure 32). この新しいオプションでは、ターゲット ブランチに適用されるトピック ブランチからの変更を含む単一のコミットが生成されます。This new option will produce a single commit containing the changes from the topic branch that will be applied to the target branch. 正規のマージとスカッシュ マージの間の最も顕著な違いは、スカッシュ マージのコミットは親コミットを 1 つしか持たないという点です。The most notable difference between a regular merge and a squash merge is that the squash merge commit will only have one parent commit. これは、履歴グラフがより単純になることを意味します。トピック ブランチに加えられる中間コミットは結果のコミット グラフで到達できないからです。This will mean a simpler history graph, as any intermediate commits made to the topic branch will not be reachable in the resulting commit graph.

Squash merge pull request
"*(図 32) スカッシュ マージ プル要求*"*(Figure 32) Squash merge pull request*

詳細については、「Squash merge pull requests (スカッシュ マージ プル要求)」を参照してください。You can find more information at Squash merge pull requests.

コミットの追跡可能性Commit traceability

ビルドの状態 (成功または失敗) を [コード エクスプローラー] ビューおよび [コミットの詳細] ビューでわかりやすく表示できるようになりました (図 33)Build status (success or failure) is now clearly visible in the Code Explorer and Commit Details views (Figure 33). クリックするだけで詳細を表示できるため、コミットの変更がビルドで成功したか失敗したかが常にわかるようになります。More details are just a click away, so you’ll always know if the changes in the commit passed the build or not. ビルド定義のリポジトリ オプションで、どのビルドが状態を表示するかカスタマイズすることもできます。You can also customize which builds post status in the repository options for the build definition. さらに、[コミットの詳細] ビューへの最新の変更により、変更に関するより深い洞察が得られます。Additionally, the latest changes to the Commit Details view provide deeper insights about your changes. プル要求を使用して変更をマージする場合は、マスター ブランチに対して変更を導入したプル要求へのリンク (マージ コミットの場合は、それを作成した PR) が表示されます。If you’re using pull requests to merge your changes, you’ll see the link to the pull request that introduced the changes into the master branch (or in the case of a merge commit, the PR that created it). 変更がマスターに達すると、変更内容が含まれていることを確認するブランチ リンクが表示されます。When your changes have reached master, the branch link will appear to confirm that the changes have been included.

Commit Traceability
"*(図 33) コミットの追跡可能性*"*(Figure 33) Commit Traceability*

Web での Git LFS ファイルの表示View Git LFS files in the Web

Git で大きなファイル (オーディオ、ビデオ、データセットなど) を既に使用している場合、Git Large File Storage (LFS) が、ファイルの内容をリモート サーバーに保存しつつ、これらのファイルを Git 内部でポインターに置き換えることをご存じでしょう。If you’re already working with large files in Git (audio, video, datasets, etc.), then you know that Git Large File Storage (LFS) replaces these files with pointers inside Git, while storing the file contents in a remote server. リポジトリ内のファイルをクリックするだけで、これらの大きなファイルの完全な内容を表示できるようになりました。This makes it possible to view the full contents of these large files by simply clicking the file in your repo.

詳細については、Git を使用した大きなファイルの管理に関するページを参照してください。For more information, see Manage large files with Git.

コード参照をコード リンクと簡単に共有します (図 34)Share code references easily with code links (Figure 34). ファイル内のテキストを選択して [リンク] アイコンをクリックするだけです。Just select text in a file and click the Link icon. 選択されているコードへのリンクをコピーします。It will copy a link to the selected code. いずれかのメンバーがそのリンクを表示すると、強調表示したコードの背景がゴールドになります。When someone views that link, the code you highlighted will have a gold background. これは一部の行選択でも機能します。It even works for partial line selections.

Send links to code
"*(図 34) コードへのリンクの送信*"*(Figure 34) Send links to code*

状態 APIStatus API

ビルドの成功または失敗を [コード エクスプローラー] ビューおよび [コミットの詳細] ビューでわかりやすく表示できるようになりました (図 35)Success or failure of the build is now clearly visible in the code explorer and commit details views (Figure 35). クリックするだけで詳細を表示できるため、コミットの変更がビルドで成功したか失敗したかが常にわかるようになります。More details are just a click away, so you'll always know if the changes in the commit passed the build or not. ビルド定義のリポジトリ オプションで、どのビルドがビルド状態を表示するかカスタマイズすることもできます。You can also customize which builds post build status in the repository options for the build definition.

Status API
"*(図 35) 状態 API*"*(Figure 35) Status API*

ファイルの種類のアイコンFile type icons

エクスプローラー、プル要求、コミットの詳細、シェルブセット、変更セットなど、ファイルの一覧を表示するビューに、ファイルの拡張子に対応する新しいファイル アイコンが表示されます (図 36)You will see new file icons matching the extension of the file in the explorer, pull requests, commit details, shelveset, changeset or any other view that shows a list of files (Figure 36).

File type example
"*(図 36) ファイルの種類の例*"*(Figure 36) File type examples*

リポジトリ作成時に Readme ファイルを追加するAdd a ReadMe during repo creation

新しい Git リポジトリ作成が機能強化され、ユーザーは Readme ファイルを追加できるようになりました*(図 37)*。The new Git repository creation has been improved by providing users the ability to add a ReadMe file (Figure 37). リポジトリに Readme ファイルを追加すると、他の人がコードベースの目的を理解しやすくなるだけでなく、リポジトリをすぐに複製することもできます。Adding a ReadMe to the repository not only helps others understand the purpose of the codebase, but also allows you to immediately clone the repository.

Add a ReadMe file
"*(図 37) ReadMe ファイルの追加*"*(Figure 37) Add a ReadMe file*

ビルドの機能強化 Build Improvements

このリリースでは、ログのサイズが増量され、Java ビルド テンプレートが追加され、いくつかの変更に名前を付けるための Xamarin サポートが機能強化されています。In this release, we’ve increased the size of the logs, added Java build templates, and improvements to our Xamarin support to name a few changes.

再設計された [ビルド キュー] タブRedesigned build queue tab

[キューに入っているビルド] ページの新しいデザインを実装しました。このページでは、キューに入っているビルドおよび実行中のビルドをより多く、直観的な方法で一覧表示します (図 38)We've implemented a new design for the Queued builds page that shows a longer list of queued and running builds, and in a more intuitive fashion (Figure 38).

Build queue tab
"*(図 38) [ビルド キュー] タブ*"*(Figure 38) Build queue tab*

詳細については、ビルド システムの管理に関するページを参照してください。For more information, see Administer your build system.

順序と列を指定するためのビルド結果の拡張機能の有効化Enable build result extensions to specify order and column

ビルド結果セクションの拡張機能が、列およびその表示順序を指定できるようになりました (図 39)Build result section extensions can now specify which column and the order in which they appear (Figure 39). 結果ビューには 2 つの列があり、すべての拡張機能は既定で最初の列になります。The result view has two columns, and all extensions will be in the first column by default. 注: すべてのサード パーティ製の拡張機能は、含めるビルド結果の後に表示されます。Note: All third-party extensions will appear after the build result sections we include.

Build order and column
"*(図 39) ビルドの順序と列*"*(Figure 39) Build order and column*

行番号へのビルドBuild to line number

ビルド エラーから、エラーの原因となったコードの行にジャンプできるようになりました。Now you can jump from a build error to the line of code that caused it. 内部的にプル要求ポリシーとして使用するプライマリ ビルドの最新のエラーを見て、以下がわかります (図 40)Looking at the latest error on the primary build we use as a pull request policy internally, you see this (Figure 40):

Build to line number
"*(図 40) 行番号へのビルド*"*(Figure 40) Build to line number*

ビルド ログ ビューでサポートされるログの数が増えています。Build log view supports much larger logs

以前のログ ビューでは、最大 10,000 行のログしかサポートされていませんでした。The previous log view only supported logs up to 10,000 lines. 新しいビューアーは、VS コードで使用される Monaco エディターに基づいており、150,000 行までのログをサポートします。The new viewer is based on the Monaco editor used in VS Code and will support logs up to 150,000 lines.

Java のビルド テンプレートJava build templates

Ant、Maven、Gradle のビルド テンプレートを追加して、Java 開発者がより一層簡単にビルドを開始できるようにしました (図 41)We’ve made it even easier for Java developers to get started with build by adding build templates for Ant, Maven, and Gradle (Figure 41).

Java build templates
"*(図 41) Java のビルド テンプレート*"*(Figure 41) Java build templates*

テンプレートの詳細については、ビルド ステップに関するページを参照してください。For more information on templates, see Build steps.

Xamarin のビルド タスクXamarin build tasks

Xamarin のサポートに対していくつかの重要な機能強化が行われています。We made some significant improvements to our Xamarin support:

Xamarin ライセンス手順は、不要になりましたので、ビルド テンプレートから削除されました。The Xamarin License step is no longer necessary and has been removed from the build templates. この取り組みの一環として、該当するタスクも廃止することになります。As part of this effort we will also deprecate the task. このタスクが最終的に削除されるときに何らかの障害が発生するのを防ぐために、このタスクを使用しているすべてのビルド定義を更新して、このタスクを削除しておく必要があります。All build definitions that use this task should be updated to remove it in order to prevent any disruption when the task is finally removed.

最終的に、これらの新規タスクを使用するよう Xamarin のビルド定義のテンプレートが機能強化されました。Finally, the Xamarin build definition templates were enhanced to use these new tasks. Xamarin アプリをビルドしますBuild your Xamarin app.

ビルドおよびリリース管理のための Docker 統合Docker integration for build and release management

ビルド機能を活用して、Docker イメージを作成し、継続的統合フローの一部として Docker Hub にアップロードします (図 42)Take advantage of the build capabilities to build your Docker images and upload them to the Docker Hub as part of your continuous integration flow (Figure 42). その後、それらのイメージをいくつかの Docker ホストに Release Management の一部として配置します。Then, deploy those images to a number of Docker hosts as part of Release Management. Marketplace 拡張機能は、Docker を使用するために必要なすべてのサービス エンドポイントの種類とタスクを追加します。The Marketplace extension adds all the service endpoint types and tasks necessary for you to work with Docker.

Docker images
"*(図 42) Docker イメージ*"*(Figure 42) Docker images*

プル要求ビューの SonarQube の結果SonarQube results in pull request view

プル要求をマージするためのビルド実行に SonarQube MSBuild タスクが含まれる場合、プル要求のディスカッション コメントとして新しいコード分析の問題が表示されるようになりました (図 43)If the build run to merge a pull request contains SonarQube MSBuild tasks, you will now see new code analysis issues as discussion comments in the pull request (Figure 43). このエクスペリエンスは、SonarQube サーバーにプラグインがインストールされているあらゆる言語に対して機能します。This experience works for any language for which a plug-in is installed on the SonarQube server. 詳細については、ブログ投稿「SonarQube Code Analysis issues integration into Pull Requests (プル要求への SonarQube コード分析の問題の統合)」を参照してください。For more information, see the SonarQube Code Analysis issues integration into Pull Requests blog post.

SonarQube pull requests
"*(図 43) プル要求の SonarQube*"*(Figure 43) SonarQube pull requests*

ビルド定義の状態 API レポートの構成Configure status API reporting for a build definition

状態を Git 状態 API に報告するビルド定義を選択できるようになりました。You can now choose which build definitions report their status back to the Git status API. 特定のリポジトリまたはブランチをビルドする多くの定義があるものの、実際の正常性を表すものは 1 つだけである場合にこれは特に便利です。This is particularly useful if you have many definitions that build a given repository or branch, but only have one that represents the real health.

詳細については、ビルド REST API リファレンスを参照してください。For more information, see the Build REST API reference.

チーム ルームでのビルド vNext のサポートBuild vNext support in team rooms

チーム ルームに常に XAML ビルドの通知を追加できるようになっています。It has been always possible to add notifications of XAML builds in the team room. このスプリントを使用すれば、ユーザーはビルド vNext の完了を知らせる通知も受信することができます。With this sprint, users can also receive notifications from Build vNext completions.

Git CI トリガーのパス フィルターを有効にするEnable path filters for Git CI triggers

ホストされている Git リポジトリの CI トリガーでは、特定のパスを含めることも除外することもできます。CI triggers for hosted Git repositories can include or exclude certain paths. これにより、特定のパス内のファイルが変更された場合にのみ実行されるように、ビルド定義を構成することができます (図 44)This enables you to configure a build definition to run only when files in specific paths have changed (Figure 44).

Git CI Triggers
"*(図 44) Git CI トリガー*"*(Figure 44) Git CI Triggers*

リリース管理の機能強化 Release Management Improvements

Team Foundation Server 2015 に Web ベースの統合型リリース管理を導入して以来、このバージョンではさまざまな機能強化を行ってきました。Since the introduction of integrated web-based Release management in Team Foundation Server 2015, we have made several enhancements in this version.

リリース定義を複製、エクスポート、およびインポートするClone, export, and import release definitions

リリース定義を複製、エクスポート、インポートする機能をリリース ハブ内に組み込みました。拡張機能をインストールする必要はありません (図 45)We have incorporated the ability to clone, export, and import release definitions within Release hub, without requiring installation of an extension (Figure 45).

Clone and export commands on release summary page
"*(図 45) リリース概要ページでコマンドを複製およびエクスポートする*"*(Figure 45) Clone and export commands on release summary page*

詳細については、「Clone, export, and import a release definition」 (リリース定義の複製、エクスポート、インポート) のドキュメントを参照してください。For more details, see Clone, export, and import a release definition documentation.

リリース概要に表示されるテスト結果Test results displayed in the release summary

リリース概要ページでは、環境固有の情報が表示されるように、外部サービスの貢献ポイントを有効にしました。In the release summary page, we have enabled a contribution point for an external service to show environment-specific information.

この機能は、テストがリリース環境の一部として実行された際にテスト結果の概要を表示するために Team Service で使用されます (図 46)In Team Services, this functionality is used to display a summary of test results when tests are run as part of a release environment (Figure 46).

Test results displayed in the release summary
"*(図 46) リリース概要に表示されるテスト結果*"*(Figure 46) Test results displayed in the release summary*

詳細については、「Understand the summary view of a release」 (リリースの概要ビューの確認) のドキュメントを参照してください。For more details, see Understand the summary view of a release documentation.

OAuth トークンをスクリプトに渡すPass OAuth tokens to scripts

Team Services で REST API を呼び出すカスタム PowerShell スクリプトを実行する必要がある場合 (おそらく作業項目を作成したり、ビルドの情報を照会したりする場合)、OAuth トークンをスクリプトに渡す必要があります。If you need to run a custom PowerShell script that invokes the REST APIs on Team Services, perhaps to create a work item or query a build for information, you need to pass the OAuth token in the script.

環境を構成する際に新しいオプションを使用すると、スクリプトを環境内のタスクとして実行し、現在の OAuth トークンにアクセスできます (図 47)A new option when you configure an environment allows scripts to run as tasks in the environment to access the current OAuth token (Figure 47).

Pass OAuth tokens to scripts
"*(図 47) OAuth トークンをスクリプトに渡す*"*(Figure 47) Pass OAuth tokens to scripts*

詳細については、「Environment general options」 (環境の一般的なオプション) のドキュメントを参照してください。For more details, see Environment general options documentation.

これは、ビルド定義を取得する方法を示す簡単な例です (図 48)This is a simple example showing how to get a build definition (Figure 48):

Example script using passed oAuth token
"*(図 48) 渡された oAuth トークンを使用したスクリプトの例*"*(Figure 48) Example script using passed oAuth token*

部分的に成功した展開のトリガーTrigger on partially successful deployments

ビルド タスクとリリース タスクでは、各タスクの [管理オプション] パラメーターで [エラー時に続行] オプションを選択することができます。Build and release tasks have an option to Continue on error in the Control Options parameters for each task.

ビルド定義では、このオプションが設定されたタスクが失敗すると、[ビルドが一部成功しました] という結果が生成されます。In a build definition, this results in a Build partially succeeded result if a task with this option set should fail.

リリース定義でも同様の動作を指定できるようになりました。The same behavior is now available in release definitions. タスクが失敗した場合、リリース全体の結果は、"リリースが一部成功しました" となります (図 49)If a task fails, the overall release result will show as "Release partially succeeded" (Figure 49).

Release summary shows partially successful releases in orange color
"*(図 49) リリースの概要で部分的に成功したリリースはオレンジ色で表示される*"*(Figure 49) Release summary shows partially successful releases in orange color*

既定では、部分的に成功したリリースは、環境の展開オプションで前述の動作が指定されていたとしても、後続の環境に対してリリースを自動的にトリガーしません。By default, a partially successful release will not automatically trigger a release to a subsequent environment, even if this behavior is specified in the environment deployment options.

ただし、前のリリースが部分的に成功した場合でも、後続の環境に対してリリースをトリガーするようにリリース管理に指示する新しいオプションを各リリース環境で設定することができます (図 50)However, a new option can be set in each release environment that instructs Release Management to trigger a release to a subsequent environment when the previous release is partially successful (Figure 50).

Setting the option to trigger from a partially successful release
"*(図 50) 部分的に成功したリリースからトリガーするオプションの設定*"*(Figure 50) Setting the option to trigger from a partially successful release*

詳細については、「Environment deployment triggers」 (環境の配置トリガー) のドキュメントを参照してください。For more details, see Environment deployment triggers documentation.

GitHub に格納されている成果物を直接使用するConsume artifacts stored in GitHub directly

場合によっては、バージョン管理システムに格納されている成果物は、このトピックの説明のとおり、ビルド プロセスを経由させることなく直接使用することをお勧めします。Sometimes you may want to consume artifacts stored in a version control system directly, without passing them through a build process, as described in this topic.

GitHub リポジトリにコードが格納されている場合も、同じことが行えるようになりました (図 51)You can now do the same if your code is stored in a GitHub repository (Figure 51).

Linking code in a GutHub repository to a release definition
"*(図 51) GitHub リポジトリ内のコードをリリース定義にリンクする*"*(Figure 51) Linking code in a GutHub repository to a release definition*

詳細については、「TFVC, Git, and GitHub sources」 (TFVC、Git、GitHub のソース) のドキュメントを参照してください。For more details, see TFVC, Git, and GitHub sources documentation.

ARM を使用した Web アプリ配置Web App Deployment using ARM

AzureRM Web アプリ配置と呼ばれる、新しいバージョンの Azure Web アプリ配置タスクを利用できます。A new version of the Azure Web App Deployment task is available, called AzureRM Web App Deployment.

AzureRM Web アプリ配置では、MSDeploy と Azure Resource Manager サービス エンドポイント接続が使用されます。It uses MSDeploy and an Azure Resource Manager service endpoint connection. このタスクを使用して、ASP.NET 4、Node、Python ベースの Web アプリに加えて、Azure Web ジョブと Azure API アプリを配置します。Use this task to deploy Azure Web Jobs and Azure API apps, in addition to ASP.NET 4, Node, and Python based web apps.

このタスクでは、アプリのデータを保持する機能、アプリをオフラインにする機能、ターゲットの追加のファイルを削除する機能など、一般的な発行オプションもサポートされています。The task also supports common publishing options such as the ability to retain app data, take an app off-line, and remove additional files at the destination.

近日公開されるバージョンでは、構成の変換など、機能がさらに追加される可能性があります (図 52)More features, such as configuration transformations, may appear in forthcoming versions (Figure 52).

Web app deployment using ARM
"*(図 52) ARM を使用した Web アプリ配置*"*(Figure 52) Web app deployment using ARM*

タスク グループTask groups

"タスク グループ" を使用すると、ビルドまたはリリース定義で既に定義された一連のタスクを、再利用できる 1 つのタスクにカプセル化できます。このタスクは、他のタスクとまったく同じようにビルドまたはリリース定義に追加できます (図 53)A task group lets you encapsulate a sequence of tasks already defined in a build or a release definition into a single reusable task that can be added to a build or release definition just like any other task (Figure 53).

カプセル化されたタスクからパラメーターを構成変数として抽出し、残りのタスク情報を抽象化することができます。You can choose to extract the parameters from the encapsulated tasks as configuration variables, and abstract the rest of the task information.

新しいタスク グループは、タスク カタログに自動的に追加され、他のリリース定義またはビルド定義に追加できる状態になります。The new task group is automatically added to the task catalogue, ready to add to other release and build definitions.

Linking code in a GutHub repository to a release definition
"*(図 53) GitHub リポジトリ内のコードをリリース定義にリンクする*"*(Figure 53) Linking code in a GutHub repository to a release definition*

詳細については、「Task Groups」 (タスク グループ) のドキュメントを参照してください。For more details, see Task Groups documentation.

リリースの論理削除Soft delete of releases

リリースを削除した場合、または保持ポリシーによって自動的にリリースが削除された場合、リリースは概要と詳細リストから削除されます。When you delete a release, or it is automatically deleted by a retention policy, the release is removed from the overview and details lists.

しかし、完全に削除される前に、リリースはリリース定義と共に一定期間 (通常は 14 日間) 保持されます。However, it is retained with the release definition for a period (typically 14 days) before it is permanently deleted.

この期間中、削除されたリリースは概要と詳細リストの [Deleted (削除済み)] タブに表示されます。During this period, it is shown in the Deleted tab of the overview and details lists.

これらのリリースは、ショートカット メニューを開いて [削除の取り消し] を選択することで復元できます (図 54)You can restore any of these releases by opening the shortcut menu and choosing Undelete (Figure 54).

Undelete releases
"*(図 54) リリースの削除の取り消し*"*(Figure 54) Undelete releases*

詳細については、「Restore deleted releases」 (削除されたリリースの復元) のドキュメントを参照してください。For more details, see Restore deleted releases documentation.

環境ごとのリリースとビルドの保持Retain releases and builds for each environment

リリース定義のリリース保持ポリシーにより、リリースとそれにリンクされたビルドが保持される期間が定められます。The release retention policy for a release definition determines how long a release and the build linked to it are retained.

既定ではリリースは 60 日間保持されます。この期間中に配置または修正されなかったリリースは、自動的に削除されます。By default, a release is retained for 60 days - releases that have not been deployed or modified during that time will automatically be deleted.

しかし、実稼働環境など、特定の環境に配置したリリースをより多く保持したい場合や、それらのリリースを、テスト環境、ステージング環境、QA 環境など、その他の環境に配置してあったリリースよりも長い期間保持したい場合があります。However, you may want to retain more releases that have been deployed to specific environments, such as your production environment, or retain them longer than those that were just deployed to other environments such as test, staging, and QA.

リリースにリンクされたビルドをそのリリースと同じ期間保持することもできます。これにより、このリリースをもう一度配置する必要がある場合に成果物を使用できます (図 55)You can also retain the build linked to a release for the same period as the release to ensure that the artifacts are available if you need to redeploy that release (Figure 55).

Retain releases
"*(図 55) リリースの保持*"*(Figure 55) Retain releases*

詳細については、「Release and build retention」 (リリースとビルドの保持) のドキュメントを参照してください。For more details, see Release and build retention documentation.

リンクされた成果物の機能強化Linked artifact improvements

2 つの新機能により、成果物と成果物のソースが使いやすくなります。Two new features make it easier to work with artifacts and artifact sources:

  • 複数の成果物のソースをリリース定義にリンクできます (図 56)You can link multiple artifact sources to a release definition (Figure 56). それぞれの成果物は、ソース エイリアスと呼ばれるエージェント上のフォルダーにダウンロードされます。Each of the artifacts is downloaded into a folder on the agent called the source alias. これで、リンクされた成果物のソース エイリアスが編集できるようになります。You can now edit the source alias of a linked artifact. たとえば、ビルド定義の名前を変更する際に、ソース エイリアスを編集してビルド定義の名前を反映させることができます。For example, when you change the name of the build definition, you can edit the source alias to reflect the name of the build definition.
Linked artifact improvements
"*(図 56) リンクされた成果物の機能強化*"*(Figure 56) Linked artifact improvements*
For more details, see [Artifact source alias]( documentation.
  • Build.* という形式 (Build.BuildId や Build.BuildNumber など) の複数の変数が、タスク パラメーターで使用できるように公開されています。A number of variables of the format Build.* (such as Build.BuildId and Build.BuildNumber) are exposed for use in task parameters. 複数のソースがリリースに関連付けられている場合、これらの変数には、プライマリ ソースとして指定した成果物のソースからの値が設定されるようになっています。When multiple sources are associated with a release, these variables are now populated with values from the artifact source you specify as the primary source. 詳細については、「Artifact variables」 (成果物の変数) のドキュメントを参照してください。For more details, see Artifact variables documentation.

配置 - 手動介入タスクDeployment - Manual Intervention task

環境への配置中に実行を一時停止できるようになりました。You can now pause execution during deployment to an environment.

手動介入タスクを環境に含めると、配置を一時的に停止して手動の手順を実行し、その後に自動化された手順を再開することができます。Including a Manual Intervention task in an environment enables you to temporarily halt a deployment, perform manual steps, and then resume further automated steps.

配置を拒否し、手動介入後にその後の手順が実行されないようにすることもできます (図 57)You can also reject the deployment and prevent further steps from executing after a manual intervention (Figure 57).

Manual intervention task
"*(図 57) 手動介入タスク*"*(Figure 57) Manual intervention task*

詳細については、「Manual intervention」 (手動介入) のドキュメントを参照してください。For more details, see Manual intervention documentation.

SQL データベース配置タスクのスクリプトSQL Database deployment task scripts

Azure SQL Database 配置 (図 58) タスクは、Azure SQL データベースに対して SQL スクリプトを実行できるよう機能強化されました。The Azure SQL Database Deployment (Figure 58) task has been enhanced to run SQL scripts against an Azure SQL Database. スクリプトは、ファイルとして指定するか、タスク内にインラインで指定できます。The scripts can be provided as a file, or inline within the task.

SQL database deployment task scripts
"*(図 58) SQL データベース配置タスクのスクリプト*"*(Figure 58) SQL database deployment task scripts*

リリース定義の概要 - ダッシュ ボード ウィジェットRelease definition summary - dashboard widget

ダッシュ ボードへのリリース定義のピン留め - リリースの概要を作成し、チーム全員にリリースの定義が表示されるようにすることが簡単にできます。Pin a release definition to the dashboard - an easy way to make a summary of releases for that definition visible to all your team.

詳細については、「Add release information to the dashboard」 (ダッシュボードにリリース情報を追加する) のドキュメントを参照してください。For more details, see Add release information to the dashboard documentation.

特定の時間に環境に対するリリースを昇格させるPromote releases to an environment at a specific time

製品の展開はすべて、午前 0 時に実行しますか?Want all your production deployments to happen at midnight? 環境において、正常な展開 (または最新の展開のみ) を別の環境から選択し、それを指定された時間に展開するための条件を構成することができます (図 59)You can configure a condition on an environment that selects a successful deployment (or just the latest one) from another environment, and deploys it at the specified time (Figure 59).

Schedule release to an environment
"*(図 59) 環境に対するリリースをスケジュール設定する*"*(Figure 59) Schedule release to an environment*

複数の環境での条件に基づいて展開するDeploy based on conditions in multiple environments

前のバージョンまで、並列配置 (フォーク配置) を行うことができましたが、複数環境の状態に基づいて 1 つの環境への配置 (結合配置) を開始することはできませんでした。Until the previous version, you could do parallel deployments (forkdeployments), but you could not start a deployment to an environment based on the status of multiple environments (join deployments). これができるようになりました。Now you can.

詳細については、「Parallel forked and joined deployments」 (並列のフォーク展開と結合展開) のドキュメントを参照してください。For more details, see Parallel forked and joined deployments documentation.

リリース管理用の REST APIREST APIs for release management

リリース管理サービス用の REST API を使用すると、リリース定義やリリースを作成し、リリースを展開するさまざまな要素を管理することができます。You can use the REST APIs for the Release Management service to create release definitions and releases, and manage many aspects of deploying a release.

詳細については、API リファレンス ドキュメントを参照してください。For more information, see the API reference documentation. API を使用する基本的な例については、ブログ投稿「Using ReleaseManagement REST API’s (ReleaseManagement REST API の使用)」を参照してください。You'll find some basic examples that use the APIs in this blog post, Using ReleaseManagement REST API’s.

サービス フックの統合Service hooks integration

新しいリリースが作成されたとき、展開が開始または完了したとき、または承認が保留状態または完了したときに、リリース通知を送信します。Send release notifications when new releases are created, deployments are started or completed, or when approvals are pending or completed. そのような通知を受信するために、Slack などのサードパーティ製ツールと統合します。Integrate with third party tools such as Slack to receive such notifications.

各国の Azure クラウドへの配置Deployment to national Azure clouds

Azure クラシック サービス エンドポイントで新しい環境設定を使用して、Azure China クラウド、Azure US Government クラウド、Azure German クラウドなど、既定の各国のクラウドを含む、特定の Azure クラウドをターゲットにすることができます (図 60)Use the new Environment setting in an Azure Classic service endpoint to target a specific Azure cloud, including pre-defined national clouds such as Azure China cloud, Azure US Government cloud, and Azure German cloud (Figure 60).

Deployment to national Azure clouds
"*(図 60) 各国の Azure クラウドへの配置*"*(Figure 60) Deployment to national Azure clouds*

詳細については、「Azure Classic service endpoint」 (Azure クラシック サービス エンドポイント) を参照してください。For more details, see Azure Classic service endpoint documentation.

テストの機能強化 Test Improvements

重要なテストの機能強化が Team Foundation Server 2017 で行われました。Key test improvements have been added in Team Foundation Server 2017.

更新されたテスト結果の記憶域スキーマUpdated test result storage schema

このリリースでは、テスト結果の成果物を新しいコンパクトで効率的な記憶域スキーマに移行しています。In this release, we are migrating the test result artifacts to a new compact and efficient storage schema. テスト結果が TFS データベースの記憶域を最も消費するものの 1 つであるため、この機能が TFS データベースの記憶域の占有量を削減するものとなることを期待しています。Since test results are one of the top consumers of storage space in TFS databases, we expect this feature to translate into reduced storage footprint for TFS databases. TFS の以前のバージョンからアップグレードするお客様の場合、TFS のアップグレード中にテスト結果が新しいスキーマに移行されます。For customers who are upgrading from earlier versions of TFS, test results will be migrated to the new schema during TFS upgrade. データベースに存在するテスト結果データによっては、このアップグレードに時間がかかる可能性があります。This upgrade may result in long upgrade times depending on how much test result data exists in your databases. ポリシーを開始し、テスト結果で使用される記憶域を減らして、TFS のアップグレードが高速化されるようテスト保持ポリシーを構成してください。It’s advisable to configure the test retention policy and wait for the policy to kick in and reduce the storage used by test results so that the TFS upgrade will be faster. TFS のインストール後は、TFS インスタンスをアップグレードする前に、TFSConfig.exe ツールを使用してテスト結果をクリーンアップすることができます。After installing TFS, but before upgrading the TFS instance, you can use the TFSConfig.exe tool to clean up test results. 詳細については TFSConfig.exe ヘルプを参照してください。See TFSConfig.exe help for more details. アップグレード前にテスト保持の構成またはクリーンアップが柔軟に行えない場合は、アップグレードの時間枠に応じて計画してください。If you don’t have the flexibility to configure test retention or clean up test results before upgrade, make sure you plan accordingly for the upgrade window. テスト保持ポリシーの構成の例については、「Test result data retention with Team Foundation Server 2015 (Team Foundation Server 2015 でのテスト結果データ保持)」を参照してください。See Test result data retention with Team Foundation Server 2015 for more examples about configuring test retention policy.

テスト ハブの機能強化Test Hub improvements

#####テスト ハブでのテスト構成管理Test configuration management in Test Hub テスト ハブ内に新しい [構成] タブを追加することで、Web UI にテスト構成管理を導入しました (図 61)We’ve brought test configuration management to the web UI by adding a new Configurations tab within the Test Hub (Figure 61). テスト構成を作成および管理し、テスト ハブ内から構成変数をテストできるようになりました。Now you can create and manage test configurations and test configuration variables from within the Test hub.

Configurations hub
"*(図 61) 構成ハブ*"*(Figure 61) Configurations hub*

詳細については、構成と構成変数の作成に関するページを参照してください。For more information, see Create configurations and configuration variables.

#####テスト計画、テスト スイートおよびテスト ケースへの構成の割り当てAssigning configurations to test plans, test suites, and test cases 構成の割り当てがより簡単になりました。テスト ハブ内からテスト計画、テスト スイート、またはテスト計画を直接割り当てられるようになりました (図 62)Assigning configurations just got easier - you can assign test configurations to a test plan, test suite, or test case(s) directly from within the Test hub (Figure 62). 項目を右クリックし、[構成の割り当て先] を選択するだけで、すぐに始められます。Right-click an item, select Assign configurations to …, and you’re off and running. テスト ハブの構成でフィルターすることもできます (図 63)You can also filter by Configurations in the Test hub (Figure 63).

Assign Configurations
"*(図 62) 構成の割り当て*"*(Figure 62) Assign Configurations*
Configurations Filter
"*(図 63) 構成フィルター*"*(Figure 63) Configurations Filter*

詳細については、テスト計画とテスト スイートへの構成の割り当てに関するページを参照してください。For more information, see Assign configurations to Test plans and Test suites.

#####[テスト結果] ペインでのテスト計画/テスト スイート列の表示View test plan/test suite columns in test results pane 新しい列が [テスト結果] ペインに追加されました。このペインには、テスト結果の実行元となったテスト計画とテスト スイートが表示されます。We’ve added new columns to the Test results pane that show you the test plan and test suite under which the test results were executed in. これらの列は、テストの結果を掘り下げるときにかなり必要とされるコンテキストを提供します (図 64)These columns provide much-needed context when drilling into results for your tests (Figure 64).

Test Results Pane
"*(図 64) [テスト結果] ペイン*"*(Figure 64) Test results pane*

#####テスト ハブおよびカードでのテストの順序Ordering of tests in Test Hub & on cards それらが含まれているスイートのタイプ (静的、要件ベース、クエリ ベースなど) に関係なく、テスト ハブ (図 65) から手動テストを順序付けできるようになりました。You can now order manual tests from within the Test Hub (Figure 65), irrespective of the type of suite in which they’re included: static, requirement-based, or query-based suites. 単純に 1 つ以上のテストをドラッグ アンド ドロップするか、コンテキスト メニューを使用してテストの順序を変更することができます。You can simply drag and drop one or more tests or use the context menu to reorder tests. 順序付けが完了したら、[順序] フィールドによってテストをソートし、Web ランナーからその順序で実行できるようになります。Once the ordering is completed, you can sort your tests by the Order field and then run them in that order from the Web runner. かんばんボードのユーザー ストーリー カード上で直接テストを順序付けすることもできます (図 66)You can also order the tests directly on a user story card on the Kanban board (Figure 66). これにより、手動テストの下、長時間保留状態にあるユーザー音声項目 (495 票) が完了します。This completes one of the long-pending user voice items (with 495 votes) under manual testing.

Order tests
"*(図 65) テストの順序付け*"*(Figure 65) Order tests*
Order tests on card
"*(図 66) カード上でのテストの順序付け*"*(Figure 66) Order tests on card*

#####テスト ハブでテスト スイートに順序を付けるOrder test suites in Test Hub テスト チームは必要に応じてテスト スイートに順序を付けることができるようになりました。この機能を実行するまで、スイートはアルファベット順に並べられているにすぎません。Test teams can now order the test suites as per their needs – prior to this capability, the suites were only ordered alphabetically. テスト ハブでドラッグ アンド ドロップ機能を使用することにより、ピア スイートの間でスイートの並べ替えを行うことも、スイートを階層内の別のスイートに移動することもできます (図 67)Now, using the drag/drop capability in Test hub, suites can be re-ordered among the peer suites or moved to another suite in the hierarchy (Figure 67). これは、手動テスト/テスト ケース管理の下にあるユーザーの声アイテムに対処するものです。This addresses the following user voice item under manual testing/test case management.

Order Test suites
"*(図 67) テスト スイートに順序を付ける*"*(Figure 67) Order Test suites*

#####テスト担当者の割り当ての一環としてユーザーを検索するSearch for users as part of assigning testers 各種ハブにわたって新しい ID 選択コントロールを展開する機能の一環として、テスト ハブでは、1 つまたは複数のテストにテスト担当者を割り当てるときに、ユーザーを検索するオプションも使用できるようになりました (図 68)As part of the rollout of new identity picker controls across the different hubs, in Test hub, we have also enabled the option to search for users when assigning testers to one or more tests (Figure 68). これは、チーム メンバーの数は多いのに、コンテキスト メニューには限られたエントリ セットしか表示されないような場合にきわめて有効です *(図 69)。This is extremely useful in scenarios where the number of team members is large, but the context menu only shows a limited set of entries *(Figure 69).

Search users
"*(図 68) ユーザーの検索*"*(Figure 68) Search users*
Assign Users
"*(図 69) ユーザーの割り当て*"*(Figure 69) Assign Users*

#####テスト対象のビルドを選択するPick a build to test with テスト ハブの [Run with options](オプションを指定して実行) を使用することで、テスト対象の "ビルド" を選択し、Web ランナーを起動できるようになりました (図 70)You can now pick the “build” you want to test with and then launch the Web runner, using ‘Run with options’ in Test hub (Figure 70). 実行中のバグ フィールドは、選択されているビルドに自動的に関連付けられます。Any bug filed during the run will automatically be associated with the build selected. さらに、その特定のビルドに対してテスト結果が発行されます。In addition, the test outcome is published against that specific build.

Pick a build
"*(図 70) ビルドの選択*"*(Figure 70) Pick a build*

#####データ コレクターを使用してテスト ハブから Microsoft テスト ランナー クライアントを起動するLaunch Microsoft Test Runner client from Test Hub with data collectors Microsoft Test Manager クライアントで設定を構成しなくても、テストの実行に関連付けるデータ コレクターとビルドを選択し (図 71)、テスト ハブからパフォーマンスの高い方法で Microsoft テスト ランナー 2017 (クライアント) を起動できるようになりました。You can now choose your data collectors & build to associate with the test run (Figure 71), and launch the Microsoft Test Runner 2017 (client) in a performant way from Test hub, without having to configure them in Microsoft Test Manager client. Microsoft テスト ランナーは Microsoft Test Manager シェル全体を開くことがなく起動され、テストが完了するとシャットダウンします。The Microsoft Test Runner will be launched without opening the entire Microsoft Test Manager shell and will shut-down on completion of the test execution.

Run with options
"*(図 71) オプションを指定して実行*"*(Figure 71) Run with options*

詳細については、「Run tests for dektop apps (デスクトップ アプリのテストの実行)」を参照してください。For more information, see Run tests for desktop apps.

#####データ コレクターの選択とテスト ハブからの Exploratory Runner クライアントの起動Choose data collectors and launch Exploratory Runner client from Test hub Microsoft Test Manager クライアントで設定を構成しなくても、データ コレクターを選択し、テスト ハブからパフォーマンスの高い方法で Exploratory Runner 2017 (クライアント) を起動できるようになりました。You can now choose your data collectors and launch the Exploratory Runner 2017 (client) in a performant way from Test hub, without having to configure them in Microsoft Test Manager client. 要件ベースのスイートのコンテキスト メニューから [オプションを指定して実行] を呼び出して (図 72)、必要とする探索的ランナーとデータ コレクターを選択します。Invoke 'Run with options' from the context menu (Figure 72) for a Requirement based suite and choose Exploratory runner and the data collectors you need. 探索的ランナーは、前述の Microsoft テスト ランナーと同様に起動されます。The Exploratory runner will be launched similar to Microsoft Test Runner as described above.

Run with Options - XT
"*(図 72) オプションを指定して実行 - XT*"*(Figure 72) Run with Options - XT*

#####各種テスト スイートで実施されるテスト結果の構成Configure test outcomes for tests across different test suites 同じテスト計画に基づく各種テスト スイートの間で共有されているテストを対象にして、テスト結果の形態を構成する機能を追加しました (図 73)We have now added the ability to configure the behavior of test outcomes for tests shared across different test suites under the same test plan (Figure 73). このオプションが選択され、特定のテストの結果を設定すると (テスト ハブ、Web ランナー、Microsoft テスト ランナーから、またはかんばんボード上のカードから、テスト結果を成功/失敗/ブロックにマークする)、その結果は、同じテスト計画に基づき同じ構成を持つ各種テスト スイートで共有されている他のすべてのテストにも反映されます。If this option is selected, and you set the outcome for a test (mark it as Pass/Fail/Blocked either from the Test hub, Web runner, Microsoft Test Runner, or from cards on Kanban board), that outcome will propagate to all the other tests present across different test suites under the same test plan, with the same configuration. ユーザーは、テスト ハブのテスト計画コンテキスト メニューからでも、かんばんボード テスト ページの共通設定の構成ダイアログ ボックスからでも、特定のテスト計画に対して "テスト結果の構成" を設定することができます。Users can set the “Configure test outcomes” option for a particular test plan either from the Test hub test plan context menu or from the Kanban board test page in the common settings configuration dialog. このオプションは既定ではオフになっているので、オンにするには、オプションを明示的に有効にする必要があります。This option is turned off by default and you will have to explicitly enable it to take effect.

Configure test outcomes
"*(図 73) テスト結果の構成*"*(Figure 73) Configure test outcomes*

#####作業項目からのバグの検証Verify bugs from work item バグを特定したテストを再び実行してバグを検証できるようになりました (図 74)You can now verify a bug by re-running the tests which identified the bug (Figure 74). バグの作業項目フォーム コンテキスト メニューの検証オプションを呼び出して、Web ランナーで関連するテスト ケースを開始できます。You can invoke the Verify option from the bug work item form context menu to launch the relevant test case in the web runner. Web ランナーを使用して検証を実行し、Web ランナーで直接バグ作業項目を更新します。Perform your validation using the web runner and update the bug work item directly within the web runner.

Verify bugs
"*(図 74) バグの検証*"*(Figure 74) Verify bugs*

#####テスト計画の REST API/テスト スイートの複製REST APIs for test plan / test suite clone テスト計画とテスト スイートのクローンを作成する REST API が追加されました。We've added REST APIs for cloning of test plans and test suites. これは、Team Services 統合サイトのテスト管理セクションの下にあります。You can find them under the Test Management section on our Team Services Integrate site.

かんばんカードからの進行状況のテストTest progress from your Kanban cards

かんばんボードのストーリーから直接テスト ケースを追加、表示、およびテスト ケースと対話できるようになりました。You can now add, view, and interact with test cases directly from your stories on the Kanban board. 新しい [テストの追加] メニュー オプションを使用して、リンクされたテスト ケースを作成し、進行状況に合わせてカードからステータスを直接監視します (図 75)Use the new Add Test menu option to create a linked Test case, and then monitor status directly from the card as things progress (Figure 75).

Inline tests
"*(図 75) インライン テスト*"*(Figure 75) Inline tests*

この新機能により、ボードのカードから以下の操作を直接実行できるようになりました。With this new capability, you can now perform the following actions directly from a card on your board:

  • テストを追加する。Add tests.
  • テストを開く。Open tests.
  • 1 つのユーザー ストーリーから別のユーザー ストーリーにドラッグ/ドロップすることにより、テストの親を再設定します。Reparent a test by dragging/dropping from one user story to another.
  • Ctrl を押しながらドラッグ/ドロップして同じテストを別のユーザー ストーリーにコピーします (同じテスト ケースが複数のユーザー ストーリーをテストするシナリオの場合)。Copy the same test to another user story using CTRL+Drag/Drop (for scenarios where the same test case tests more than one user story).
  • 合格、失敗、などのようにすばやくマークすることで、テストの状態を更新します。Update the test status by quickly marking it Pass/Fail/etc.
  • Web テスト ランナーを起動して、テストを実行します。この Web テスト ランナーから、個々のステップ、ファイル、バグを合格/失敗として設定することができます。Run the test by launching it in the Web Test Runner, from which you can pass or fail individual steps, file bugs, etc.
  • 合格したテストの数、およびそのストーリーに残る数を示すロールアップの状態の概要を表示します。View a summary of the roll-up status indicating how many tests have passed and how many remain for that story.

(テスターの割り当て、構成の割り当て、一元的なパラメーター、テスト結果のエクスポートなど) 高度なテスト管理機能が必要な場合、テスト ハブに切り替え、自動作成される既定のテスト計画/要件に基づくスイートの使用を開始することができます。If you need advanced test management capabilities (like assign testers, assign configurations, centralized parameters, exporting test results, etc.), you can then switch over to Test Hub and start using the default test plan/requirement-based suites that have been auto-created for you. 詳細については、「Add, run, and update inline tests (インライン テストの追加、実行、更新)」を参照してください。For more information, see Add, run, and update inline tests.

#####カードからテスト計画/テスト スイートに移動するTraverse to a test plan/test suite from the card かんばんボード上のカードから直接、テストが作成される基礎的なテスト計画/テスト スイートに簡単に移動できますようになりました。You can now easily traverse to the underlying test plan/test suite under which the tests are created, directly from a card on the Kanban board. このリンクをクリックすると (図 76)、テスト ハブに移動し、適切なテスト計画が開き、それらのインライン テストを制御する特定のスイートが選択されます。Clicking on this link (Figure 76) will take you to the Test hub, open the right test plan, and then select the specific suite that controls those inline tests.

Traverse to plan/suite
"*(図 76) 計画/スイートにトラバースする*"*(Figure 76) Traverse to plan/suite*

#####かんばんボード上の共通設定の構成におけるテスト ページTest page in common settings configuration of Kanban board かんばんボード上で共通設定を構成するためのダイアログ ボックスの新しいページを使用し、インライン テストが作成されるテスト計画を制御します (図 77)Use the new Tests page in common settings configuration dialog on Kanban board to control the test plan where the inline tests are created (Figure 77). これまで、カード上でテストが作成された場合、カードの区分/イテレーション パスに一致するテスト パスが存在していないと、作成されたテストはいずれも新しく作成されたテスト計画に自動的に追加されていました。Previously, any tests created on a card would automatically be added to a newly created test plan, provided no test plans existed that matched the area & iteration paths of the card. 今回、この動作は、使用する既存のテスト計画を構成することにより上書きできるようになりました。テストはすべて、選択した進行中のテスト計画に追加されます。Now, you can override this behavior by configuring an existing test plan of your choice – all the tests will then be added to the selected test plan going forward. この機能は、テストの注釈をオンにした場合にのみ有効になります。Note that this functionality is only enabled if the Test annotation is turned on.

Common settings
"*(図 77) 一般的な設定*"*(Figure 77) Common settings*

Web ランナーの機能強化Web runner enhancements

#####手動テストの際のテスト ステップの添付ファイルの追加Add test step attachments during manual testing 手動テストの際にテスト ステップの添付ファイルを追加できるよう Web テスト ランナーが機能強化されました (図 78)We’ve enhanced the Web test runner to give you the ability to add test step attachments during manual testing (Figure 78). これらのステップ結果添付ファイルは、セッションおよびその後 [テスト結果] ペインで登録するバグに自動的に表示されます。These step result attachments automatically show up in any bugs you file in the session and subsequently in the Test results pane.

Test Step attachments
"*(図 78) テスト ステップの添付ファイル*"*(Figure 78) Test Step attachments*

#####Web ランナーのスクリーンショット、画面記録、イメージ アクション ログ、システム情報サポート (Chrome ブラウザーを使用)Screenshot, screen recording, image action log and system info support in Web runner (using Chrome browser) Chrome で Web ランナーを使用するとき、スクリーンショットを取り、その内部に注釈を追加できるようになりました (図 79)You can now take screenshots and annotate them inline when you use Web runner in Chrome (Figure 79). オンデマンドで画面記録をキャプチャすることもできます。これは Web アプリだけでなく、デスクトップ アプリでも行えます。You can also capture on-demand screen recordings of not just the web apps, but also your desktop apps. これらのスクリーンショットと画面記録は、現行のテスト ステップに自動的に追加されます。These screenshots and screen recordings are automatically added to the current Test step. スクリーンショットと画面記録のほか、オンデマンドのイメージ アクション ログを Web アプリからキャプチャできるようになりました。In addition to screenshots & screen recordings, you can also capture on-demand image action log from your web apps. 操作をキャプチャするブラウザー ウィンドウを指定する必要があります。これにより、指定したウィンドウ (そのウィンドウで開いている既存のタブまたは新しいタブ) または新たに起動した子ブラウザー ウィンドウでの操作はすべて、自動的にキャプチャされ、Web ランナーでテスト中のテスト ステップに関連付けられます。You need to specify the browser window on which to capture your actions – all actions on that window (any existing or new tabs you open in that window) or any new child browser windows you launch, will automatically be captured and correlated against the test steps being tested in the Web runner. これらのスクリーンショット、画面記録、イメージ アクション ログは、実行中にファイルに保存したバグに追加され、最新のテスト結果に添付されます。These screenshots, screen recordings and image action logs are then added to any bugs you file during the run and attached to the current test result. 同様に、システム情報データが自動的に取り込まれ、ファイル、Web ランナーからバグの一部として含まれています。Similarly, the system information data is automatically captured and included as part of any bugs you file from the Web runner. これらすべてで、Chrome ベースのテストとフィードバック拡張機能の機能が利用されます。All these leverage the capability from the Chrome-based Test & Feedback extension.

Web runner using Chrome browser
"*(図 79) Chrome ブラウザーを使用した Web ランナー*"*(Figure 79) Web runner using Chrome browser*

詳細については、テスト中の診断データの収集に関するページを参照してください。For more information, see Collect diagnostic data during tests.

#####子として登録されているバグ – Web ランナー/テストとフィードバック拡張機能Bugs filed as children – Web runner/test & feedback extension Web ランナーでテストを実行する際にボードのカードまたはテスト ハブの要件ベースのスイートから起動されると、登録される新規バグがそのユーザー ストーリーの子として自動的に作成されるようになりました。When running tests in Web runner, launched either from a card on the board or from a requirement-based suite in Test hub, any new bugs filed will now be automatically created as a child to that user story. 同様に、探索的テスト拡張機能からユーザー ストーリーを探索する場合にも、登録する新規バグがそのユーザー ストーリーの子として作成されます。Similarly, if you are exploring a user story from the exploratory testing extension, any new bugs you file will also be created as a child to that user story. この新しい動作により、ストーリーおよびバグでより簡単に追跡が行えるようになります。This new behavior allows for simpler traceability across stories and bugs. これは、共通設定の構成ページにある [バグの作業] 設定が、"バックログやボードにバグが表示されません。" または "バックログとボードにバグがタスクとして表示されます。" に設定されている場合にのみ適用されます。This is applicable only if the “Working with bugs” settings in the Common Settings Configuration page is set to “Bugs do not appear on backlogs or board” or "Bugs appear on the backlogs and boards with tasks". [バグの作業] オプションがその他の設定になっている場合、関連するリンクが代わりに作成されます。また、親が既に定義されている既存のバグに追加する場合など、その他の特定シナリオでも、関連するリンクが作成されます。For all other settings for “Working with bugs” option and in certain other scenarios, such as adding to an existing bug that already has a parent defined, a Related link will be created instead.

#####Web ランナーでの既存のバグの更新Update existing bugs from Web runner Web ランナーでは、新しいバグの作成に加えて、既存のバグを更新することもできるようになりました (図 80)In addition to creating new bugs from the Web runner, now you can also update an existing bug (Figure 80). 収集された診断データ、再現手順、現在のセッションからの追跡可能性に関するリンクはすべて、既存のバグに自動的に追加されます。All the diagnostic data collected, repro steps, and links for traceability from the current session are automatically added to the existing bug.

Add to existing bug
"*(図 80) 既存のバグへの追加*"*(Figure 80) Add to existing bug*

テストとフィードバック拡張機能 - 機能強化Test & feedback extension - enhancements

ブラウザーベースのテストとフィードバック拡張機能は、Visual Studio Marketplace からインストールできます。The browser-based Test & Feedback extension can be installed from the Visual Studio Marketplace. Visual Studio Team Services と Team Foundation Server (2015 以降) の両方がサポートされます。It supports both Visual Studio Team Services and Team Foundation Server (2015 or later).

#####作業項目の探索Explore work items 特定の作業項目に対して探索的テストを実行できるようになりました (図 81)You can now do exploratory testing for a specific work item (Figure 81). これにより、選んだ作業項目と進行中のテスト セッションとが関連付けられ、拡張機能内で受け入れ基準と説明を表示することができます。This lets you associate the selected work item with your ongoing testing session, and view the acceptance criteria and description, from within the extension. また、選択した作業項目でファイリングするバグまたはタスクの間でエンドツーエンドの追跡ができるようになります。It also creates end-to-end traceability between bugs or tasks that you file on the selected work item. 作業項目は、作業項目から直接探索することも、拡張機能内で探索することもできます。You can explore the work item either directly from a work item, or from within the extension:

• 作業項目から直接 (図 81): コンテキスト メニューにある [探索的テストの実行] オプションを使用して、特定の作業項目の探索的テスト セッションを製品内から直接起動します。• Directly from a work item (Figure 81): Launch exploratory testing session for a specific work item directly from within the product using the “Do exploratory testing” option in the context menu. すべてのカード、グリッド、およびテスト ハブにエントリ ポイントが追加されました。We’ve added entry points on all cards, grids, and in the Test hub.

• 拡張機能内で (図 82): XT セッションで作業項目を検索し、進行中のセッションと関連付けます。• Within the extension (Figure 82): Search for a work item from within the XT session and then associate it with the ongoing session.

XT from card
"*(図 81) 作業項目からの XT*"*(Figure 81) XT from work item*
Explore work item
"*(図 82) 拡張機能からの XT*"*(Figure 82) XT from extension*

詳細については、「Explore work items with the Test & Feedback extension (テストとフィードバック拡張機能を使用した作業項目の探索)」を参照してください。For more information, see Explore work items with the Test & Feedback extension.

テストとフィードバックを使用した、イメージ アクション ログ、画面記録、Web ページの読み込みデータのキャプチャCapture image action log, screen recordings and web page load data using test & feedback

イメージ操作ログ: 拡張機能には、バグの原因となった手順をワンクリックで自動的に追加する新規オプションがあります。Image Action Log: The extension gives you a new option to add the steps that lead you to the bug automatically with just one click. [Include image action log] (イメージ アクション ログを含める) オプション (図 83) をオンにすると、マウス、キーボード、タッチ操作をキャプチャして、対応するテキストとイメージを直接バグやタスクに追加できます。Select the “Include image action log” option (Figure 83) to capture the mouse, keyboard, and touch actions, and add the corresponding text and images directly into the bug or task.

ビデオとしての画面記録: 拡張機能を使用してオンデマンドで画面記録をキャプチャすることもできます。Screen recording as video: You can also capture on-demand screen recordings using the extension. これらの画面記録は、Web アプリからだけでなく、デスクトップ アプリからもキャプチャできます。These screen recordings can be captured not just from the web apps, but also your desktop apps. 拡張機能を構成することで、画面記録を自動的に停止し、拡張機能の [オプション] ページを使用して登録されているバグにそれらを添付できます。You can configure the extension to automatically stop screen recordings and attach them to a bug being filed using the extension’s “Options” page.

ページの読み込みデータ: "Web ページの読み込み" データをキャプチャするという、新しいバックグラウンド キャプチャ機能を拡張機能に追加しました。Page Load Data: We have added a new background capture capability to the extension – capturing of “web page load” data. "イメージ操作ログ" 機能が、探索中の Web アプリで実行されている操作をバック グラウンドにてイメージ形式でキャプチャしたのと同様に、"ページ読み込み" 機能は Web ページで実行される読み込み操作の詳細を自動的にキャプチャします。Just like the “image action log” captured your actions performed on a web app being explored, in the form of images in the background, the “page load” functionality automatically captures details for a web page to complete the load operation. Web ページ読み込みの主観的/認識されるパフォーマンス低下に依存するのでなく、バグによるパフォーマンス低下を客観的に定量化できるようになりました。Instead of relying on subjective/perceived slowness of web page load, you can objectively quantify the slowness in the bug now. バグがファイルに保存されると、タイル ビューに加えて、詳細なレポートもバグにアタッチされます。これは、開発者が一連の初期調査を行う場合に役に立ちます。Once the bug is filed, in addition to the tile view, a detailed report is also attached to the bug, which can help the developer with their initial set of investigations.

XT Image Action Log
"*(図 83) XT イメージ操作ログ*"*(Figure 83) XT Image Action Log*
イメージ操作ログ データに基づくテスト ケースの作成Create test cases based on image action log data

探索的セッション中にテスト ケースを作成するとき、イメージを持つテスト ステップが自動的に入力されます (図 84)When you create test cases during your exploratory session, the test steps with images are automatically filled in for you (Figure 84). 同時テスト設計およびテスト実行は、実際の探索的テストの基礎であり、この新機能によってそれが現実となります。Simultaneous test design and test execution is the basis of true exploratory testing, and this new capability makes this a reality. キャプチャされたテキストを編集し、予期する結果を追加し、関連しない行をオフにし、予定されているテストの合格/実行のために保存することができます。You can edit the text captured, add the expected result, uncheck rows not relevant, and save it for upcoming test passes/runs.

XT Create Test Cases
"*(図 84) XT のテストケースの作成*"*(Figure 84) XT Create Test Cases*

詳細については、イメージ アクション ログ データに基づいたテスト ケースの作成に関するページを参照してください。For more information, see Create test cases based in image action log data.

探索的テスト セッションの洞察Exploratory testing session insights

完了した探索的テスト セッションを、テストとフィードバック拡張機能を使用して作成された特定の期間中、チーム レベルまたは個人レベルで表示できるようになりました。You can now view the completed exploratory testing sessions, either at a team or individual level, for a given time period created using the Test & Feedback extension. Web アクセスのテスト ハブ グループ内の実行ハブの [最近の探索的セッション] リンクをクリックして、この分析情報ページにアクセスできます。You can get to this insights page by clicking the “Recent exploratory sessions” link in the Runs hub within the Test Hub group in web access. この新しいビューは、意味のある洞察を得るために役立ちます。以下に例を挙げます。This new view helps you derive meaningful insights, including:

  • 概要ビューには、探索された作業項目の内訳、作成された作業項目、セッション所有者、およびこれらのセッションで費やされた合計時間が表示されます (図 85)The summary view that shows a breakdown of the work items explored, the work items created, and the session owners, along with the total time spent on these sessions (Figure 85).
  • [グループ化] ビューは、探索された作業項目、セッション、セッション所有者、"なし" のいずれからでもピボットすることができます。The group-by view that can be pivoted by either explored work-items, sessions, session owners, or none. ピボットでは、すべての作業項目 (バグ、タスク、テスト ケース) のリストを表示したり、特定の作業項目タイプに範囲を絞ったりすることができます。For any pivot, you can either view the list of all work items (bugs, tasks, test cases) created or scope the list down to a specific work item type.
  • [グループ化] ビューで選択内容に基づいて情報を表示する詳細ペインの表示。The details pane view that displays information based on selection in the group-by view. 選択したピボット行 (たとえば探索される作業項目) で、詳細ペインに概要情報を表示することができます。たとえば、セッションの総数、これらのセッションで費やされる合計時間、探索したセッション所有者、およびそれに対して作成されたバグ/タスク/テスト ケース、およびその状態と優先順位などです。For a selected pivot row (say explored work items), you can view its summary information in the details pane, such as the total number of sessions, the total time spent across these sessions, the session owners who explored it, and the bugs/tasks/test cases created against it, along with their state and priority. 選択した作業項目行では、その作業項目フォームのインラインを表示し、必要に応じて変更を加えることができます。For a selected work item row, you can view its work item form inline and make changes as appropriate.
XT Session insights
"*(図 85) XT セッションの洞察*"*(Figure 85) XT Session insights*

詳細については、「Get insights across your exploratory testing sessions (探索的テスト セッションからの情報の取得)」を参照してください。For more information, see Get insights across your exploratory testing sessions.

######探索的テスト セッション: 未探索の作業項目の表示Exploratory testing sessions: View unexplored work items 探索したすべての作業項目の詳細を、指定のデータ範囲についてすべてのセッション/マイ セッションでフィルター処理して、[最近使用した探索的セッション] ビューに表示することに加えて、探索していないすべての作業項目の一覧についても同じビューで表示できるようにしました (図 86)In addition to seeing the details of all the explored work items in the “recent exploratory sessions” view, filtered by all/my sessions for a given date range, we have now added the ability to also see a list of all work items that have NOT been explored, in the same view (Figure 86). まず、注目する作業項目に対する共有クエリを指定します。[セッション] ページの [概要] セクションに、クエリから得られたすべての作業項目の一覧が探索済み項目と未探索項目に分けて表示されます。You start by specifying a shared query for work items that you are interested in and the sessions page shows a list of all the work items from the query, with a breakdown of both explored and unexplored items in the summary section. さらに、ピボットによる [未探索の作業項目] グループを使用すると、まだ探索されていない項目の一覧を表示できます。In addition, using the “Unexplored Work Item” group by pivot, you can see the list of items that have not been explored yet. これは、まだ探索されていないストーリー数、およびバグ検証機能にまだ通していないストーリー数を追跡する場合に非常に便利です。This is extremely useful to track down how many stories have not been explored or gone through a bug-bash yet.

View unexplored WIT
"*(図 86) 未探索の WIT を表示する*"*(Figure 86) View unexplored WIT*
利害関係者によるエンド ツー エンドのフィードバックのフローEnd to end stakeholder feedback flow
フィードバックの要求Request feedback

基本的なアクセス レベルのユーザーは、作業項目メニューの [フィードバックの要求] オプションを使用することで、進行中または完了した機能/ストーリーについて直接、利害関係者からのフィードバックを要求できるようになりました (図 87)Users with basic access level can now request feedback from stakeholders directly for ongoing or completed features/stories using the Request Feedback option in the work item menu (Figure 87). この操作により、フィードバック要求フォームが開き、フィードバックを受けたい利害関係者を選択できます。必要に応じて、フィードバックが欲しい製品の部分を知らせる簡単な指示を入力します。This opens the Request feedback form where you can choose the stakeholders you want feedback from and optionally provide a simple set of instructions prompting for the areas of the product you’d like input. これにより、(入力された指示がある場合はそれと共に) 選択した利害関係者に個別にメールが送信されます。This will send off individual mails to the selected stakeholders along with the instructions provided, if any.

XT Feedback Flow
"*(図 87) XT フィードバック フロー*"*(Figure 87) XT Feedback Flow*

詳細については、「Request stakeholder feedback using the Test & Feedback extension (テストとフィードバック拡張機能を使用した利害関係者からのフィードバックの要求)」を参照してください。For more information, see Request stakeholder feedback using the Test & Feedback extension.

フィードバックの提供Provide feedback

利害関係者は、届いたメールの [Provide feedback (フィードバックの送信)] リンクをクリックして、フィードバックの要求に応えることができます。選択したフィードバックの要求で、テストとフィードバック拡張機能 (以前の探索的テストの拡張機能) が自動的に構成されます (まだインストールしていない場合、拡張機能をインストールするよう求められます)。Stakeholders can respond to the feedback request by clicking the Provide feedback link in the mail they received, which automatically configures the Test & Feedback extension (formerly Exploratory Testing extension) with the selected feedback request (it will prompt to install the extension, if not already installed). その後、拡張機能のキャプチャ機能をフル活用して調査結果をキャプチャし、フィードバック応答、バグ、タスクの各作業項目の形式でフィードバックを送信できるようになります。Stakeholders can then use the full capture capabilities of the extension to capture their findings and submit their feedback in the form of feedback response/bug/task work items. また、利害関係者は、[フィードバックの要求] ページに移動して、届いたフィードバックの要求をすべて 1 か所で表示できます。Additionally, stakeholders can navigate to the “Feedback requests” page to view in one place all feedback requests received by them. 一覧では、返信するフィードバックの要求を選択できるほか、完了のマークを付けたり拒否したりすることで、"保留中のフィードバックの要求" を管理できます (図 88)。また、目的のオプション ボタンをクリックして、フィードバックの要求を種類ごとに切り替えることができます (図 89)From the list, they can select the feedback request they want to provide feedback on, manage their “Pending feedback requests” (Figure 88) by marking them as complete or by declining them and can switch between different types of feedback requests by clicking on the desired radio button (Figure 89).

Provide feedback link
"*(図 88) フィードバック リンクの提供*"*(Figure 88) Provide feedback link*
XT Feedback Flow
"*(図 89) XT フィードバック フロー*"*(Figure 89) XT Feedback Flow*

詳細については、テストとフィードバック拡張機能を使用したフィードバックの送信に関するページを参照してください。For more information, see Provide feedback using the Test & Feedback extension.

自発的なフィードバックVoluntary feedback

利害関係者は、上記のように要請されて行うフローのほか、拡張機能を使用して自発的にフィードバックを提供することもできます (図 90)In addition to the solicited flow mentioned above, stakeholders can also use the extension to provide voluntary feedback (Figure 90). 拡張機能を開いて接続の設定ページで [Connected (接続完了)] モードを選択し、フィードバックを提供したい相手のアカウントとプロジェクト/チームに接続できます。They can open the extension, select the “Connected” mode in the Connection settings page, and connect to the account and Project/Team to whom they wish to provide feedback. その後、拡張機能を使用して調査結果をキャプチャし、フィードバック応答、バグ、タスクの各作業項目の形式でフィードバックを送信できるようになります。They can then use the extension to capture their findings and submit their feedback in the form of feedback response/bug/task work items.

Voluntary Feedback
"*(図 90) 自発的なフィードバック*"*(Figure 90) Voluntary Feedback*

詳細については、テストとフィードバック拡張機能を使用した自発的なフィードバックの提供に関するページを参照してください。For more information, see Provide voluntary feedback using the Test & Feedback extension.

自動テストの機能強化Automated testing improvements

#####ビルド/リリースの概要の [テスト] タブのコンソール ログとテスト期間Console logs and test duration in tests tab in build/release summary trx ファイルでキャプチャされたテスト結果のコンソール ログは、抽出されてテスト結果の添付ファイルとして発行されます (図 91)Test result console logs that are captured in .trx files are extracted and published as test result attachments (Figure 91). これらは [テスト] タブでプレビューできるため、ログを表示するために trx ファイルをダウンロードする必要がなくなりました。You have an option to preview them in Tests tab, and don't need to download the trx file to view logs anymore.

Console logs and duration
"*(図 91) コンソール ログと期間*"*(Figure 91) Console logs and duration*
ビルド用のテスト傾向ウィジェットTest trend widget for builds

ウィジェットのギャラリーに新しい "テスト結果トレンド" ウィジェットが追加されました (図 92)We have added a new 'Test result trend' widget to the Widget Gallery (Figure 92). このウィジェットを使用すると、ビルド定義に対する最新の 30 個までのビルドについて表示するテスト結果トレンド グラフをダッシュボードに追加できます。Use this widget to add a test result trend chart of up to 30 most recent builds for a build definition to the dashboard. ウィジェット構成オプションを使用して、合格したテストの数、失敗したテストの数、テストの合計数、合格のパーセンテージ、テスト期間といったピボットを含めるようにグラフをカスタマイズできます。Widget configuration options can help you customize the chart to include pivots like passed test count, failed test count, total test count, pass percentage, and test duration.

'Test result trend' widget
"*(図 92) 'テスト結果トレンド' ウィジェット*"*(Figure 92) 'Test result trend' widget*

#####リリース環境の概要でのテスト ステータスTest status with Release Environment summary リリース環境を使用してアプリケーションを展開し、アプリケーションに対するテストを実行することをお勧めします。It’s a recommended practice to use Release Environments to deploy applications and run tests against them. このリリースでは、リリース概要ページの [環境] セクションにリリース環境のテスト成功率を統合しました (図 93)With this release, we have integrated test pass rate of Release Environments in the Environments section of the Release summary page (Figure 93). スクリーン ショットに示すように、環境でエラーが発生した場合は、[テスト] 列を確認することで、エラーの原因がテストの失敗にあるのかどうかをすぐに推測できます。As shown in the screenshot, if an Environment has failed, you can quickly infer if the failure is because of failing tests by looking at the Tests column. 合格率をクリックして [テスト] タブに移動すれば、問題の環境で失敗したテストを調査することができます。You can click on the pass rate to navigate to the Tests tab and investigate the failing tests for that Environment.

Test status with Release Environment summary
"*(図 93) リリース環境の概要でのテスト ステータス*"*(Figure 93) Test status with Release Environment summary*

#####ブランチおよびリリース環境の自動テストの履歴Automated test history for branches and release environments 個々のテストを複数のブランチ、環境、および構成で実行するのは一般的なシナリオです。It’s a common scenario for an individual test to run on multiple branches, environments, and configurations. このようなテストが失敗した場合、マスター ブランチなどの開発ブランチにおよぶエラーが含まれているのかどうかどうか、エラーが、運用環境に展開されるリリース ブランチにも影響を与えているかどうかを識別することが重要です。When such a test fails, it is important to identify if the failure is contained to development branches like the master branch or if failures are also impacting release branches that deploy to production environments. [結果概要] ページの [履歴] タブを確認することにより、テスト対象の各種ブランチでのテストの履歴を視覚化できるようになりました (図 94)You can now visualize the history of a test across various branches that it is testing by looking at the History tab in Result summary page (Figure 94). 同様に、テストが実行されているさまざまなリリース環境でのテストの履歴を視覚化するために、環境ピボットでグループ分けすることができます。Similarly, you group by the Environment pivot to visualize the history of a test across different Release Environments in which its run.

Test status with Release Environment summary
"*(図 94) リリース環境の概要でのテスト ステータス*"*(Figure 94) Test status with Release Environment summary*

######継続的なテストでの追跡可能性Traceability with continuous testing ユーザーは自分のダッシュボード上で要件の品質を追跡できるようになりました (図 95)Users can now track the quality of their Requirements right on their Dashboard (Figure 95). Microsoft は計画されたテスト ユーザー向けの要件の品質に対するソリューションを既に用意しており、継続的なテストを取り入れているユーザーに提供します。We already have a solution for Requirements quality for our Planned testing users and we are bringing it to our users who follow Continuous Testing. ユーザーは自動テストを要件に直接リンクさせ、ダッシュ ボードのウィジェットを使用することで、ビルドまたはリリースからの品質データを取得しながら、追跡対象とされている要件の品質を追跡することができます。Users will be able to link automated tests directly to Requirements and then use Dashboard widgets to track the quality of Requirements you are interested in tracking, pulling the Quality data from Build or Release.

Requirement Quality Widget
"*(図 95) 要件品質ウィジェット*"*(Figure 95) Requirement Quality Widget*

#####リモート テスト - コンピューターの台数に基づいてテストを配布するRemote testing – distribute tests based on number of machines [機能テストの実行] タスクを使用してアセンブリ内のテストをリモート コンピューターに配布できるようにしました (図 96)We have enabled tests from within an assembly to be distributed to remote machines using the Run Functional Tests task (Figure 96). TFS 2015 では、アセンブリ レベルでしかテストを配布できませんでした。In TFS 2015, you could distribute tests only at the assembly level. これは、次のようにタスク内のチェック ボックスを使用して有効にすることができます。This can be enabled using the check box in the task as below.

Task Setting
"*(図 96) タスク設定*"*(Figure 96) Task Setting*

#####SCVMM と VMWare の自動テストAutomated testing for SCVMM and VMWare ユーザーは、クラウド (Azure を使用) またはオンプレミス (SCVMM または VMWare を使用) にテスト マシンを動的に設定し、これらのマシンを使用してテストを分散方式で実行できます。Users can dynamically set up test machines in the cloud with Azure, or on premises using SCVMM or VMWare, and use these machines to run their tests in a distributed manner. ユーザーは、Azure、SCVMM、または VMWare のいずれかのマシン プロビジョニング タスクに続けて機能テストの実行タスクを実行して、テストを実行できます。Users can use one of the machine provisioning tasks— Azure, SCVMM, or VMWare—followed by the Run Functional Tests task to run tests.

#####Maven タスクおよび Gradle タスクでの SonarQube 分析SonarQube analysis in Maven and Gradle tasks Maven および Gradle ビルド タスクで SonarQube 分析をトリガーできるようになりました。そのためには、[SonarQube の解析を実行] をオンにし、エンドポイント、SonarQube プロジェクト名、プロジェクト キー、およびバージョンを指定します (図 97)You can now trigger a SonarQube analysis in the Maven and Gradle build task by checking 'Run SonarQube Analysis', and providing the endpoint, the SonarQube project name, the project key, and the version (Figure 97).

Run SonarQube Analysis
"*(図 97) SonarQube 分析の実行*"*(Figure 97) Run SonarQube Analysis*

また、SonarQube プロジェクトでリンクが表示されるようになりました (図 98)You will also now get a link on the SonarQube project (Figure 98). 品質ゲートの詳細を表示する完全な分析を要求し、品質条件が満たされていない場合はビルドを中断することができます。You can request a full analysis to see the quality gates details, and choose to break the build if they are not met.

Run SonarQube Analysis
"*(図 98) SonarQube 分析の実行*"*(Figure 98) Run SonarQube Analysis*

詳細については、「The Gradle build task now supports SonarQube analysis」 (Gradle ビルド タスクで SonarQube 解析をサポートするようになりました) を参照してください。For more information, please see The Gradle build task now supports SonarQube analysis.

Marketplace の機能強化 Marketplace Improvements

プロジェクト コレクション管理者は、Team Foundation Server から Visual Studio Marketplace を参照し、チーム プロジェクト コレクションに無料の拡張機能をインストールできるようになりました。Project collection administrators can now browse to the Visual Studio Marketplace from a Team Foundation Server and install free extensions in a team project collection. 拡張機能は自動的に Visual Studio Marketplace からダウンロードされ、Team Foundation Server にアップロードされ、選択したチーム プロジェクト コレクションにインストールされます (図 99)The extensions are automatically downloaded from the Visual Studio Marketplace, uploaded to the Team Foundation Server, and installed in the selected team project collection (Figure 99).

Install Free Extension
"*(図 99) 無料の拡張機能のインストール*"*(Figure 99) Install Free Extension*

有料の拡張機能の購入とインストールPurchase and install paid extensions

プロジェクト コレクション管理者は、Team Foundation Server から Visual Studio Marketplace を参照し、有料の拡張機能を購入し、選択したチーム プロジェクト コレクションにインストールできるようになりました (図 100)Project collection administrators can now browse to the Visual Studio Marketplace from a Team Foundation Server, buy paid extensions, and install them in a selected team project collection (Figure 100). 管理者は、Azure サブスクリプションで拡張機能の支払いをして、購入した拡張機能を割り当てるユーザー数を選択することができます。The administrator can pay for extensions with an Azure subscription and select the number of users to assign these extensions. これらの拡張機能は自動的に Visual Studio Marketplace からダウンロードされ、Team Foundation Server にアップロードされ、選択したチーム プロジェクト コレクションにインストールされます。These extensions are automatically downloaded from the Visual Studio Marketplace, uploaded to the Team Foundation Server, and installed in the selected team project collection.

Purchase Paid Extension
"*(図 100) 有料の拡張機能の購入*"*(Figure 100) Purchase Paid Extension*

詳細については、「Get extensions for Team Foundation Server」 (Team Foundation Server の拡張機能の入手) のドキュメントを参照してください。For more details, see Get extensions for Team Foundation Server documentation.

管理の機能強化 Administration Improvements

####Windows 認証Windows Authentication 以前のリリースでは、ドメインに参加している TFS の配置を構成する際に、Windows 認証で使用するセキュリティ サポート プロバイダーとして NTLM と Negotiate のどちらかを選ぶ必要がありました。In previous releases, you needed to decide between NTLM and Negotiate security support providers for Windows Authentication when configuring a domain-joined TFS deployment. 2017 では、構成操作からこの設定が削除されています。In 2017, we removed this setting from the configuration experience. 2017 で NTLM 認証を引き続き使用する場合は、操作をする必要はありません。If you want to continue using NTLM authentication in 2017, you do not need to take any action. Kerberos 認証を使用しており、2017 で引き続き使用する場合も、操作をする必要はありません。If you had been using Kerberos authentication and want to continue doing so in 2017, you do not need to take any action. TFS 2017 では常に、Negotiate および NTLM の両方のセキュリティ サポート プロバイダーを順に構成するようになりました。TFS 2017 now always configures both the Negotiate and NTLM security support providers, in that order. この構成では、セキュリティ強化のため、可能であれば Kerberos 認証が使用されます。With this configuration, Kerberos authentication will be used where possible, providing enhanced security. Kerberos を使用できない場合は、NTLM 認証が使用されます。When Kerberos cannot be used, NTLM authentication will be used. この変更に伴う NTLM 認証の使用による既存の TFS 配置への影響を防ぐため、広範なテストが行われました。We did extensive testing to ensure that there would not be any impact on existing TFS deployments using NTLM authentication due to this change.

最新のナビゲーション エクスペリエンスA Modern navigation experience

このリリースでは、新機能の追加と機能強化が行われた上部ナビゲーション バーを提供します。In this release, we are enabling a new and improved top navigation bar. 新しいナビゲーション バーには次の 2 つの主要な目標があります。There are two core goals for the new nav:

  • 1 回のクリックで任意のハブに迅速にアクセスできるようにすることで、製品区分間のナビゲーション効率を向上させます。Increase navigation efficiency across product areas by quickly allowing you access any of the hubs with one click.
  • 最新の視覚的外観とユーザー エクスペリエンスを製品にもたらします。Bring a modern visual aesthetics and user experience to the product.

これは、ユーザーにとって大きな変更であり、機能は引き続き反復処理されるので、既定では、新しいナビゲーション UX をオフにすることに決めました。Since this is a big change for our users, and the feature is still being iterated on, we decided to have the new navigation UX off by default. 新しいナビゲーションを使用したい場合は、Team Foundation Server 管理領域のコントロール パネルに進み、[新しいナビゲーションをオンにします] をオンにします。If you want to play with it, you can enable it by going to the Team Foundation Server admin area Control Panel and choosing to “Turn on new navigation”. その場合、サーバー内のすべてのユーザーで新しいナビゲーションが有効になるので注意してください。Please note that will enable it for all users in the server.

チーム プロジェクトの名前の変更アクセス許可Team project rename permission

チーム プロジェクトの名前を変更できるユーザーを制御するアクセス許可が変更されました。The permission controlling which users can rename a team project has changed. 以前は、チーム プロジェクトの [プロジェクト レベル情報を編集します] アクセス許可を持つユーザーが、その名前を変更できました。Previously, users with Edit project-level information permission for a team project could rename it. 新しい "チーム プロジェクトの名前変更" アクセス許可によって、チーム プロジェクトの名前を変更する許可をユーザーに対して付与または拒否できるようになりました。Now users can be granted or denied the ability to rename a team project through the new Rename team project permission.

管理者設定作業ハブAdmin settings Work hub

全般設定 (図 101)、イテレーション、および区分を 1 つのタブに結合する新しい [作業] ハブを管理設定ページに導入しました。この変更により、ユーザーはプロジェクト レベルの設定とチーム設定の相違点を明確に知ることができます。We've introduced a new "Work" hub in the Admin settings page that combines general settings (Figure 101), Iterations, and Areas in a single tab. With this change, users will see clear differences between project-level settings and team settings. チーム設定の場合、ユーザーには、チームに関係する区分とイテレーションだけが表示されます。For team settings, users will only see areas and iterations that are relevant to their team. プロジェクト レベルで、設定ページは、管理者がプロジェクト全体の区分とイテレーションを管理できるようにします。At a project level, the settings page will enable admins to manage areas and iterations for the entire project. また、プロジェクト区分パスに "チーム" という新しい列が追加され、特定の区分パスを選択したチームを、管理者が簡単かつ即座に見分けられるようになりました。Additionally, for project area paths, a new column called "Teams" has been added to make it convenient for admins to tell quickly and easily which teams have selected a specific area path.

Admin work hub
"*(図 101) 管理作業ハブ*"*(Figure 101) Admin work hub*

プロセス構成 REST APIProcess configuration REST APIs

このパブリック API により、ユーザーは特定のプロジェクトのプロセス構成を取得することができます。This public API allows users to get the process configuration of a given project. プロセス構成には、次の設定が含まれています。The process configuration contains the following settings:

  • TypeFields: アジャイル ツールで使用されているカスタマイズ可能なフィールドの抽出。TypeFields: abstractions of customizable fields that are used in the agile tooling. たとえば、"ストーリー ポイント" フィールドの種類は、"作業量" です。For example, the type of the "Story points" field is "Effort".
  • バックログの定義: 各バックログにある作業項目タイプを定義します。Backlog definitions: define what work item types are on each of the backlogs. これは、拡張機能を作成するお客様からよく求められる API です。This is a frequently requested API from customers building extensions. このデータにより、拡張機能は、アジャイル ツールで一般的なシナリオを使用できるようにするためにプロセス固有のフィールドを活用する方法がわかります (たとえば、作業項目のアクティビティまたは作業量の変更、特定のバックログ レベルで含まれる作業項目の判別、チームが区分パスまたはカスタム フィールドによって識別されるかどうかの判別など)。With this data, an extension can know how to leverage process-specific fields to enable common scenarios in the agile tools (such as changing the activity or effort of a work item, knowing what work items are included at a given backlog level, or determining whether teams are identified by area path or a custom field). 詳細情報については、作業の概要に関するページを参照してください。Please refer to Work Overview for more information.

Team Foundation Server 2017 では、グループとグループ メンバーシップを管理するために新しいエクスペリエンスを導入しています。Team Foundation Server 2017 introduces a new experience to manage groups and group membership. ユーザー/グループ名に対するプレフィックスに基づいた検索条件を使用して、アクティブ ディレクトリまたはローカル コンピューターのユーザー/グループで検索を行うことができます。You can search in active directory or local machine users/groups using prefix based search criteria on user/group name(s). たとえば、"John D" と samaccountname (例: "businessdomain\johbdnd")、ユーザー/グループの連絡先カードを参照してください。For example, 'John D' as well as samaccountname (e.g. 'businessdomain\johbdnd') and see the contact card of a user/group.

ユーザー セキュリティ設定User security settings

新しい "My Security" (マイ セキュリティ) エクスペリエンスで、個人用アクセス トークンと SSH を管理することができます (図 102)You can manage your personal access tokens and SSH in the new "My Security" experience (Figure 102). [マイ プロファイル] を使用して SSH を管理していたユーザーは、ユーザー セキュリティ設定で SSH 公開キーを管理することが必要になります (図 103)Users who were using "My Profile" to manage SSH will now need to manage their SSH public keys in the user security settings (Figure 103).

My security
"*(図 102) マイ セキュリティ*"*(Figure 102) My security*
My profile
"*(図 103) マイ プロファイル*"*(Figure 103) My profile*

統合された構成ウィザードUnified configuration wizard

以前のリリースでは、試行する内容に応じて、TFS 展開用の複数の構成ウィザードの中からいずれかを選択していました。新しい展開を構成する場合は [基本] ウィザードおよび[完全] ウィザードを使用していました。運用環境と運用前環境のアップグレードでは [アップグレード] ウィザードを使用していました。既存の展開のスケールアウトや新しいハードウェアへのアプリケーションの置換など、さまざまなシナリオで [アプリケーション層のみ] ウィザードを使用していました。In previous releases, you would pick one of multiple configuration wizards for your TFS deployment depending on what you were trying to do – the Basic and Full wizards could be used to configure a new deployment; the Upgrade wizard could be used for production and pre-production upgrades; and the Application-Tier Only wizard could be used for a variety of scenarios, including scaling out an existing deployment, replacing an application tier with new hardware, and so forth. TFS 2017 では、これらのシナリオがすべて、1 つのサーバー構成ウィザードに統合されました。このウィザードでは、簡単な選択を行うだけで、目的のシナリオに進み、必要な設定を行うことができます。In TFS 2017, all of these scenarios have been unified into a single Server Configuration Wizard, which guides you toward and then through each of these scenarios by asking you to make simple choices. さらに、運用前環境のアップグレードや既存の展開の複製などの高度な構成では、tfsconfig.exe を介して行われていた操作が自動化されました。たとえば、サーバー ID の変更、データベース接続文字列の再マップ、外部の依存関係への参照の削除 (これは tfsconfig.exe PrepareClone を使用して行われていました) などの操作が対象です。Additionally, advanced configurations like pre-production upgrades and clone existing deployment now automate actions which used to be done via tfsconfig.exe, including changing server IDs, remapping database connection strings, and removing references to external dependencies (which used to be done with tfsconfig.exe PrepareClone).

新しいアクセス レベルNew access level

Team Foundation Server のアクセス レベル管理ポータルに新しい Visual Studio Enterprise グループが追加されたことで、Visual Studio Enterprise のサブスクリプションを持っているユーザーをすばやく特定できるようになりました。With the new Visual Studio Enterprise group added to the Access Level admin portal in Team Foundation Servers, you can now quickly identify who has a Visual Studio Enterprise subscription. このようなユーザーは、いったん識別されると、追加料金なしで Visual Studio Marketplace からインストールされた 1 番目のパーティのすべての TFS 拡張機能に完全にアクセスすることができます。Once identified, these users will gain full access to all first party TFS extensions installed from the Visual Studio Marketplace at no additional charge.

個人用アクセス トークン Personal Access Tokens

SSH だけでなく個人用アクセス トークンを使用して、任意の Team Foundation Server に接続できるようになりました (図 104)You can now connect to any Team Foundation Server using a personal access token in addition to SSH (Figure 104). これは、Linux または Mac で開発を行い、任意のオートメーション ツールおよび GIT で使用する場合に便利です。This is helpful if you develop on Linux or Mac and would like to use in any automation tools and GIT. 個人用アクセス トークンは、ユーザー セキュリティ設定ページから管理できます。You can manage your personal access tokens from the user security settings page.

Personal Access Tokens
"*(図 104) 個人用アクセス トークン*"*(Figure 104) Personal Access Tokens*

既知の問題 Known Issues

これは、このリリースの既知の問題の完全な一覧です。This is a complete list of known issues in this release.

Team Foundation Server 2017 のパワー ツールはありません。There are no Power Tools for Team Foundation Server 2017

  • 問題:Issue:

    TFS 2017 では Power Tools がリリースされていません。No Power Tools have been released for TFS 2017.

  • 回避策:Workaround:

    以前の Power Tools はほとんど TFS 2017 に統合されたことをお知らせします。We are excited to let you know that most of the previous Power Tools have been integrated into TFS 2017. プロセス テンプレート エディターは統合されていませんが、Visual Studio Marketplace で取得できます。The Process Template Editor is one that has not been integrated, but you can get it in the Visual Studio Marketplace.

カスタム コントロールの拡張機能の更新Updating custom control extensions

作業項目の種類の定義をインポートしているときに発生するエラーError when importing work item type definition

  • 問題:Issue:

    作業項目ページの拡張機能をインストール済みのユーザーが、作業項目の種類の定義をエクスポートしてインポートしたときに、"The 'LayoutMode' attribute is not declared ('LayoutMode' 属性が宣言されていません)" というエラーが表示されます。Customers with a work item page extension installed, who export a work item type definition then import that definition, will see an error, “The ‘LayoutMode’ attribute is not declared”.

  • 回避策:Workaround:

    作業項目の種類の定義をエクスポートするたびに PageContribution 要素に LayoutMode 属性が追加されます。There is an extra LayoutMode attribute on the PageContribution element each time you export a work item type definition. 定義をインポートする前に、PageContribution モードを検索して LayoutMode 属性を削除してください。Before importing the definition, search for the PageContribution mode and remove the LayoutMode attribute. たとえば、LayoutMode="FirstColumnWide" を削除します。For example, remove LayoutMode="FirstColumnWide".

お客様は Git LFS バージョン 1.3.1 以降に更新する必要があります。Customers should update to Git LFS version 1.3.1 or higher

  • 問題:Issue:

    バージョン 1.3.1 より前のバージョンの Git LFS は、今後のリリースではサポートされません。Git LFS versions before 1.3.1 will not be supported in future releases.

  • 回避策:Workaround:

    Git LFS を使用しているお客様には、Git LFS バージョン 1.3.1 以降への更新を強くお勧めします。Customers using Git LFS are strongly encouraged to update to Git LFS version 1.3.1 or higher. これより古いバージョンの LFS クライアントは、このバージョンの TFS で行われた認証に関する変更と互換性がありません。Older versions of the LFS client are not compatible with authentication changes in this version of TFS. お客様が余裕をもって移行を行えるように、RTW 向けに短期的な回避策を実装しました。In order to give customers time to migrate, we implemented a short-term workaround for RTW. この回避策は、バージョン 1.3.1 より前の Git LFS クライアントが機能しなくなる Update 1 では削除されます。The workaround will be removed in Update 1, at which point Git LFS clients below 1.3.1 will no longer work.

NuGet の復元で に存在するパッケージが検出されないNuGet Restore is not finding packages that exist in

  • 問題:Issue:

    NuGet 3.4.3 以降を使用している場合、 が NuGet.Config の明示的なソースでない限り、NuGet 復元タスクは からパッケージを復元しません。When using NuGet 3.4.3 or greater, the NuGet Restore task will not restore packages from unless it is an explicit source in the NuGet.Config.

  • 回避策:Workaround: が NuGet.config に存在することを確認します。Ensure is in NuGet.Config.

NuGet のビルド タスクとリリース タスクが認証を行わないNuGet build and release tasks do not authenticate

  • 問題:Issue:

    Team Foundation Server/Package Management を使用している場合、エージェントがネットワーク サービス ユーザーとして実行されていると (ビルド エージェントがサービスとして実行されている場合に既定値となります)、NuGet のビルド タスクとリリース タスクはフィードに対して自らの認証を実行しません。When using Team Foundation Server / Package Management, NuGet build and release tasks will not authenticate to feeds if the agent is running as a NETWORK SERVICE user, which is the default when the build agent is run as a service. このようなことが発生する理由: バージョン 3.5 より前の NuGet では、ビルド タスクによって提供された資格情報ではなく、ビルド エージェントを実行しているユーザー アカウントの資格情報が使用されることにあります。This happens because versions of NuGet before 3.5 use the credentials of the user account running the build agent, not the credentials provided by the build task.

  • 回避策:Workaround:

    ネットワーク サービスとして実行されているエージェントを使用して TFS フィードで NuGet のビルド/リリース タスクを使用するには、NuGet 3.5 以降を使用する必要があります。To use NuGet build/release tasks with TFS feeds using an agent that is running as a NETWORK SERVICE, you must use NuGet 3.5 or higher.

NuGet ビルド/リリース タスクでは、エージェントの資格情報が使用されます。NuGet build and release tasks use agent’s credentials

  • 問題:Issue:

    バージョン 3.5 より前の NuGet では、ビルド タスクによって提供された資格情報ではなく、ビルド エージェントを実行しているユーザー アカウントの資格情報が使用されます。Versions of NuGet before 3.5 use the credentials of the user account running the build agent, not the credentials provided by the build task. このことが原因で、予期しないアクセスが発生したり、フィードへのアクセス権が不足したりすることがあります。This may result in unexpected access or lack of access to feeds.

  • 回避策:Workaround:

    TFS ビルド エージェントで NuGet 3.5 以降を使用します。Use NuGet 3.5 or higher on TFS build agents.

外部拡張機能が TFS のアップグレード時に自動的にアップグレードされないExternal extensions do not automatically upgrade when upgrading TFS

  • 問題:Issue:

    Visual Studio Marketplace から拡張機能をダウンロードし、TFS 2015 インストールにそれを発行してから TFS 2017 にアップグレードした場合、Marketplace に公開される新しいバージョンの拡張機能には自動的にアップグレードされません。If you downloaded an extension from the Visual Studio Marketplace, published it to your TFS 2015 installation, and then upgraded to TFS 2017, the extension will not be automatically updated when new versions of the extension are published to the Marketplace.

  • 回避策:Workaround:

    TFS 2017 にアップグレードした後、TFS 2015 にインストールした拡張機能をアンインストールします。After upgrading to TFS 2017, uninstall the extensions you had installed in TFS 2015. 次に、最新の拡張機能をもう一度インストールします。Then reinstall the latest extensions. TFS 2017 では、更新された外部拡張機能の有無を 1 日に 1 回自動的にチェックし、アップグレードする機能が追加されています。In TFS 2017 we added a feature to automatically check for updated external extensions once a day and upgrade them.

Jenkins キュー ジョブ タスクがリリース定義で実行できないThe Jenkins Queue Job task cannot be run in release definitions

  • 問題:Issue:

    リリース定義で Jenkins キュー ジョブ タスクを実行すると、サーバー エラー 500 が表示されます。When running the Jenkins Queue Job task in a release definition, customers get a 500 server error.

  • 回避策:Workaround:

    現時点では、Jenkins キュー ジョブ タスクは、TFS ビルド定義の一環としては実行できますが、リリース定義では実行できません。Currently, the Jenkins Queue Job task can be run as part of TFS build definitions, but not release definitions. この機能は、将来のリリースで追加される予定です。This ability will be added in a future release.

TFS 2017 DLL に対してカスタム TFS サーバー プラグインを再ビルドする必要があるCustom TFS server plugins need to be rebuilt against TFS 2017 DLLs

  • 問題:Issue:

    カスタム TFS サーバー プラグインが TFS 2017 へのアップグレード後に機能しません。Custom TFS server plugins do not work after upgrading to TFS 2017.

  • 回避策:Workaround:

    TFS 2017 アセンブリに対して、カスタム サーバー プラグインを再ビルドします。Rebuild your custom server plugins against the TFS 2017 assemblies.

TFS 2015 RTM 以降、カスタム TFS サーバー プラグインのサーバー オブジェクト モデルが変更されているThe Server Object Model for Custom TFS server plugins has changed since TFS 2015 RTM

  • 問題:Issue:

    カスタム TFS サーバー プラグインがコンパイルされません。Custom TFS server plugins do not compile.

  • 回避策:Workaround:

    このブログ記事の説明に従って、ソース コードを修正してください。Fix up source code as described in this blog post.

管理者のアクションを使用すると、例外がスローされます。When using administrator actions, an exception is thrown

  • 問題:Issue:

    [アラート管理] ページで、チーム管理者が [特定のユーザー向けの警告を検索] でチームのサブスクリプションを検索すると、例外を取得する可能性があります。In the Alerts Administration page, when Team Administrators use the Find Alerts for a specific user search to find subscriptions for a team, they might get an exception.

  • 回避策:Workaround:

    • オプション 1: [すべての警告] ノードをクリックして [すべてのチーム警告] フィルターを表示させます。Option 1: Click on the All Alerts node and set the All My Teams Alerts filter to show. これにより、ユーザーにアクセスできるすべてのグループのすべてのアラートが表示されます。This will show all alerts for all groups that the user has access to.

    • オプション 2: グループがチームの場合、チーム名を検索する代わりに、このチームの [警告管理] ページに移動してサブスクリプションを管理します。Option 2: In case the group is a team, instead of searching by team name, navigate to this team’s Alerts Administration page to manage subscriptions.

チーム ビルド/リリース管理で機能テストを実行するためのタスクの使用に関する問題Issue using tasks for running functional tests in Team Build / Release Management

  • 問題:Issue:

    タスク カタログから "Visual Studio Test Agent の配置" タスクと "機能テストの実行" タスクを使用するチーム ビルド/リリース管理での機能テストの実行は、現在、Agents for Visual Studio 2015 更新プログラム 3 を使用し、Visual Studio 2013 および Visual Studio 2015 を使用してビルドされたテストを実行する場合にのみ使用できます。Running functional tests in Team Build / Release Management using ‘Visual Studio Test Agent Deployment’ and ‘Run Functional Tests’ tasks from the task catalog currently uses Agents for Visual Studio 2015 Update 3 and can only be used to run tests built using Visual Studio 2013 and Visual Studio 2015. これらのタスクは、Visual Studio 2017 RC を使用してビルドされたテストの実行には使用できません。These tasks cannot be used for running tests built using Visual Studio 2017 RC. 詳細については、こちらのブログ投稿を参照してください。For more details, please refer to this blog post.

  • 回避策:Workaround:

    対応策はありません。There is no workaround. Test Agent 2017 の使用と、Visual Studio 2017 を使用してビルドされたテストの実行に関するサポートは、TFS 2017 Update 1 タイムフレームで追加されます。Support for using Test Agent 2017 and running tests built using Visual Studio 2017 will be added in the TFS 2017 Update 1 timeframe.

拡張機能が自動的に更新されないExtensions are not being auto-updated

  • 問題:Issue:

    以前のバージョンの TFS を TFS 2017 にアップグレードし、接続モードで TFS 2017 を実行すると、自動更新されるはずの拡張機能が自動更新されません。If you upgrade a prior version of TFS to reach TFS 2017 and are running TFS 2017 in connected mode then your extensions will not be auto-updated as they should be.

  • 回避策:Workaround:

    この問題の回避策はありません。There is no workaround at this time. この問題は修正されており、自動更新動作は TFS 2017 Update 2 から提供されるようになります。We have fixed the issue and the auto update behavior will reach you through TFS 2017 Update 2. 何らかの理由で Update 2 まで待てない場合は、サポート チャネルに連絡すれば、修正プログラムを早く入手できます。If for any reason you cannot wait for Update 2 then reach us through the Support channel and we shall share the fix earlier.

運用環境 (Go-Live) への展開を妨げる問題が発生した場合は、Microsoft 製品サポートに問い合わせてください。If you encounter issues that are preventing you from deploying in a production environment (Go-Live), please contact Microsoft product support. (英語のみ) 米国営業時間内のみ (月~金、太平洋標準時午前 6 時~午後 6 時)、1 営業日以内に回答します。(English only) U.S. business hours only (M-F 6a-6p PST), 1 business day response.

Top of Page