Team Foundation Server 2018 リリース ノート Team Foundation Server 2018 Release Notes


英語以外のバージョンからこのページにアクセスしていて、最新の内容を見たい場合は、このリリース ノートの英語版ページをご覧ください。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.

Download the latest version of Team Foundation Server

Team Foundation Server 2018 の詳細については、Team Foundation Server の要件と互換性に関するページを参照してください。To learn more about Team Foundation Server 2018, see the Team Foundation Server Requirements and Compatibility page.

TFS 2018 の新機能のビデオWhat's New in TFS 2018 video


皆様のご意見をお待ちしております。We’d love to hear from you! 開発者コミュニティで問題を報告して追跡し、スタック オーバーフローでアドバイスを得ることができます。You can report a problem and track it through Developer Community and get advice on Stack Overflow. Microsoft に優先的に取り組んで欲しいアイデアがある場合は、UserVoice でアイデアを追加するか、既存のアイデアに投票してください。As always, if you have ideas on things you’d like to see us prioritize, head over to UserVoice to add your idea or vote for an existing one.

リリース日: 2017 年 11 月 15 日Release Date: November 15, 2017

概要: Team Foundation Server 2018 の更新プログラムSummary: Team Foundation Server 2018 Updates

Team Foundation Server 2018 に新しい価値をたくさん追加しました。We've added a lot of new value to Team Foundation Server 2018. 主な特徴:Some of the highlights include:

XAML ビルドXAML Build

元々、XAML ビルドは TFS 2018 RTW および Update 1 から削除されたものとして表示されていました。We had originally listed XAML build as removed from TFS 2018 RTW and Update 1. ただし、それによって多くの顧客がアップグレードできなくなったり、アップグレードの完了後に再有効化のためサポートに連絡しなければならなくなりました。However, that resulted in too many customers being unable to upgrade or having to contact support to re-enable it after the upgrade completed. TFS 2018 Update 2 では、XAML ビルドが有効になっていますが、推奨されていません。In TFS 2018 Update 2, XAML build is enabled but has been deprecated. つまり、XAML ビルドへの追加の投資はなく、Microsoft Test Manager (MTM) は XAML ビルドの使用を今後サポートしません。This means there is no further investment in XAML Build, and Microsoft Test Manager (MTM) no longer supports using XAML builds. 新しいビルド定義形式のいずれかに変換することを強くお勧めします。We highly recommend converting to one of the newer build definition formats. 引き続き XAML コントローラーに接続して、TFS 2018 Update 2 で XAML ビルドを実行することもできます。You may continue to connect your XAML controllers and run XAML builds with TFS 2018 Update 2. 詳細More info

TFS 2018 RTW で削除された機能Features Removed in TFS 2018 RTW

詳細: このリリースの新機能Details: What's New in this Release

作業項目のトラッキング Work Item Tracking

Web でのプロジェクト作成ウィザード Project Creation Wizard on the web

Web アクセスからチーム プロジェクトを作成するためのエクスペリエンスを機能強化しました。We have improved the experience for creating a Team Project from web access. Visual Studio クライアントでチーム プロジェクトを作成するときに使用できる機能の多くが含まれるようになりました。It now includes most of the features available when you create a Team Project in the Visual Studio client. Web インターフェイスを使う利点は、一致するバージョンの Visual Studio が必要ないことです。The benefit of using the web interface is that you don't need a matching Visual Studio version. Visual Studio と Web バージョンの違いは、Web バージョンでは SSRS でレポートがプロビジョニングされないことです。The difference of using Visual Studio or the web version is that the web version doesn’t provision your reports in SSRS. チーム プロジェクト作成の Web バージョンを使用していた場合は、アプリケーション層で tfsconfig コマンドを実行して SSRS レポートをプロビジョニングまたは更新できます。If you used the web version of the Team Project creation, you can run the tfsconfig command on the Application Tier to provision or update the SSRS reports. 詳しくは、「AddProjectReports」をご覧ください。See details in add project reports.

Web でのプロセス テンプレート マネージャーProcess Template Manager on the web

TFS 2018 では、Web アクセスを使ってプロセス テンプレートをアップロードできます。With TFS 2018, you can use web access to upload your process templates. Web インターフェイスは、プロセス テンプレートとやり取りするために Visual Studio の正しいバージョンをインストールする必要がないため、はるかに簡単なエクスペリエンスです。The web interface is a much easier experience because you don't have to install the correct version of Visual Studio to interact with your process templates. Visual Studio 2017 Update 4 以前ではまだ [プロセス テンプレート マネージャー] ダイアログが表示されますが、Web インターフェイスを使うことをお勧めします。Visual Studio 2017 Update 4 and earlier will still show the Process Template Manager dialog, although we recommend using the web interface. Visual Studio 2017 Update 5 以降では、Web に自動的にリダイレクトされます。Visual Studio 2017 Update 5 and later will redirect you to the web automatically.

作業項目フォーム ヘッダーのカスタマイズ Customize the work item form header

既存のコントロールを置換するか、またはプロセスに関連のないコントロールを非表示にして、作業項目フォームのヘッダー領域をカスタマイズできるようになりました。You can now customize the work item form header area by replacing the existing controls, or hiding controls, that are not relevant to your process. これにより、領域パスをユーザー設定のチーム フィールドに置き換えたり、チームが "かんばん" に重点を置いている場合にイテレーションを非表示にしたり、理由をユーザー設定のフィールドに置き換えたりできます。This will enable replacing Area path with a custom Team field, hiding Iteration if your teams are more Kanban focused, and replacing Reason with a custom field. 状態フィールドは非表示にすることも置き換えることもできません。The State field cannot be hidden or replaced.

詳細については、WebLayout および Control 要素に関するドキュメントを参照してください。See the documentation for WebLayout and Control elements for more information.

モバイル作業項目フォーム Mobile work item form

完全なエンド ツー エンドのエクスペリエンスで、作業項目の外観が最適化されています (図 1)We have a full end-to-end experience that includes an optimized look and feel for work items (Figure 1). 自分に割り当てられた項目、フォローしている項目、過去に表示した項目、最近編集した項目を携帯電話から簡単に操作できます。It provides an easy way to interact with items that are assigned to you, that you’re following, or that you have visited, or edited recently, from your phone.

Mobile work item query
(図 1) モバイル作業項目のクエリ(Figure 1) Mobile work item query

わかりやすい表示だけでなく、このエクスペリエンスはすべてのフィールドの種類に対する最適化されたコントロールをサポートします (図 2)Along with the good looks, this experience supports optimized controls for all field types (Figure 2).

Mobile work item form
(図 2) モバイル作業項目のフォーム(Figure 2) Mobile work item form

新しいモバイル ナビゲーション (図 3) では、ユーザーは TFS の他のモバイル対応部分にアクセスでき、他のハブを使う必要があるときは完全なデスクトップ サイトに戻ることができます。With the new mobile navigation (Figure 3), users can reach any other mobile-ready parts of TFS and get back to the full desktop site in case they need to interact with other hubs.

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

バックログ、かんばんボード、スプリント、およびクエリのフィルター処理Filtering on backlogs, Kanban boards, sprints, and queries

すべての作業項目追跡グリッド エクスペリエンス (クエリ、バックログ、かんばんボード、スプリント バックログ、テスト ケース管理) で、共通の一貫したフィルター処理コンポーネントが使われるようになりました (図 4)All of our work item tracking grid experiences (queries, backlogs, Kanban boards, sprints backlogs, and test case management) now make use of our common, consistent filtering component (Figure 4). 表示されている列にキーワード フィルターを適用して、タグを選択するだけでなく、作業項目の種類、状態、担当者でフィルター処理を行って、探している作業項目をすばやく取得することもできます。Beyond applying a keyword filter across displayed columns and selecting tags, you can also filter on work item types, states, and assigned to, in order to quickly get to the work items you are looking for.

Filtering on query
(図 4) クエリのフィルター処理(Figure 4) Filtering on queries

かんばんカードの空のフィールドを表示するように展開するExpand to show empty fields on a Kanban card

カードにフィールドを追加した後、ボードの設定で__空のフィールドを非表示にする__ (図 5) ことで不必要なフィールドをボードから除去できます。Today, you have the option to add additional fields to a card and then hide empty fields (Figure 5) in board settings to remove unnecessary clutter from the board. この機能の欠点は、空のフィールドを非表示にした後、作業項目フォームを開くことでしかフィールドを更新できなかったことです。The drawback to this feature was that once an empty field was hidden, the only way to update the field was to open the work item form. かんばんカードの新しい展開オプションを使うと、ボードで空のフィールドを非表示にしても、1 回のクリックでカードの特定のフィールドにアクセスして更新できます。With the newly available expand option on Kanban cards, you can now benefit from hiding empty fields across the board, but still have single click access to update a particular field on a card. カードをポイントし、カードの下部にある下向きのシェブロンを使って、非表示フィールドを更新します。Simply hover over the card and look for the down chevron at the bottom of the card to update the hidden field.

Hidden field
(図 5) かんばんカードの隠しフィールド(Figure 5) Hidden field on Kanban card

カードの下部にある下向きのシェブロンをクリックして、フィールドを更新します (図 6)Click the down chevron at the bottom of the card to update the field (Figure 6).

Update hidden field
(図 6) かんばんカードの隠しフィールドの更新(Figure 6) Update hidden field on Kanban card

作業項目保存ブロック拡張機能Extensions block work item save

作業項目フォームのカスタム コントロール、グループ、およびページで、作業項目の保存をブロックし、作業項目フォームを保存する前に、データを検証し、必須情報が入力されていることを確認できるようになりました。Work item form custom controls, groups, and pages can now block work item save to validate data and ensure the user fills out any required information before saving the work item form.

配信計画へのインラインでの追加Inline add on Delivery Plans

新機能のアイデアはいつ思いつくかわかりません。そこで、新機能を配信計画に簡単に直接追加できるようにしました (図 7)New feature ideas can arrive at any moment, so we’ve made it easier to add new features directly to your Delivery Plans (Figure 7). ホバー時の [新規アイテム] ボタンをクリックし、名前を入力し、Enter キーを押すだけです。Simply click the New item button available on hover, enter a name, and hit enter. 新機能は、領域のパスとイテレーション パスを想定して作成します。A new feature will be created with the area path and iteration path you’d expect.

Inline add on delivery plans
(図 7) 配信計画へのインラインでの追加(Figure 7) Inline add on delivery plans

バージョン管理 Version Control

フォーク Forks

TFS 2018 では Git フォークのサポートが追加されます (図 8)TFS 2018 adds support for Git forks (Figure 8). フォークはリポジトリのサーバー側コピーです。A fork is a server-side copy of a repository. フォークを使うと、直接コミット アクセスを与えることなく、広範なユーザーにリポジトリへの寄与を許可できます。Using forks, you can allow a broad range of people to contribute to your repository without giving them direct commit access. 代わりに、ユーザーはリポジトリの自分のフォークに作業をコミットします。Instead, they commit their work to their own fork of the repository. これにより、中央リポジトリに変更を受け入れる前に、プル要求で変更を確認できます。This gives you the opportunity to review their changes in a pull request before accepting those changes into the central repository.

Git forks
(図 8) Git フォーク(Figure 8) Git forks


Git Virtual File System (GVFS) がサポートされるようになりました。Git Virtual File System (GVFS) is now supported. GVFS を使用すると、ファイル システム上での Git の動作を仮想化および最適化することにより、Git リポジトリを数百万のファイル規模に対応できるようにすることができます。GVFS allows Git repositories to scale to millions of files by virtualizing and optimizing how Git operates on the filesystem.

Web を使用してリポジトリにフォルダーを作成するCreate a folder in a repository using web

Web を介して Git および TFVC リポジトリにフォルダーを作成できるようになりました (図 9)You can now create folders via the web in your Git and TFVC repositories (Figure 9). フォルダー管理拡張機能に取って代わる機能です。フォルダー管理拡張機能は廃止処理が行われることになります。This replaces the Folder Management extension, which will now undergo the process of deprecation.

フォルダーを作成するには、コマンド バーまたはコンテキスト メニューで [新規]、[フォルダー] の順にクリックします。To create a folder, click New > Folder in either the command bar or context menu:

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

TFVC の場合は、フォルダー名を指定し、チェックインします。For TFVC, you’ll specify a folder name and then check it in. Git の場合、フォルダーを空にすることはできないので、ファイル名も入力する必要があります。必要に応じてファイルを編集し、コミットします。For Git, because empty folders aren’t permitted, you’ll also have to specify a file name, optionally edit the file, then commit it.

さらに、Git の場合、[新しいファイル] ダイアログ (図 10) が強化され、サブフォルダーを作成するためのスラッシュを使用できるようになりました。Additionally, for Git, The New file dialog (Figure 10) has been enhanced to accept slashes to create subfolders.

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

ファイルのミニマップFile minimap

表示または編集しながらファイルのミニマップを表示して、コードの概要を簡単に確認できるようになりました (図 11)You can now view a minimap of a file as you view or edit to give you a quick overview of the code (Figure 11). ミニマップをオンにするには、(F1 キーまたは右クリックで) コマンド パレットを開き、[Toggle Minimap](ミニマップの切り替え) を選択します。To turn on the minimap, open the Command Palette (F1 or right-click) and select Toggle Minimap.

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

中かっこの位置揃えBracket matching

ファイルを編集したり、表示したりするときに、左側にガイドラインが表示され、中かっこの位置を簡単に揃えられるようになりました (図 12)When editing or viewing a file, there are now guidelines on the left side to make it easy to match your brackets (Figure 12).

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

空白の表示/非表示の切り替えToggle white space

ファイルを表示または編集するときに空白の表示/非表示を切り替えることができるようになりました。You can now toggle white space on and off when viewing or editing a file. 差分をとるときに空白を切り替える機能はまだ開発中です。We are still developing a feature that will allow you to toggle white space when diff’ing. 空白を表示するには (図 13)、(F1 キーまたは右クリックで) コマンド パレットを開いて [Toggle White Space](空白の切り替え) を選択します。これにより、スペースとタブを区別することができます。To view white space (Figure 13), open the Command Palette (F1 or right-click) and select Toggle White Space, which allows you to differentiate between spaces and tabs.

Toggle white space
(図 13) 空白の表示/非表示の切り替え(Figure 13) Toggle white space

TFVC リポジトリの Web 編集をオフに設定Setting to turn off web editing for TFVC repos

TFVC を使うチームは、Visual Studio のチェックイン ポリシーを使ってコードの品質を確認することがよくあります。Teams that use TFVC often use check-in policies in Visual Studio to ensure code quality. ただし、チェックイン ポリシーはクライアントで適用されるため、Web で編集されたコードは同じポリシーの対象になりません。However, because check-in policies are enforced on the client, code that is edited on the web isn’t subjected to the same policies.

複数のユーザーから、Web 編集を無効にしてチェックイン ポリシーをバイパスする変更を防ぐ方法を求められました。Several people have asked for a way to disable web-editing to protect against changes that bypass check-in policies. プロジェクト/リポジトリ ベースで TFVC の Web 編集 (追加、削除、名前変更、編集) をオフにする方法を設けました。We’ve enabled a way for you to turn off web-editing (adding, deleting, renaming, and editing) for TFVC on a project/repository basis.

Web 編集を禁止するには、[ファイル] ページから [設定][バージョン管理] に移動します (図 14)To disallow web-editing from the Files page, go to Settings then Version Control (Figure 14). ツリーで TFVC リポジトリをクリックし、[オプション] ピボットに移動して、[Enable web-editing for this TFVC repository](この TFVC リポジトリの Web 編集を有効にする) をオフにします。Click on the TFVC repo in the tree, navigate to the Options pivot, and uncheck Enable web-editing for this TFVC repository. 既定では、Web 編集は有効になっています。By default, web-editing is enabled.


__プロジェクト概要ページ__からの README の編集には影響ありません。Editing the README from the Project Overview page is unaffected.

Turn off web editing
(図 14) Web 編集をオフに設定(Figure 14) Turn off web editing

Web 編集が無効になっているプロジェクトで Web 編集を試みると、Web 編集が許可されないことが通知されます (図 15)If you attempt a web-edit in a project with web-editing disabled, you will be notified that web-editing is not allowed (Figure 15).

Web editing not allowed dialog
(図 15) Web 編集が許可されないダイアログ(Figure 15) Web editing not allowed dialog


この機能は、関連する提案に基づいて開発されました。This has been developed based on a related suggestion.

古いブランチを識別するIdentify stale branches

不要になったブランチを削除することによってリポジトリをクリーンに維持すると、チームは重要なブランチを探して、適切な細分性でお気に入りを設定できます。Keeping your repository clean by deleting branches you no longer need enables teams to find branches they care about and set favorites at the right granularity. ただし、リポジトリに多数のブランチがある場合、非アクティブであり削除できるブランチを見極めるのが難しいことがあります。However, if you have lots of branches in your repo, it can be hard to figure out which are inactive and can be deleted. "古い" ブランチ (3 か月より古いコミットをポイントしているブランチ) を識別しやすくしました。We’ve now made it easier to identify “stale” branches (branches that point to commits older than 3 months). 古いブランチを表示するには、[ブランチ] ページの [古い] ピボットに移動します (図 16)To see your stale branches, go to the Stale pivot on the Branches page (Figure 16).

Stale branches
(図 16) 古いブランチ(Figure 16) Stale branches

削除されたブランチを検索して再作成するSearch for a deleted branch and re-create it

サーバーからブランチを誤って削除したとき、何が起きたのか明らかにするのが難しい場合があります。When a branch is accidentally deleted from the server, it can be difficult to figure out what happened to it. 削除されたブランチを検索し、いつ、だれが削除したのかを確認して、必要であれば再作成できるようになりました。Now you can search for a deleted branch, see who deleted it and when, and re-create it if you wish.

削除されたブランチを検索するには、ブランチ検索ボックスにブランチの完全な名前を入力します。To search for a deleted branch, enter the full branch name into the branch search box. そのテキストに一致する既存のブランチが返されます。It will return any existing branches that match that text. 削除されたブランチの一覧で完全に一致するものを検索するオプションもあります。You will also see an option to search for an exact match in the list of deleted branches. リンクをクリックして削除されたブランチを検索します (図 17)Click the link to search deleted branches (Figure 17).

Search for deleted branches
(図 17) 削除されたブランチの検索(Figure 17) Search for deleted branches

一致が見つかった場合、だれが、いつ削除したかが表示されます。If a match is found, you will see who deleted it and when. ブランチを復元することもできます (図 18)You can also restore the branch (Figure 18).

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

ブランチを復元すると、最後にポイントされていたコミットで再作成されます。Restoring the branch will re-create it at the commit to which is last pointed. ただし、ポリシーとアクセス許可は復元されません。However, it will not restore policies and permissions.

プレフィックスで始まるブランチでコミットを検索するSearch for a commit in branches starting with a prefix

すべてのブランチにプレフィックスが設定された階層形式のブランチ構造がある場合、この機能は、そのプレフィックス テキストで始まるすべてのブランチでコミットを検索するのに役立ちます。If you have branch structure in a hierarchical format where all branches are prefixed with a text, then this feature will help you to find a commit in all the branches starting with that prefix text. たとえば、"dev" というプレフィックスが付いたすべてのブランチでコミットが行われたかどうかを確認する場合は、検索ボックスに「dev」と入力し、["dev" で始まるブランチを検索します] を選びます (図 19)For example, if you want to see whether a commit made its way to all branches that are prefixed with "dev" then simply type "dev" in the search box and select Search in branches starting with "dev" (Figure 19).

Search for a commit
(図 19) コミットの検索(Figure 19) Search for a commit

コミット詳細ページのリッチになったプル要求の吹き出しRicher pull request callout on commit details page

コミット詳細ページのプル要求の吹き出しに、診断の向上に役立つ関連情報がより多く表示されるようになりました (図 20)The pull request callout on the commit details page shows more relevant information to help you diagnose better (Figure 20). また、いずれかのブランチでコミットを行った最初のプル要求と、既定のブランチに関連付けられているプル要求が、吹き出しに表示されるようになりました。Now we also show the first pull request that introduced the commit to any branch and the pull request associated with the default branch in the callout.

Pull request callout
(図 20) プル要求の吹き出し(Figure 20) Pull request callout

コードのツリー ビューをフィルター処理するFilter tree view in Code

目的のファイルを探すのに、コミットが変更した可能性のあるすべてのファイルをスクロールする必要がなくなりました。Now you don’t need to scroll through all the files that a commit may have modified to just get to your files. コミット詳細、プル要求、シェルブセットの詳細、変更セットの詳細の各ページのツリー ビューで、ファイルとフォルダーのフィルター処理がサポートされるようになりました。The tree view on commit details, pull requests, shelveset details, and changeset details page now supports file and folder filtering. これはスマート フィルターであり、フォルダー名でフィルター処理するとフォルダーの子ファイルが表示され、ファイル名でフィルター処理するとファイルの折りたたまれたツリー ビューでファイル階層が表示されます。This is a smart filter that shows child files of a folder when you filter by folder name and shows a collapsed tree view of a file to display the file hierarchy when you filter by file name.

コミット ツリー (図 21) および (図 22) のファイルまたはフォルダー検索フィルター:Find a file or folder filter on commit tree (Figure 21) and (Figure 22):

Find a file or folder
(図 21) ファイルまたはフォルダーの検索(Figure 21) Find a file or folder
Filtered view
(図 22) コミット ツリーのフィルター処理されたビュー(Figure 22) Filtered view on commit tree

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

[ブランチの更新] ページには大きな価値があります。The Branch Updates page has tremendous value. ただし、このページは [履歴] ハブでピボットとして非表示になっていました。However, it was hidden as a pivot under the History hub. ブランチの更新に関するページは、[コード] に、[コミット][ブランチ][タグ][プル要求] と共に、[プッシュ] という名前でハブとして表示されるようになります (図 23)Now the branch updates page will be visible as a hub called Pushes (Figure 23) under Code, alongside Commits, Branches, Tags, and Pull Requests. プッシュ ページの新しい URL は \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes です。The new URL for the pushes page is: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes. 古い URL も引き続き機能します。The old URLs will continue to function.

Pushes page
(図 23) プッシュ ページ(Figure 23) Pushes page

同時に、ハブにはコミットだけが表示されるようになったため、[履歴] ハブは [コミット] (図 24) に名前を変更されました。At the same time, the History hub is now renamed to Commits (Figure 24) since the hub only shows commits. コミット リスト ビューではポイントしたときにのみ詳細な時刻が表示されるためコミット関連のトラブルシューティングが難しいというフィードバックをいただきました。We received feedback that people were finding it difficult to troubleshoot commit related issues because the commit list view only showed detailed time on-hover. 現在は、インスタンスのコミット リスト ビューに dd/mm/yy hh:mm の形式で日時が表示されるようになっています。Now the commit list view across your instance will show date and time in dd/mm/yy hh:mm format. コミット ページの新しい URL は \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits です。The new URL for commits page is: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits. 古い URL も引き続き機能します。The old URLs will continue to function.

Commits page
(図 24) コミット ページ(Figure 24) Commits page

ファイルからコミットに移動したときにファイル名が維持されるRetain filename when moving from Files to Commits

[コード] ハブの [ファイル] ピボットでディレクトリをフィルター処理して特定のファイルを表示した後、[履歴] ピボットに切り替えた場合、コミットで 1,000 より多くのファイルが変更されているとファイル名が維持されないというフィードバックがありました。We heard feedback from people that when they filter the directory to a particular file in the Files pivot of the Code hub and later flip to the History pivot, the filename isn’t persisted if the commit changed more than 1,000 files. そのため、より多くのファイルを読み込み、内容をフィルター処理してファイルを検索する必要があり、生産性に影響がありました。This resulted in people needing to load more files and filter content to find the file, which was impacting productivity. 通常、開発者は同じディレクトリで作業しており、変更をトレースしても作業ディレクトリが維持されることを望みます。Developers normally work in the same directory and want to persist to the directories they work in as they trace changes. このバージョンでは、コミットで変更されたファイルの数に関係なく、[コード] ハブのピボット間を移動してもファイル名が維持されるようになりました。Now, we persist the filename as you move between Code hub pivots regardless of the number of files changed in a commit. つまり、目的のファイルを検索するのに、[さらに読み込む] をクリックする必要はありません。This means that you do not have to click on Load More to find the file you want.

Git タグを表示する View Git tags

リポジトリのすべてのタグを [タグ] ページで見ることができます (図 25)You can view all the tags in your repository on the Tags page (Figure 25). すべてのタグをリリースとして管理している場合、ユーザーはタグ ページにアクセスしてすべての製品リリースをまとめて見ることができます。If you manage all your tags as releases, then a user can visit the tags page to get a bird’s-eye view of all the product releases.

View Git tags
(図 25) Git タグの表示(Figure 25) View Git tags

軽量タグと注釈付きタグを簡単に区別できます。You can easily differentiate between a lightweight and an annotated tag. 注釈付きタグには関連するコミットと共にタガーと作成日が表示されるのに対し、軽量タグにはコミット情報のみが表示されます。Annotated tags show the tagger and the creation date alongside the associated commit, while lightweight tags only show the commit information.

Git タグを削除するDelete Git tags

リモート リポジトリからタグを削除したい場合があります。There can be times when you want to delete a tag from your remote repo. タグ名を間違えたり、正しくないコミットにタグを付けたりした場合が想定されます。It could be due to a typo in the tag name, or you might have tagged the wrong commit. [タグ] ページでタグのコンテキスト メニューをクリックして [タグの削除] を選ぶことで、Web UI からタグを簡単に削除できます (図 26)You can easily delete tags from the web UI by clicking the context menu of a tag on the Tags page and selecting Delete tag (Figure 26).


リモート リポジトリ上のタグの削除は慎重に行う必要があります。Deleting tags on remote repos should be exercised with caution.

Delete git tags
(図 26) Git タグの削除(Figure 26) Delete Git tags

Git タグのフィルター処理Filtering Git tags

古いリポジトリでは、時間とともにタグの数が大幅に増えることがあります。また、タグが階層構造で作成されたリポジトリでは、タグの検索が困難な場合があります。For old repositories, the number of tags can grow significantly with time; there can also be repositories that have tags created in hierarchies, which can make finding tags difficult.

[タグ] ページで探しているタグが見つからない場合、[タグ] ページ上部のフィルターを使ってタグ名を簡単に検索できます (図 27)If you are unable to find the tag that you were looking for on the Tags page, then you can simply search for the tag name using the filter on top of the Tags page (Figure 27).

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

Git タグのセキュリティGit tags security

このバージョンでは、リポジトリのユーザーにきめ細かいアクセス許可を付与してタグを管理できます。Now you can grant granular permissions to users of the repo to manage tags. このインターフェイスからは、タグの削除やタグの管理のアクセス許可をユーザーに付与できます (図 28)You can give users the permission to delete tags or manage tags from this interface (Figure 28).

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

Git タグについて詳しくは、Microsoft DevOps のブログをご覧ください。Read more about Git tags at the Microsoft DevOps blog.

プル要求完了時に作業項目を自動的に完了させる Automatically complete work items when completing pull requests

PR に作業項目をリンクしている場合、すべてのものを最新に保つことだけが簡素化されました。If you’re linking work items to your PRs, keeping everything up to date just got simpler. このバージョンでは、PR を完了するとき、PR が正常にマージされた後で、リンクされた作業項目を自動的に完了させることができます (図 29)Now, when you complete a PR, you’ll have the option to automatically complete the linked work items after the PR has been merged successfully (Figure 29). ポリシーを使っている場合、PR をオート コンプリートに設定すると、同じオプションが表示されます。If you’re using policies and set PRs to auto-complete, you’ll see the same option. PR が完了した後で忘れずに作業項目に再度アクセスして状態を更新する必要はなくなりました。No more remembering to revisit work items to update the state once the PR has completed. この処理は自動的に行われます。This will be done for you automatically.

Complete linked work items
(図 29) リンクされた作業項目の完了(Figure 29) Complete linked work items

プッシュ/新規イテレーションで投票をリセットするReset votes on push/new iteration

PR でより厳密な承認ワークフローを選んでいるチームは、新しい変更がプッシュされるときに、オプトインして投票をリセットできるようになりました (図 30)Teams opting for a more strict approval workflow in PRs can now opt-in to reset votes when new changes are pushed (Figure 30). 新しい設定は、[レビュー担当者の最小数が必要です] ポリシーのオプションです。The new setting is an option under the policy to Require a minimum number of reviewers.

Reset votes setting
(図 30) 投票設定のリセット(Figure 30) Reset votes setting

このオプションをオンにすると、PR のソース ブランチが更新されると常に、すべてのレビュー担当者のすべての投票がリセットされます。When set, this option will cause all votes from all reviewers to be reset any time the source branch of the PR is updated. PR タイムラインは、このオプションの結果として投票がリセットされると常にエントリを記録します (図 31)The PR timeline will record an entry any time the votes are reset as a result of this option (Figure 31).

Reset votes in timeline
(図 31) タイムラインでの投票のリセット(Figure 31) Reset votes in timeline

ファイル名でプル要求ツリーをフィルター処理するFilter pull request tree by file name

プル要求での特定のファイルの検索がこれまでより簡単になりました。Finding a specific file in a pull request is easier than ever. [ファイル] ビューの新しいフィルター ボックスでは、ツリー ビューのファイル一覧をフィルター処理できます (図 32)The new filter box in the Files view lets users filter down the list of files in the tree view (Figure 32).

Find file or folder in pull request
(図 32) プル要求でのファイルまたはフォルダーの検索(Figure 32) Find file or folder in pull request

フィルターはプル要求内のファイルのパスの任意の部分と一致するので、フォルダー名、部分的なパス、ファイル名、または拡張子で検索できます (図 33)The filter matches any part of the path of the files in the pull request, so you can search by folder names, partial paths, file names, or extensions (Figure 33).

Find results
(図 33) 検索結果(Figure 33) Find results

プル要求のコメントのフィルター オプションの追加More pull request comments filtering options

プル要求の概要とファイル ビューの両方で、コメントのオプションが同じになりました (図 34)Comments in both the pull request overview and the files view now have the same options (Figure 34). 自分が参加したディスカッションだけをフィルターで抽出することもできます。You can also filter to see only the discussions you participated in.

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

プル要求の詳細でコードのコメントの元の差分を表示するView original diff for code comments in pull request details

コメントで参照されているコードを変更した後 (多くの場合、要求された変更を行ったとき)、PR コメントを理解するのが難しい場合があります (図 35)Sometimes, it’s hard to make sense out of a PR comment after the code it’s referencing has changed (many times, when a requested change has been made) (Figure 35).

View original diff
(図 35) 元の差分の表示(Figure 35) View original diff

このような場合、更新番号の付いたバッジが表示されるようになり、それをクリックすると、コメントが最初に作成されたときのコードを見ることができます (図 36)When this happens, you’ll now see a badge with an update number that you can click to see what the code looked like at the time the comment was originally created (Figure 36).

Update badge
(図 36) 更新バッジ(Figure 36) Update badge

折りたたみ可能なプル要求のコメントCollapsible pull request comments

コードのレビューはプル要求のエクスペリエンスの重要な部分であるため、レビュー担当者がコードに簡単に集中できる新機能が追加されました。Reviewing code is a critical part of the pull request experience, so we’ve added new features to make it easier for reviewers to focus on the code. コード レビュー担当者は、新しいコードを初めてレビューするときに、簡単にコメントを非表示にして邪魔にならないようにできます (図 37)Code reviewers can easily hide comments to get them out of the way when reviewing new code for the first time (Figure 37).

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

コメントを非表示にすると (図 38)、ツリー ビューに表示されなくなり、ファイル ビューのコメント スレッドが折りたたまれます。Hiding comments (Figure 38) hides them from the tree view and collapses the comment threads in the file view:

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

折りたたまれたコメントは、余白のアイコンをクリックして簡単に展開でき、もう一度クリックすると再び折りたたむことができます。When comments are collapsed, they can be expanded easily by clicking the icon in the margin, and then collapsed again with another click. ツールヒントを使うと (図 39)、スレッド全体を表示することなく、コメントを簡単に見ることができます。Tooltips (Figure 39) make it easy to peek at a comment without seeing the entire thread.

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

プル要求の説明とコメントのタスク一覧Task lists in pull request descriptions and comments

PR を準備するとき、またはコメントを追加するときに、追跡したいことの短いリストがある場合がありますが、結局、テキストを編集したり、複数のコメントを追加したりすることが必要になります。When preparing a PR or commenting you sometimes have a short list of things that you want to track but then end up editing the text or adding multiple comments. 軽量タスク一覧は、PR 作成者やレビュー担当者が、説明または単一の統合されたコメントで、ToDo リストの進行状況を追跡できる優れた方法です。Lightweight task lists are a great way to track progress on a list of to-dos as either a PR creator or reviewer in the description or a single, consolidated comment. [マークダウン] ツールバーをクリックして始めるか、または選択したテキストに書式を適用します (図 40)Click on the Markdown toolbar to get started or apply the format to selected text (Figure 40).

Task list toolbar
(図 40) タスク一覧ツールバー(Figure 40) Task list toolbar

タスク一覧を追加した後は (図 41)、ボックスをオンにするだけで、項目を完了としてマークできます。Once you’ve added a task list (Figure 41), you can simply check the boxes to mark items as completed. これらは、マークダウン内で [ ] および [x] と表されて、コメントに格納されます。These are expressed and stored within the comment as [ ] and [x] in Markdown. 詳しくは、マークダウンのガイダンスをご覧ください。See Markdown guidance for more information.

Task list
(図 41) タスク一覧(Figure 41) Task list

プル要求に "いいね" コメントを付ける機能Ability to “Like” comments in pull requests

PR コメントの支持を、__いいね__ボタンのシングル クリックで示します (図 42)Show your support for a PR comment with a single click on the like button (Figure 42). ボタンをポイントすると、コメントに "いいね" をしたすべてのユーザーのリストを見ることができます。You can see the list of all people that liked the comment by hovering over the button.

Like pull request comments
(図 42) プル要求に "いいね" コメントを付ける(Figure 42) Like pull request comments

提案を承認するときのワークフローの機能強化Improved workflow when approving with suggestions

プル要求で__オート コンプリート__ オプション (図 43) を使うのは生産性向上のためによい方法ですが、レビュー担当者とのアクティブなディスカッションを途中で中止するのはよくありません。Using the auto-complete option (Figure 43) with pull requests is a great way to improve your productivity, but it shouldn’t cut short any active discussions with code reviewers. このようなディスカッションをさらに促進するため、__承認と提案__の投票では、プル要求にオート コンプリートが設定されているというメッセージが表示されるようになりました。To better facilitate those discussions, the Approve with suggestions vote will now prompt when a pull request is set to complete automatically. ユーザーは、フィードバックを読むことができるようにオート コンプリートをキャンセルすることも、オート コンプリートを設定したままにして、すべてのポリシーが満たされた時点でプル要求が自動的に完了されるようにすることもできます。The user will have the option to cancel the auto-complete so that their feedback can be read, or keep the auto-complete set and allow the pull request to be completed automatically when all policies are fulfilled.

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

Git 通知のパス フィルター処理のサポートPath filtering support for Git notifications

リポジトリ内のすべてのフォルダーについての通知を受け取る代わりに、チーム メンバーがプル要求を作成したとき、または関心のあるフォルダーでコードをプッシュしたときにのみ、通知を受け取ることができます。Instead of getting notifications for all folders in a repo, you can now choose to get notified when team members create pull requests or push code in only the folders that you care about. Git プッシュ要求または Git プル要求のカスタム メール通知サブスクリプションを作成すると、フォルダー パスでこれらの通知をフィルター処理するための新しいオプションが表示されます (図 44)When creating custom Git push or Git pull requests email notification subscriptions, you will see a new option to filter these notifications by folder path (Figure 44).

Path filtering for notifications
(図 44) 通知のパス フィルター処理(Figure 44) Path filtering for notifications

プル要求ワークフローの更新されたメール テンプレートUpdated email templates for pull request workflows

プル要求のメール通知が、明確で簡潔で実用的なように更新されました (図 45)Pull request email alerts have been refreshed to make them clear, concise, and actionable (Figure 45). 件名行は PR タイトルとリポジトリ名などのセカンダリ情報で始まり、ID は末尾に移動されています。The subject line will begin with the PR title and secondary information, like the repo name, and ID will be deferred to the end. 作成者名が件名に追加され、PR を作成したユーザーでルールやフィルターを簡単に適用できるようになっています。The name of the author has been added to the subject to make it simpler to apply rules and filters based on the person that created the PR.

通知メール本文のテンプレートは更新されており、最初に通知の送信理由がまとめて示され、その後に重要なメタデータ (タイトル、ブランチ名、説明) とメインのアクション呼び出しボタンが表示されるようになっています。The body of the alert emails has a refreshed template that first summarizes why the alert was sent, followed by the critical metadata (title, branch names, and description), and a main call-to-action button. レビュー担当者、ファイル、コミットなどの他の詳細情報は、メールのさらに下の方に記載されます。Additional details like the reviewers, files, and commits are included further down the email.

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

ほとんどの通知では、アクション呼び出し (図 46) をクリックすると Web のプル要求が表示されます。For most alerts, the call-to-action (Figure 46) will be to view the pull request in the web. ただし、特定のコメントに関する通知を受け取るときは、アクション呼び出しは__そのコメントに直接リンク__しており、コードとコンテキストの前の会話を簡単に見つけることができます。However, when you’re notified about a specific comment, the call-to-action will link directly to that comment so you can easily find the code and prior conversation for context.

Email call-to-action
(図 46) メールのアクション呼び出し(Figure 46) Email call-to-action

プッシュ通知用の電子メール テンプレートの更新Updated email templates for push notifications

プッシュ通知は、明確かつ簡潔で、実行可能に最適化された新しい電子メールテンプレートに合わせて更新されました (図 47)Push notifications have been updated to match the new email templates that are optimized to be clear, concise, and actionable (Figure 47). 件名は、プッシュ電子メールを明確に区別し、ブランチ、リポジトリ、および作成者を特定し、プッシュに含まれるコミットの数を要約するのに役立ちます。The subject line helps you clearly distinguish push emails, identify the branch, repo, and author, and summarize the number of commits included in the push. このような変更により、これらの電子メール通知を管理するのに役立つルールとフィルターを簡単に作成することもできます。These changes also make it easier to create rules and filters to help manage these email notifications.

電子メールの本文は、他の電子メールと一貫した内容になっており、電子メールが送信された理由、操作を開始した人、通知が発生した原因を強調しています。The email body is consistent with other emails, emphasizing why the email was sent, who initiated the action, and exactly what happened. プッシュ通知に特化して、リポジトリ、ブランチ、ファイル、およびコミットの詳細がすべて含まれており、受信者に変更の範囲について通知するのに役立ちます。Specific to push alerts, the details about the repo, branch, files, and commits are all included to help inform the recipients about the scope of the changes. プッシュ通知に対するアクションの main 呼び出しは View Push です。これにより、通知を生成した特定のプッシュのプッシュ ビューが表示されます。The main call-to-action for push alerts is View Push, which will open the pushes view for the specific push that generated the alert.

Push template
(図 47) プッシュ テンプレート(Figure 47) Push template

Wiki Wiki

各プロジェクトは独自の Wiki をサポートするようになりました (図 48)Each project now supports its own Wiki (Figure 48). チーム メンバーによるプロジェクトの理解、使用、寄与を支援するページを簡単に作成できます。Now you can conveniently write pages that help your team members understand, use, and contribute to your project.

Wiki page
(図 48) PR Wiki ページ(Figure 48) PR Wiki page

新しい Wiki に含まれる主要な機能は次のとおりです。Some of the key features of the new Wiki include:

  • マークダウン構文を使用する簡素化された編集エクスペリエンス。Simplified editing experience using markdown syntax.
  • 新しいページでは、タイトルを指定し、コンテンツを追加できます。The new page allows you to specify a title and add content. (図 49)(Figure 49)
Title Wiki
(図 49) PR タイトル Wiki(Figure 49) PR Title Wiki
  • マークダウンでの HTML タグのサポート (図 50)Support for HTML tags in markdown (Figure 50).
Wiki HTML tags
(図 50) PR Wiki HTML タグ(Figure 50) PR Wiki HTML tags
  • マークダウン フォルダーでのイメージのサイズの簡単な変更 (図 51)Conveniently resize images in the markdown folder (Figure 51).
Image resize
(図 51) PR イメージのサイズ変更(Figure 51) PR Image resize
  • 並べ替え、親の再設定、ページ管理が可能な強力なページ管理ウィンドウ。Powerful page management pane that allows you to reorder, re-parent, and manage pages.
  • 大規模な Wiki についてタイトルでページをフィルター処理する機能 (図 52)Ability to filter pages by title for large Wikis (Figure 52).
Wiki menu
(図 52) PR Wiki メニュー(Figure 52) PR Wiki menu

詳しくは、Wiki の概要に関するページをご覧ください。Learn more about getting started with Wiki.

  • Wiki を使用していて、意図しない変更を保存してしまうことがあります。As you use Wiki more, there is a chance you’ll save unintended changes. リビジョンの詳細に移動して [元に戻す] ボタンをクリックすることで、Wiki ページのリビジョンを戻すことができるようになりました (図 53)Now you can revert a revision to a Wiki page by going to the revision details and clicking on the Revert button (Figure 53).
Wiki revert button
(図 53) PR Wiki の [元に戻す] ボタン(Figure 53) PR Wiki revert button

Wiki の作成中に、Wiki ページの目次に存在しないリンクを含めたパターンが見つかっています (図 54)We observed a pattern during Wiki creation where a table of contents on a Wiki page included non-existent links (Figure 54). ユーザーは、実際のページを作成しようとして、このようなリンクをクリックします。Users would click on these links in an attempt to create an actual page. 従来、このようなシナリオでは、リンクが壊れていること、またはページが存在しないことを示す警告を表示していました。We previously handled this scenario by giving a warning suggesting that the link was broken, or that the page did not exist. 現在は、これを Wiki の主流のシナリオとして処理し、ページの作成を許可するようになりました。Now, we are handling this as a mainstream scenario for Wiki, by allowing you to create pages instead.

Create wiki page
(図 54) PR 作成 Wiki ページ(Figure 54) PR Create Wiki page

Wiki ページでのディープ リンクの設定Wiki page deep linking

Wiki では、ページ内またはページ間にディープ リンクの設定セクションをサポートするようになりました。これは目次を作成する場合に非常に便利です。Wiki now supports deep linking sections within a page and across pages, which is really useful for creating a table of contents. 次の構文を使用して、同じページまたは別のページにある見出しを参照できます。You can reference a heading in the same page or another page by using the following syntax:

  • 同じページ: [text to display](#section-name)Same page: [text to display](#section-name)
  • 別のページ: [text to display](/page-name#section-name)Another page: [text to display](/page-name#section-name)

Marketplace での Wiki 拡張機能は非推奨となりました。The Wiki extension on the Marketplace is now deprecated. Wiki 拡張機能を既に使っている場合は、こちらの移行ツールを使って、Wiki ページを新しい Wiki に移行できます。If you are an existing Wiki extension user, then you can migrate your Wiki pages to the new Wiki using this migration tool. 詳しくは、既存の Wiki ページの新しい Wiki への移行に関するページをご覧ください。Learn more about how to migrate your existing Wiki pages to the new Wiki.

パッケージの管理 Package Management

パッケージ管理のエクスペリエンスの更新Package Management experience updates

パッケージの URL が、GUID ではなく、パッケージ名とバージョンで動作するようになりました。Package URLs now work with the package name and version, rather than using GUIDs. これにより、パッケージの URL を簡単に手作りできます (図 55)This makes it easier to hand-craft package URLs (Figure 55). 形式は \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package です。The format is: \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package.

Package URL
(図 55) PR パッケージ URL(Figure 55) PR Package URL

UserVoice でのこちらの提案に対応し、パッケージが削除されたバージョンを、すべてのフィード ユーザーに対して非表示にできるようになりました (図 56) (取り消し線付きのパッケージも表示されません)。You can now hide deleted package versions (Figure 56) from all feed users (no more strikethrough packages!), in response to this UserVoice suggestion.

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

パッケージ詳細ページで実行できるすべてのアクションを、パッケージ一覧のコンテキスト メニューから実行できるようになりました。Any action that you could perform on the package details page can now be performed from the context menu in the list of packages.

パッケージ一覧の新しい [Last pushed](最終プッシュ日時)(図 57) には日付が表示され、最近更新されたパッケージが簡単にわかります。The package list contains a new Last pushed column (Figure 57) with humanized dates so you can easily find recently-updated packages.

Last pushed column
(図 57) 最終プッシュ列(Figure 57) Last pushed column

Maven パッケージ Maven packages

TFS 2018 から、Maven 成果物のホスティングがサポートされるようになりました (図 58)We’ve launched support for hosting Maven artifacts in TFS 2018 (Figure 58). Maven 成果物を使うと、Java 開発者はコードとコンポーネントを簡単に共有できます。Maven artifacts enable Java developers to easily share code and components. パッケージ管理を使った Maven 成果物の共有方法については、getting started guide (開始ガイド) のページをご覧ください。Check out our getting started guide for how to share Maven artifacts using Package Management.

Maven packages
(図 58) Maven パッケージ(Figure 58) Maven packages

新しい統合 NuGet タスクNew unified NuGet task

NuGet の復元NuGet パッケージャー、__NuGet パブリッシャー__の各タスクが、NuGet ビルド タスクにまとめられ、他のビルド タスク ライブラリと整合するようになりました。既定では、新しいタスクは NuGet 4.0.0 を使います。We’ve combined the NuGet Restore, NuGet Packager, and NuGet Publisher task into a unified NuGet build task to align better with the rest of the build task library; the new task uses NuGet 4.0.0 by default. それに従い、古いタスクは非推奨とされたため、時間があるときに新しい NuGet タスクに移行することをお勧めします。Accordingly, we’ve deprecated the old tasks, and we recommend moving to the new NuGet task as you have time. この変更は、結合されたタスクを使うことによってのみアクセスできる、以下で説明する機能強化の流れと一致するものです。This change coincides with a wave of improvements outlined below that you’ll only be able to access by using the combined task.

この作業の一環として、PATH で使用可能な NuGet のバージョンを管理し、新しい NuGet タスクによって使われる、新しい NuGet Tool インストーラー タスクもリリースされました。As part of this work, we’ve also released a new NuGet Tool Installer task that controls the version of NuGet available on the PATH and used by the new NuGet task. したがって、新しいバージョンの NuGet を使うには、ビルドの先頭に NuGet Tool インストーラー タスクを追加するだけで済みます (図 59)So, to use a newer version of NuGet, just add a NuGet Tool Installer task at the beginning of your build (Figure 59).

Nuget task
(図 59) NuGet タスク(Figure 59) NuGet task

詳細については、Microsoft DevOps のブログで、「ビルドでの最新の NuGet を使用する」をご覧ください。Read more about using the latest NuGet in your build on Microsoft DevOps Blog.

NuGet の [Allow duplicates to be skipped](重複のスキップを許可する) オプションNuGet “Allow duplicates to be skipped” option

多くの NuGet ユーザーから、パッケージのセットを生成しても、その一部しか更新しないことがある (したがって、バージョン番号が更新される) という指摘がありました。We heard from many NuGet customers that they generate a set of packages, only some of which may have updates (and therefore updated version numbers). NuGet ビルド タスクの新しい [Allow duplicates to be skipped](重複のスキップを許可する) オプションを使うと、タスクは、同じバージョンが既に使われている VSTS/TFS フィードにパッケージのプッシュを試みる場合に続行できます。The NuGet build task has a new Allow duplicates to be skipped option that will enable the task to continue if it tries to push packages to a VSTS/TFS feed where the version is already in use.

npm ビルド タスクの更新npm build task updates

Windows、Linux、Mac のどれで npm プロジェクトをビルドするときでも、新しい NPM ビルド タスクはシームレスに動作します。Whether you’re building your npm project on Windows, Linux, or Mac, the new NPM build task will work seamlessly. また、npm installnpm publish の両方を簡単に行うことができるように、タスクの編成を変更しました。We have also reorganized the task to make both npm install and npm publish easier. install および publish について、プロジェクトの .npmrc ファイルに列記されているレジストリの資格情報をサービス エンドポイントに安全に保存できるように、資格情報の取得を単純化しました。For install and publish, we have simplified credential acquisition so that credentials for registries listed in your project’s .npmrc file can be safely stored in a service endpoint. または、VSTS/TFS フィードを使っている場合は、フィードを選択できるようにして、その後ビルド エージェントによって使われる必要な資格情報を含む .npmrc が生成されます。Alternatively, if you’re using a VSTS/TFS feed, we have a picker that will let you select a feed, and then we will generate a .npmrc with requisite credentials that are used by the build agent.

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

NuGet および npm とは異なり、Maven のビルド タスクはこれまで認証されたフィードで動作しませんでした。Unlike NuGet and npm, the Maven build task did not previously work with authenticated feeds. VSTS/TFS フィードを簡単に使用できるように、Maven タスクが更新されました (図 60)We’ve updated the Maven task so you can work easily with VSTS/TFS feeds (Figure 60).

dotnet task
(図 60) dotnet タスク(Figure 60) dotnet task

dotnet タスクが認証されたフィード、Web プロジェクトをサポートするdotnet task supports authenticated feeds, web projects

dotnet タスクの次のメジャー バージョン (2.x) では、フィードバック要求の多くに対応し、しばらくの間追跡した一連のバグが修正されます。The next major version of the dotnet task (2.x) addresses many of your feedback requests and fixes a set of bugs we’ve tracked for a while.

  1. 最初に、dotnet はパッケージ管理などの認証されたパッケージ ソースをサポートするようになったので、プライベート パッケージ ソースからパッケージを復元するために NuGet タスクを使う必要はなくなりました。First, dotnet now supports authenticated package sources like Package Management, so you don’t need to use the NuGet task anymore to restore packages from private package sources.
  2. [プロジェクトへのパス] フィールドの動作が、タスクの 2.0 バージョンで変更されました。The behavior of Path to project(s) field has changed in the 2.0 version of the task. 以前のバージョンのタスクでは、指定されたパターンと一致するプロジェクト ファイルが見つからない場合、タスクは警告をログに記録した後、成功していました。In previous versions of the task, if the project file(s) matching the specified pattern were not found, the task used to log a warning and then succeed. このようなシナリオでは、ビルドが成功したのに依存関係が復元されない理由を把握するのが困難な場合があります。In such scenarios it can sometimes be challenging to understand why the build succeeded but dependencies were not restored. 新しいタスクは、指定されたパターンに一致するプロジェクト ファイルが見つからない場合は失敗します。Now the task will fail if the project file(s) matching the specified pattern are not found. これは他のタスクの動作と一致しており、簡単に理解して使うことができます。This is in line with the behavior of other tasks and is easy to understand and use.
  3. 以前のバージョンのタスクの publish コマンドでは、ユーザーが明示的に出力パスを指定した場合でも、プロジェクト ファイル名に従って名前を付けられたフォルダーにすべてのファイルを格納することで、出力パスが変更されていました。In previous versions of the task’s publish command, the task modified the output path by putting all the files in a folder that was named after the project file name, even when you passed an explicit output path. このため、コマンドを連結するのが困難でした。This makes it hard to chain commands together. 新しいタスクでは、ユーザーが出力パスのファイルを制御できるようになりました。Now you have control over the output path file.

PATH で使用可能な dotnet のバージョンを管理し、新しい dotnet タスクによって使われる、新しい dotnet ツール インストーラー タスクもリリースされました。We’ve also released a new dotnet Tool Installer task that controls the version of dotnet available on the PATH and used by the new dotnet task. したがって、新しいバージョンの dotnet を使うには、ビルドの先頭に dotnet ツール インストーラー タスクを追加するだけで済みます。So, to use a newer version of dotnet, just add a dotnet Tool Installer task at the beginning of your build.

アカウント/コレクションの外部の作業Working outside your account/collection

TFS サーバーまたは VSTS アカウントの外部のフィード (図 61) を、それが別の VSTS アカウントまたは TFS サーバーの Package Management フィードか、または、Artifactory、MyGet などの Package Management 以外のフィードかにかかわらず、簡単に使用できるようになりました (図 60)It’s now easier to work with feeds (Figure 61) outside your TFS server or VSTS account, whether they’re Package Management feeds in another VSTS account or TFS server or non-Package Management feeds like, Artifactory, or MyGet (Figure 60). NuGet および npm に専用の__サービス エンドポイント__の種類により、正しい資格情報の入力が容易になり、ビルド タスクはパッケージ ダウンロード操作とパッケージ プッシュ操作の間でシームレスに動作できるようになりました。Dedicated Service Endpoint types for NuGet and npm make it easy to enter the correct credentials and enable the build tasks to work seamlessly across package download and package push operations.

Feeds to use
(図 61) 使用するフィード(Figure 61) Feed to use

VSTS/TFS フィード用のフィード ピッカーFeed picker for VSTS/TFS feeds

ソース リポジトリにパッケージの元の場所が記録されるように、構成ファイル (NuGet.Config、.npmrc など) をチェックインすることを常にお勧めします。We always recommend checking in a configuration file (e.g. NuGet.Config, .npmrc, etc.) so that your source repository has a record of where your packages came from. ただし、これが望ましくない一連のシナリオが報告されているため、新しい [この VSTS/TFS フィードからのパッケージを使用する] オプションが追加されました。このオプションを使うと、フィードを選択し、そのビルド ステップに使われる構成ファイルを自動的に生成することができます (図 62)However, we’ve heard a set of scenarios where this isn’t ideal, so we’ve added a new Use packages from this VSTS/TFS feed option that allows you to select a feed and automatically generate a configuration file that will be used for that build step (Figure 62).

Feed picker
(図 62) フィード ピッカー(Figure 62) Feed picker

ビルドとリリース Build and Release

XAML ビルド XAML Builds

TFS 2015 では、Web ベースでクロスプラットフォームのビルド システムが導入されました。In TFS 2015, we introduced a web-based, cross-platform build system. TFS 2018 RTW または Update 1 では XAML ビルドがサポートされませんが、TFS 2018 Update 2 では XAML ビルドが再有効化されました。XAML builds are not supported in TFS 2018 RTW or Update 1, but we have re-enabled XAML builds in TFS 2018 Update 2. XAML ビルドを移行することをお勧めします。We encourage you to migrate your XAML builds. まだ移行できる状態ではなく、XAML ビルドを引き続き使う必要がある場合は、TFS 2018 Update 2 にアップグレードしてください。If you're not yet ready to migrate and need to continue using XAML builds, please upgrade to TFS 2018 Update 2.

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

  • XAML ビルドのデータがチーム プロジェクト コレクション内にある場合は、XAML ビルド機能の削除に関する警告が表示されます。If you have any XAML build data in your team project collection, you'll get a warning about the removal of XAML build features.

  • 完了した XAML ビルドを表示することはできますが、新しいビルドをキューに入れることはできません。You'll be able to view completed XAML builds, but you won't be able to queue new ones.

  • TFS 2018 には新しいバージョンの XAML ビルド コントローラーまたはエージェントがありません。There's no new version of the XAML build controller or agent in TFS 2018.

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

  • XAML ビルドのデータがチーム プロジェクト コレクション内にある場合は、XAML ビルド機能の廃止に関する警告が表示されます。If you have any XAML build data in your team project collection, you'll get a warning about the deprecation of XAML build features.

  • VS またはチーム エクスプローラー 2017 を使用して、XAML ビルド定義を編集するか、 または新しい XAML ビルドをキューに入れる必要があります。You will need to use VS or Team Explorer 2017 to edit XAML build definitions or to queue new XAML builds.

  • 新しい XAML ビルド エージェントを作成する必要がある場合は、TFS 2015 ビルド エージェントのインストーラーを使用してそれらをインストールする必要があります。If you need to create new XAML build agents, you’ll need to install them using the TFS 2015 build agent installer.

XAML ビルドの廃止予定の詳細については、TFS/Team Services 構築の自動化機能の進化に関するブログ記事を参照してください。For an explanation of our XAML build deprecation plan, see the Evolving TFS/Team Services build automation capabilities blog post.

ビルド定義のインポートとエクスポート Export and import build definitions

ビルド定義は .json ファイルとして内部的に実装されるので、ファイルの履歴で変更に関する詳細を見ることができます。Build definitions are implemented internally as .json files, so you can see details on changes in the file’s history. ビルド定義からテンプレートを複製および作成することは既にできますが、多くのユーザーは、その CI ビルド ロジックをコピーし、別のチーム プロジェクトで再利用できることを望んでいます。You can already clone and make templates from your build definitions, but many users have wanted to take a copy of their CI build logic and reuse it in another team project. 実際に、これは UserVoice で上位 10 件に入る要望でした。In fact it’s been a top-ten request on UserVoice.

ついにこれが可能になったことをお知らせします (図 63)(図 64)We’re pleased to announce that this is now possible (Figure 63) and (Figure 64)!

Export build definition
(図 63) ビルド定義のエクスポート(Figure 63) Export build definition
Import build definition
(図 64) ビルド定義のインポート(Figure 64) Import build definition

ビルド テンプレートに関する拡張機能Extensions with build templates

ビルド テンプレートを使うと、ユーザーがビルド プロセスの定義を始めるときのベースラインを作成できます。Build templates let you create a baseline for users to get started with defining their build process. これまで、製品には複数のテンプレートが付属し、ユーザーは新しいテンプレートをアカウントにアップロードできましたが、拡張機能の作成者が拡張機能の一部として新しいテンプレートを含めることはできませんでした。We ship a number of them in the box today and while you could upload new ones to your account, it was never possible for extension authors to include new templates as part of an extension. このバージョンでは、拡張機能にビルド テンプレートを含めることができるようになりました。You can now include build templates in your extensions. 例:For example:

{  "id": "Template1", 
   "type": "ms.vss-build.template", 
   "targets": [ "ms.vss-build.templates" ], 
   "properties": { "name": "Template1" } }

完全な例については、 を参照してください。For the full example, see


この機能を使うと、同じカスタム テンプレートを提供してすべてのチーム プロジェクトで共有することができます。You can use this capability to offer and share the same custom template across all your team projects.

拡張機能のタスクを非推奨にするDeprecate a task in an extension

拡張機能のタスクを非推奨にできるようになりました。You can now deprecate a task in your extension. そのためには、タスクの最新バージョンに次の変数を追加する必要があります。To make it work, you must add the following variable to the latest version of your task:

"deprecated": true

ユーザーが非推奨のタスクを検索すると (図 65)、これらのタスクは一覧の最後に移動され、既定で折りたたまれる折りたたみ可能なセクションにグループ化されます。When the user searches for deprecated tasks (Figure 65), we push these tasks to the end and group them under a collapsible section that’s collapsed by default. 定義で非推奨のタスクが既に使われている場合は、非推奨タスク バッジが表示され、ユーザーは代わりのタスクへの切り替えを促されます。If a definition is already using a deprecated task, we show a deprecated task badge to encourage users to switch to the replacement.

Deprecated task badge
(図 65) 非推奨のタスク バッジ(Figure 65) Deprecated task badge

タスクの説明で言及することにより、ユーザーに代わりのタスクを伝えることができます (図 66)You can help your users learn about the replacement task by mentioning it in the task description (Figure 66). 説明では、タスク カタログおよび既存のビルド/リリース定義の両方から正しい方向のタスクを使ってフォークをポイントします。The description will then point folks using the task in the right direction from both the task catalog and the existing build/release definitions.

Deprecated task description
(図 66) 非推奨のタスクの説明(Figure 66) Deprecated task description

提供されたビルドのセクションでセクションの可視性を制御できるLet contributed build sections control section visibility

従来、ビルド タスクとビルド概要セクションのある拡張機能を使用している場合は、そのビルドでビルド タスクを使用していない場合でも、ビルド概要セクションが表示されました。Previously, if you were using an extension that had build tasks and build summary sections, you’d see the build summary section even if you weren’t using the build task in that build. 現在は、次の行を拡張機能のコードに追加して値を true または false に設定することで、ビルド概要ページにそのセクションを表示するかどうかを選択できます。Now, you can choose to hide or show that section in the build summary page by adding the following line in your extension code and setting the value to true or false:

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

Microsoft vsts-extension-samples リポジトリのサンプルをご覧ください。View the sample included in the Microsoft vsts-extension-samples repository.

変数グループのサポートVariable group support

リリース定義で変数グループを使うことができましたが、ビルド定義でも使用できるようになりました。Variable groups have been available to use in release definitions, and now they are ready to be used in build definitions, too. 詳しくは、creating a variable group (変数グループの作成) に関する記事をご覧ください。Learn more about creating a variable group. この機能は、プロジェクト レベルのビルド/リリース変数およびビルド定義での変数グループに関する提案に基づいて優先的に開発されました。This has been developed and prioritized based on related suggestions for project-level build/release variables and variable groups in build definitions.

Apple の証明書などのセキュリティで保護されたファイルの使用Work with secure files such as Apple certificates

汎用的なセキュリティで保護されたファイル ライブラリが追加されました (図 67)We’ve added a general-purpose secure files library (Figure 67).

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

セキュリティで保護されたファイル ライブラリを使うと、署名証明書、Apple Provisioning Profiles、Android Keystore ファイル、SSH キーなどのファイルを、ソース リポジトリにコミットすることなくサーバーに格納できます。Use the secure files library to store files such as signing certificates, Apple Provisioning Profiles, Android Keystore files, and SSH keys on the server without needing to commit them to your source repository.

セキュリティで保護されたファイルの内容は暗号化され、タスクから参照することにより、ビルド プロセスまたはリリース プロセスの間にのみ使うことができます。The contents of secure files are encrypted and can only be used during build or release processes by referencing them from a task. セキュリティで保護されたファイルは、セキュリティの設定に基づいて、チーム プロジェクトの複数のビルド定義およびリリース定義で使用できます。Secure files are available across multiple build and release definitions in the team project based on security settings. セキュリティで保護されたファイルは、ライブラリ セキュリティ モデルに従います。Secure files follow the Library security model.

この新しい機能を利用する Apple タスクもいくつか追加されました。We’ve also added some Apple tasks that leverage this new feature:

ビルド定義の一時停止Pause build definitions

ビルド定義を一時停止または無効にすることができるようになりました。You can now pause or disable build definitions. ビルド定義を変更するときに、完了するまで新しいビルドのキューを避けたい場合は、ビルド定義を無効にするだけで済みます。If you plan to make changes to your build definition and you want to avoid queuing any new builds until you are done, simply disable the build definition. 同様に、エージェント マシンをアップグレードする予定がある場合は、ビルド定義を一時停止することもできます。これにより、VSTS は新しいビルド要求を引き続き受け入れますが、それらをキューに入れて保持し、定義を再開するまで実行しません。Similarly, if you plan to upgrade agent machines, you can choose to pause a build definition, which enables VSTS to still accept new build requests but hold them in queue without running until you resume the definition.

タスクの入力検証をサポートTask input validations support

ビルド定義タスクにパラメーターを入力する場合、エラーが発生することがあります。Typing the parameters in build definition tasks can sometimes be error prone. タスクのパラメーター入力検証では、タスクの作成者は適切な値が指定されるようにすることができます。With task input validation, task authors can ensure appropriate values are specified. 検証条件式は、タスク条件に使用される一般的な式構文に従います。このため、検証条件式では、URL、IPV4、電子メール、番号範囲、sha1、長さ、または一致など、タスク条件でサポートされている一般的な機能以外にもサポートされている関数を使用できます。Validation expressions follow the familiar expression syntax used for task conditions and can use any of the supported functions besides the general functions supported by task conditions, including URL, IPV4, email, number range, sha1, length, or match.

目標と使用の詳細については、vsts-tasks リポジトリ ページ を参照してください。Read more about the goals and usage on the vsts-tasks repo page.

新しいリリース定義エディター New Release Definition Editor

引き続きビルドとリリースのエクスペリエンスの更新が行われており、リリース定義エディターについて、エクスペリエンスをより直感的にし、使いにくさを解消して、新しい機能を追加することが予定されています。Continuing on our journey of refreshing the Build and Release experiences, we have re-imagined the release definition editor to provide a more intuitive experience, fix some pain points, and add new capabilities. 新しいエディターの最も強力な機能の 1 つは、環境への展開の進み具合を視覚化する機能です。One of the most powerful features of the new editor is its ability to help you visualize how deployments to your environments would progress. さらに、承認、環境のプロパティ、配置の設定が現在コンテキスト内にあり、簡単に構成できます。In addition to this, approvals, environment properties, and deployment settings are now in-context and easily configurable.

パイプラインの視覚化Visualization of the pipeline

エディターのパイプライン (図 68) は、リリースでの配置の進捗状況をグラフィカル ビューで提供します。The pipeline (Figure 68) in the editor provides a graphical view of how deployments will progress in a release. 成果物はリリースで使用されて、環境に配置されます。The artifacts will be consumed by the release and deployed to the environments. 環境のレイアウトとリンクは、各環境に定義されているトリガー設定を反映します。The layout and linking of the environments reflects the trigger settings defined for each environment.

(図 68) リリース パイプライン(Figure 68) Release pipeline
コンテキスト内の構成 UIIn context configuration UI

成果物、リリース トリガー、配置前と配置後の承認、環境のプロパティ、配置の設定が現在コンテキスト内にあり、簡単に構成できます (図 69)Artifacts, release triggers, pre-deployment and post-deployment approvals, environment properties, and deployment settings are now in-context and easily configurable (Figure 69).

Release configuration
(図 69) リリース構成(Figure 69) Release configuration
展開テンプレートの概要Getting started with deployment templates

組み込みの展開テンプレートはすべてプロセス パラメーターを備えています。このパラメーターを使用すれば、ユーザーはタスクの詳細を隅々まで確認しなくても、最も重要なパラメーターを指定することで簡単に作業を開始することができます (図 70)All in-built deployment templates are equipped with process parameters which makes it easier for users to get started by specifying the most important parameters without needing to go deep into your tasks (Figure 70).

Deployment templates
(図 70) 展開テンプレート(Figure 70) Deployment templates
リリースおよび環境変数の管理の簡素化Simplified management of release and environment variables

リリースまたは環境変数を迅速に追加するにはリスト ビューを使用し、変数をスコープ間で同時に比較および編集するにはグリッド ビューを使用します (図 71)Use the List view to quickly add release or environment variables and the Grid view to compare and edit variables across scopes side-by-side (Figure 71). さらに、フィルターとキーワード検索を使用して、両方のビューで使用する変数セットを管理することができます。Additionally, you can use the filter and keyword search to manage the set of variables to work with in both the views.

Simplified management of variables
(図 71) 変数の管理の簡素化(Figure 71) Simplified management of variables
タスクおよびフェーズ エディターの強化Improved task and phase editor

新しいビルド定義エディターでのすべての機能強化が、リリース定義エディターでも使用できるようになりました (図 72)All the enhancements in the new build definition editor are now available in the release definition editor, as well (Figure 72). タスクを検索し、[追加] ボタンまたはドラッグ アンド ドロップを使って追加できます。You can search for tasks and add them by either using the Add button or by using drag/drop. ドラッグ アンド ドロップを使って、タスクの順序を変更したりタスクを複製したりできます。You can reorder or clone tasks using drag/drop.

Task editor
(図 72) タスク エディター(Figure 72) Task editor
[変数グループ]、[保有期間]、[オプション] タブVariable groups, Retention, and Options tabs

変数グループのリンク/リンク解除 (図 73)、個々の環境の保有期間ポリシーの設定、リリース番号形式などのリリース定義レベルの設定の変更を、[オプション] タブから行うことができるようになりました。また、展開テンプレートとしての環境の保存、環境レベルのアクセス許可の設定、フェーズの順序の変更を、[タスク] タブで行うことができます。You can now link/unlink to variable groups (Figure 73), set retention policy for individual environments, and modify release definition-level settings such as release number format from the Options tab. You can also save an environment as a deployment template, set environment level permissions, and re-order phases within the Tasks tab.

Variable groups
(図 73) 変数グループ(Figure 73) Variable groups

環境レベルの操作を使って、テンプレートを保存し、セキュリティを設定します (図 74)Use environment level operations to save as template and set security (Figure 74).

Environment menu
(図 74) 環境メニュー(Figure 74) Environment menu

詳細については、リリース定義エディターのドキュメント を参照してください。See the documentation for Release Definition Editor for more information.

配置グループを使った VM の配置 VM Deployment using Deployment Groups

Release Management は、堅牢で設定なしで使用できる複数のコンピューターの配置をサポートするようになりました。Release Management now supports robust out-of-the-box multi-machine deployment. アプリケーション全体の高可用性を確保しながら、複数のコンピューターの間で配置を調整し、ローリング更新を実行できます。You can now orchestrate deployments across multiple machines and perform rolling updates while ensuring high availability of the application throughout.

エージェント ベースの配置機能は、同じビルドと配置エージェントに依存します。Agent-based deployment capability relies on the same build and deployment agents. ただし、エージェント プールの一連のプロキシ サーバーにビルドと配置エージェントをインストールしてリモート ターゲット サーバーへの配置を行う現在のアプローチとは異なり、各ターゲット サーバーに直接エージェントをインストールして、それらのサーバーへのローリング配置を行います。However, unlike the current approach where you install the build and deployment agents on a set of proxy servers in an agent pool and drive deployments to remote target servers, you install the agent on each of your target servers directly and drive rolling deployments to those servers. ターゲット コンピューター上の完全なタスク カタログを使うことができます。You can use the full task catalog on your target machines.

1 つの配置グループは (図 75)、それぞれにエージェントがインストールされているターゲット (コンピューター) の論理的なグループです。A deployment group (Figure 75) is a logical group of targets (machines) with agents installed on each of them. 配置グループの集合は、単一コンピューターの開発、複数コンピューターの QA、UAT/Prod 用のコンピューターのファームなど、物理的な環境を表します。また、物理環境のセキュリティ コンテキストを指定します。Deployment groups represent your physical environments, such as single-box Dev, multi-machine QA, and a farm of machines for UAT/Prod. They also specify the security context for your physical environments.

Deployment groups
(図 75) 配置グループ(Figure 75) Deployment groups

エージェントが登録されている任意の VM に対して、これを使うことができます。You can use this against any VM that you register our agent with. また、VM のスピンアップ時にエージェントを自動インストールする Azure VM 拡張機能を備えた Azure に非常に簡単に登録することができます。We’ve also made it very easy to register with Azure with support for an Azure VM extension that auto-installs the agent when the VM spins up. 登録時には、Azure VM 上のタグを自動的に継承します。We will automatically inherit the tags on the Azure VM when it’s registered.

配置グループを作成した後は、その配置グループで実行させたいことを構成するだけです (図 76)Once you have a deployment group, you simply configure what you want us to execute on that deployment group (Figure 76). タグを使ってどのコンピューターで何を実行するかを制御し、ロールアウトの速さを制御できます。You can control what gets run on which machines using tags and control how fast or slow the rollout happens.

Configure deployment groups
(図 76) 配置グループの構成(Figure 76) Configure deployment groups

配置を実行すると、対象のコンピューター グループ全体での進行状況がログに表示されます (図 77)When the deployment is run, the logs show the progression across the entire group of machines you are targeting (Figure 77).

Deployment group progress
(図 77) 配置グループの進行状況(Figure 77) Deployment group progress

この機能は、Release Management に統合されています。This feature is now an integrated part of Release Management. その他のライセンスは不要です。No additional licenses are required.

配置グループ UI の改良Improved Deployment Groups UI

引き続きビルドリリースのエクスペリエンスの更新が行われており、配置グループ ページについて、エクスペリエンスがさらに直観的になる予定です (図 78)Continuing our journey of refreshing the Build and Release experiences, we have now re-imagined our deployment groups pages to make it a more clean and intuitive experience (Figure 78). ランディング ページから、配置グループ内のターゲットの正常性を確認できます。From the landing page, you can view the health of the targets in the deployment group. また、個々 の配置グループのセキュリティを管理することも、配置グループ間の既定のアクセス許可を設定することもできます。You can also manage security for an individual deployment group, or set default permissions across deployment groups.

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

配置グループ内のターゲットについて、概要、最近の配置、ターゲットの機能を表示できます (図 79)For a target within a deployment group, you can view a summary, recent deployments, and the target’s capabilities (Figure 79). ターゲットに対してタグを設定し、各ターゲット上で実行するものを制御できます。You can set tags on the target, and control what is run on each target. 今後のリリースでは、配置グループに対してフィルターのサポートを追加する予定です。We will be adding filter support for deployment groups in upcoming releases.

Deployment groups UI tags
(図 79) 配置グループの UI のタグ(Figure 79) Deployment groups UI tags

タスク グループの参照Task group references

タスク グループを使うと、ビルド定義またはリリース定義に追加できるタスクのセットを定義できます (図 80)Task groups let you define a set of tasks that you can add to your build or release definitions (Figure 80). これは、複数のビルドまたはリリースでタスクの同じグループを使う必要がある場合に便利です。This is handy if you need to use the same grouping of tasks in multiple builds or releases. タスク グループのコンシューマーを追跡するため、タスク グループを参照しているビルド定義、リリース定義、タスク グループを表示できるようになりました (図 79)To help you track the consumers of a task group, you now have a view into the build definitions, release definitions, and task groups that reference your task group (Figure 79).

Task group references
(図 80) タスク グループの参照(Figure 80) Task group references

まだ参照されているタスク グループを削除しようとすると、警告とこのページへのリンクが表示されます。When you try to delete a task group that’s still referenced, we warn you and give you a link to this page.

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

タスク グループを変更するときは、そのタスク グループを使っているすべての定義に変更が反映されるため、危険な場合があります。When making changes to task groups, it can feel risky because the change is effective to all definitions that use the task group. タスク グループのバージョン管理を行うと、タスク グループのバージョンのドラフトやプレビューを行いながら、切り替えの準備ができるまで、最も重要な定義に安定したバージョンを提供できます。With task group versioning, now you can draft and preview task group versions while still offering stable versions to your most important definitions until you are ready to switch. ドラフトやイテレーションを行った後は、安定したバージョンを公開することができ、公開しながら、本質的に互換性に影響する変更の場合は、タスク グループをプレビュー (新しいメジャー バージョン) として公開することができます。After some drafting and iteration, you can publish a stable version and, while publishing, if the changes are breaking in nature, you can choose to publish the task group as preview (a new major version). または、更新された安定したバージョンとして直接公開することもできます (図 81)Alternatively, you can publish it directly as an updated stable version (Figure 81).

タスク グループの新しいメジャー (またはプレビュー) バージョンが利用可能なときは、新しいバージョンがあることが定義エディターに表示されます。When a new major (or preview) version of the task group is available, the definition editor will advise you that there is a new version. そのメジャー バージョンがプレビューの場合は、"試してみる" というメッセージも表示されます。If that major version is preview, you even see a “try it out” message. タスク グループがプレビューを終了すると、それを使用する定義が自動的に更新され、そのメジャー チャネルに移行します (図 82)When the task group comes out of preview, definitions using it will be auto-updated, sliding along that major channel (Figure 82).

Save as draft
(図 81) ドラフトとしてのタスク グループの保存(Figure 81) Save task group as draft
Publish task group as preview
(図 82) プレビューとしてのタスク グループの公開(Figure 82) Publish task group as preview

タスク グループのインポートとエクスポートTask group import and export

タスク グループはプロジェクト内で再利用できますが、異なるプロジェクトやアカウントでタスク グループを再作成するのは面倒です。Although task groups have enabled reuse within a project, we know that recreating a task group across projects and accounts can be painful. タスク グループの Import/Export では (図 83)、リリース定義の場合と同じように、タスク グループを JSON ファイルとしてエクスポートし、必要な場所にインポートできます。With task group import/export (Figure 83), as we’ve done for release definitions, now you can export as a JSON file and import where you want it. 入れ子になったタスク グループも使用でき、最初にエクスポートするときに展開されます。We’ve also enabled nested task groups, which first expand when they are exported.

Export task group
(図 83) タスク グループのエクスポート(Figure 83) Export task group

サーバー側 (エージェントレス) タスクでの複数構成のサポートMulti Configuration support in Server Side (Agentless) tasks

サーバー側 (エージェントレス) タスクに対して可変乗数を指定することにより (図 84)、同じタスク セットを段階的に複数の構成で並列に実行できます。By specifying variable multipliers for server side (agentless) tasks (Figure 84), you can now run the same set of tasks in a phase on multiple configurations, which run in parallel.

Multi configuration of agentless tasks
(図 84) エージェントレス タスクの複数の構成(Figure 84) Multi configuration of agentless tasks

手動介入タスクでの変数のサポートVariables Support in Manual Intervention task

__手動で介入__タスクが (図 85)、タスクの実行時に、ユーザーがリリース プロセスの実行を再開または拒否できる時点で、ユーザーに示される指示テキスト内での変数の使用をサポートするようになりました。The Manual Intervention task (Figure 85) now supports the use of variables within the instruction text shown to users when the task runs, at the point where the user can resume execution of the release process or reject it. リリース内で定義されていて利用可能な任意の変数を含めることができ、値は通知およびユーザーに送信されるメールで使われます (図 86)Any variables defined and available in the release can be included, and the values will be used in the notifications as well as in the email sent to users (Figure 86).

Manual intervention task
(図 85) 手動介入タスク(Figure 85) Manual intervention task
Manual intevention pending dialog
(図 86) [手動介入を保留中] ダイアログ(Figure 86) Manual intervention pending dialog

ソース ブランチに基づいて環境へのリリースを制御するControl releases to an environment based on the source branch

新しいリリースが作成されたら (通常は、ソースのビルドが成功した後)、配置を自動的にトリガーするように、リリース定義を構成できます。A release definition can be configured to trigger a deployment automatically when a new release is created, typically after a build of the source succeeds. ただし、任意のビルドが成功したときではなく、ソースの特定のブランチからのビルドのみを配置したいことがあります。However, you may want to deploy only builds from specific branches of the source, rather than when any build succeeds.

たとえば、開発およびテスト環境にはすべてのビルドを配置しますが、運用環境には特定のビルドのみを配置するような場合です。For example, you may want all builds to be deployed to Dev and Test environments, but only specific builds deployed to Production. 以前は、そのためには、2 つのリリース パイプラインを維持する必要がありました (開発およびテスト環境用に 1 つと、運用環境用に 1 つ)。Previously you were required to maintain two release pipelines for this purpose, one for the Dev and Test environments and another for the Production environment.

Release Management では、環境ごとの成果物フィルターの使用がサポートされるようになりました。Release Management now supports the use of artifact filters for each environment. つまり、配置トリガー条件 (ビルドの成功や、新しいリリースの作成など) が満たされたときに、各環境に配置されるリリースを指定することができます。This means you can specify the releases that will be deployed to each environment when the deployment trigger conditions (such as a build succeeding and creating a new release) are met. 環境の [配置条件] ダイアログの [トリガー] セクションで (図 87)、その環境への新しい配置をトリガーするビルドのソース ブランチとタグなど、成果物の条件を選びます。In the Trigger section of the environment Deployment conditions dialog (Figure 87), select the artifact conditions such as the source branch and tags for builds that will trigger a new deployment to that environment.

Deployment conditions dialog
(図 87) [配置条件] ダイアログ(Figure 87) Deployment conditions dialog

さらに、[リリース概要] ページには (図 88)、すべての "開始しなかった" 配置がその状態になった理由を示し、配置を開始する方法やタイミングを示唆する、ポップアップ ヒントが含まれます。In addition, the Release Summary page (Figure 88) now contains a pop-up tip that indicates the reason for all “not started” deployments to be in that state, and suggests how or when the deployment will start.

Release summary tip
(図 88) リリース概要のヒント(Figure 88) Release summary tip

成果物ソースとしての Git リポジトリのリリース トリガーRelease Triggers for Git repositories as an artifact source

Release Management は、同じアカウント内の任意のチーム プロジェクトのリリース定義にリンクされている Git リポジトリの継続的配置トリガーの構成 (図 89) をサポートするようになりました。Release Management now supports configuring a continuous deployment trigger (Figure 89) for Git repositories linked to a release definition in any of the team projects in the same account. これにより、新しいコミットがリポジトリに対して行われたときに自動的にリリースをトリガーできます。This lets you trigger a release automatically when a new commit is made to the repository. また、コミットがリリースをトリガーする Git リポジトリ内のブランチを指定することもできます。You can also specify a branch in the Git repository for which commits will trigger a release.

Release triggers
(図 89) リリース トリガー(Figure 89) Release triggers

リリース トリガー: Git リポジトリにプッシュされた変更の継続的配置Release Triggers: Continuous deployment for changes pushed to a Git repository

Release Management は常に、ビルドが完了したときの継続的配置を構成する機能を提供してきました。Release Management has always provided the capability to configure continuous deployment when a build completes. しかし現在は、Git プッシュでの継続的配置を構成することもできます。However, now you can also configure continuous deployment on Git Push. つまり、GitHub と Team Foundation Git リポジトリをリリース定義に成果物ソースとしてリンクした後、ビルドから生成されない Node.JS や PHP などのアプリケーションに対して自動的にリリースをトリガーし、継続的配置にビルド アクションが必要ないようにすることができます。This means that you can link GitHub and Team Foundation Git repositories as artifact sources to a release definition, and then trigger releases automatically for applications such as Node.JS and PHP that are not generated from a build and so do not need a build action for continuous deployment.

環境トリガーでのブランチ フィルターBranch filters in environment triggers

新しいリリースの定義エディターでは、特定の環境に合わせて成果物の条件を指定できるようになりました。In the new release definition editor you can now specify artifact conditions for a particular environment. このような成果物の条件を使用すると、特定の環境に配置する必要がある成果物をより詳細に制御できるようになります。Using these artifact conditions, you will have more granular control on which artifacts should be deployed to a specific environment. たとえば、運用環境の場合、マスター ブランチから生成されたビルドのみが配置されていることを確認したい場合があります。For example, for a production environment you may want to make sure that builds generated only from the master branch are deployed. このフィルターは、この条件を満たす必要があると考えられるすべての成果物に対して設定する必要があります。This filter needs to be set for all artifacts that you think should meet this criterion.

リリース定義にリンクされている成果物ごとに複数のフィルターを追加することもできます (図 90)You can also add multiple filters for each artifact that is linked to the release definition (Figure 90). 成果物の条件がすべて正常に満たされた場合にのみ、この環境への配置がトリガーされます。Deployment will be triggered to this environment only if all the artifact conditions are successfully met.

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

サーバー側タスクの機能強化Enhancements to server-side tasks

サーバー側タスク (サーバー フェーズ内で実行されるタスク) に対して 2 つの機能強化を行いました。We have made two enhancements to server-side tasks (tasks that run within a server phase).

自動パイプラインの一部として汎用的な HTTP REST API (図 91) を呼び出すために使うことができる新しいタスクを追加しました。We have added a new task that can be used to invoke any generic HTTP REST API (Figure 91) as part of the automated pipeline. たとえば、このタスクを使うと、Azure 関数を使う特定の処理を呼び出し、その完了を待機できます。For example, it can be used to invoke specific processing with an Azure function, and wait for it to be completed.

(図 91) REST API タスク(Figure 91) REST API task

また、すべてのサーバー側タスクに [管理オプション] セクション (図 92) が追加されました。We have also added a Control options (Figure 92) section to all server-side tasks. タスクの動作に、[有効][エラー時に続行][常に実行]、および [タイムアウト] の各オプションの設定が含まれるようになりました。Task behavior now includes setting the Enabled, Continue on error, Always run, and Timeout options.

Task control options
(図 92) タスク管理オプション(Figure 92) Task control options

[コード] ハブのリリース状態バッジRelease status badge in Code hub

今日、コミットが顧客の運用環境に配置されているかどうかを確認する場合は、最初に、どのビルドがコミットを使用しているかを明らかにした後、そのビルドが配置されているすべてのリリース環境を確認します。Today, if you want to know whether a commit is deployed to your customer production environment, you first identify which build consumes the commit and then check all the release environments where this build is deployed. このエクスペリエンスは、配置状態が [コード] ハブの状態バッジに統合されて、コードが配置されている環境の一覧が表示されるようになったことで、はるかに簡単になりました。Now this experience is much easier with the integration of the deployment status in the Code hub status badge to show the list of environments that your code is deployed to. すべての配置について、配置の一部であった最新のコミットに状態が通知されます。For every deployment, status is posted to the latest commit that was part of the deployment. 複数の環境の複数のリリース定義にコミットが配置される場合は、それぞれがバッジにエントリを持ち、環境ごとに状態が表示されます (図 93)If a commit is deployed to multiple release definitions (with multiple environments) then each has an entry in the badge, with status shown for each environment (Figure 93). これにより、配置に対するコードのコミットの追跡可能性が向上します。This improves the traceability of code commit to deployments.

Release status badge
(図 93) リリース状態バッジ(Figure 93) Release status badge

既定では、リリース定義を作成すると、配置の状態がすべての環境に通知されます。By default, when you create a release definition, deployment status is posted for all environments. ただし、配置状態を状態バッジに表示する環境を選択できます (たとえば、運用環境のみを表示する) (図 94)However, you can selectively choose the environments whose deployment status should be displayed in the status badge (e.g. only show production environments) (Figure 94).

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

成果物を追加するときのビルド定義メニューの機能強化Enhancements to Build definition menu when adding artifacts

ビルド成果物をリリース定義に追加するとき、定義とフォルダー編成の情報を表示できるようになり、目的の定義の選択が容易になりました (図 95)When adding build artifacts to a release definition, you can now view the definitions with their folder organization information and simplify choosing the desired definition (Figure 95). これにより、フォルダーが異なる同じ名前のビルド定義を簡単に区別できます。This makes it easy to differentiate the same build definition name but in different folders.

Add artifact
(図 95) 成果物の追加(Figure 95) Add artifact

定義の一覧は、フィルター条件を含むものによってフィルター処理されます。The list of definitions is filtered based on those that contain the filter term.

古いバージョンにリリース定義を戻すRevert your release definition to older version

現在、リリース定義を更新する場合、前のバージョンに直接戻すことはできません。Today, if a release definition is updated, you can’t directly revert to a previous version. 唯一の方法は、リリース定義の履歴を見て、変更の相違を見つけ、リリース定義を手動で編集することです。The only way is to look into the release definition history to find the diff of the changes, and then manually edit the release definition. 新しいバージョンでは、[定義を元に戻す] 機能を使って (図 96)、リリース定義の [履歴] タブから古いバージョンのリリース定義を選んで戻すことができます。Now, using the Revert Definition feature (Figure 96), you can choose, and revert back to any older version of a release definition from the release definition History tab.

Revert release definition
(図 96) リリース定義を元に戻す(Figure 96) Revert release definition

個人用のリリース通知Personalized notifications for releases

リリース通知が VSTS 通知設定のエクスペリエンスに統合されました。Release notifications are now integrated with the VSTS notification settings experience. リリースを管理するユーザーには、保留中のアクション (承認または手動介入) と重要な配置エラーが自動的に通知されるようになりました。Those managing releases are now automatically notified of pending actions (approvals or manual interventions) and important deployment failures. このような通知はオフにすることができます。そのためには、プロファイル メニューの [通知] 設定を開き、[Release Subscriptions](リリースのサブスクリプション) をオフに切り替えます。You can turn off these notifications by navigating to the Notification settings under the profile menu and switching off Release Subscriptions. カスタム サブスクリプションを作成して追加の通知をサブスクライブすることもできます。You can also subscribe to additional notifications by creating custom subscriptions. 管理者は、[チーム] 設定と [アカウント] 設定の下にある [通知] 設定からチームとアカウントのサブスクリプションを制御できます。Admins can control subscriptions for teams and groups from the Notification settings under Team and Account settings.

リリース定義の作成者は、承認と配置の完了に関する電子メールを手動で送信しなくてもよくなりました。Release definition authors will no longer need to manually send emails for approvals and deployment completions.

これは、複数のリリースの関係者と、通知を受け取りたいユーザー (承認者、リリース作成者、環境の所有者を除く) を有する大規模アカウントに特に便利です (図 97)This is especially useful for large accounts that have multiple stakeholders for releases, and for those other than the approver, release creator, and environment owner that might want to be notified (Figure 97).

Release notifications
(図 97) リリース通知(Figure 97) Release notifications

詳細については、リリース通知の管理に関する投稿を参照してください。See the post for managing release notifications for more information.

テスト Testing

Microsoft Test Manager でのラボ センターと自動テスト フローのサポートの削除 Removing support for Lab Center and automated testing flows in Microsoft Test Manager

ビルドと Release Management の発展により、TFS 2018 では XAML ビルドはサポートされなくなり、結果として、TFS での Microsoft Test Manager (MTM) の使用のサポートが更新されています。With the evolution of Build and Release Management, XAML builds are no longer supported in TFS 2018 and consequently we are updating support for using Microsoft Test Manager (MTM) with TFS. 自動テストのための MTM でのテスト センター/ラボ センターの使用は、TFS 2018 以降ではサポートされていません。Using Test Center/Lab Center in MTM for automated testing is no longer supported by TFS, starting with TFS 2018. XAML ビルドおよびラボ センターから移行する準備ができていない場合は、TFS 2018 にアップグレードしないでください。If you are not ready to migrate away from XAML builds and Lab Center, you should not upgrade to TFS 2018.

TFS 2018 へのアップグレードの影響を以下で確認してください。Please see the impact of upgrading to TFS 2018 below:

ラボ センター:Lab Center:
  • サポート対象から除外されました。No longer supported:
    • ラボ環境を作成および管理するためにテスト コントローラーを TFS に登録することはできません。Test Controllers cannot be registered with TFS for creating and managing Lab environments.
    • TFS に登録されている既存のテスト コントローラーはオフラインになり、既存のラボ環境は "準備不完了" と表示されます。Any existing Test Controllers registered with TFS will go offline and existing Lab environments will appear as 'Not Ready'.
  • 推奨される代替方法:Recommended alternative:
自動テスト:Automated Testing:
手動テスト:Manual Testing:
  • すべての手動テスト シナリオは引き続き完全にサポートされます。All manual testing scenarios continue to be fully supported. TFS 2018 で MTM を使って手動テストを実行することはできますが、ラボ環境を使って手動テストを実行することはできません。While manual tests can be run using MTM with TFS 2018, Lab Environments cannot be used to run manual tests.
  • すべての手動テスト シナリオについて、TFS の Web アクセスで [テスト] ハブを使うことを強くお勧めします。For all manual testing scenarios, we strongly recommend using the Test hub in TFS web access.

探索的テストを行っているチームからのフィードバックに基づき、Test & Feedback 拡張機能からバグ、タスク、またはテスト ケースを収集しながら、追跡可能性リンクの機能強化を行っています。Based on the feedback we received from teams doing exploratory testing, we are improving traceability links while filing bugs, tasks, or test cases from the Test & Feedback extension. 要件の検証中に作成されたバグとタスクは、チームの既定値ではなく、要件と同じ区分パスとイテレーションで作成されるようになります。Bugs and tasks created while exploring requirements will now be created with the same area path and iteration as that of the requirement instead of team defaults. 要件の検証中に作成されたテスト ケースは、作成したテスト ケースが要件に基づくテスト スイートに自動的に追加されるように、Parent <-> Child リンクではなく Tests <-> Tested By リンクでリンクされるようになります。Test cases created while exploring requirements will now be linked with a Tests <-> Tested By link instead of the Parent <-> Child link so that the test cases you create are automatically added to requirement based test suites. 最後に、特にどの要件も検証されていないときに作成された作業項目は、スプリント計画が完了した後で現在のイテレーションに新しい作業項目が追加されないように、現在のイテレーションではなくチームの既定のイテレーションに記録されます。Finally, work items created while not specifically exploring any requirement will be filed in the team’s default iteration instead of the current iteration so that no new work items come into the current iteration after the sprint planning is complete.

テスト ハブでのテスト計画とテスト スイートのテスト ケース作業項目のフィルター処理Filters for Test Case work items in Test Plans and Suites in Test Hub

[結果][構成][テスト担当者] などの [テスト] フィールドでのフィルターと同様に、[タイトル][状態][担当者] などのテスト ケース作業項目のフィールドでフィルター処理できるようになりました (図 98)In addition to the filters on Test fields like Outcome, Configuration, and Tester, you can now filter on Test Case work item fields like Title, State, and Assigned To (Figure 98).

Test case filters
(図 98) テスト ケース フィルター(Figure 98) Test case filters

リリース環境とテスト実行のテスト傾向グラフTest trend charts for Release Environments and Test Runs

VSTS ダッシュボードでテスト環境の状態を追跡できるよう、テスト結果トレンド ウィジェット (図 99)リリース環境のサポートを追加しています。We are adding support for Release Environments in the Test Result Trend widget (Figure 99) so that you can track status of test environments on VSTS dashboards. ビルドでテスト結果に対して行うのと同様の方法で、リリース環境のテスト合格率、合計、合格/不合格のテストの数、テスト期間を示す傾向グラフを作成できるようになりました。Like the way you to do for test results in Build, you can now create trend charts showing test pass rate, count of total, passed or failed tests, and test duration for Release Environments. [テスト実行] タイトル フィルターで、グラフをフィルター処理して環境内の特定のテスト実行を抽出することもできます。You can also filter the charts to a specific test run within an environment with the Test Run title filter.

Test trend chart
(図 99) テスト傾向グラフ(Figure 99) Test trend chart

テスト実行およびテスト結果のコメントに対するマークダウン書式設定のサポートMarkdown formatting support for Test Run and Test Result comments

マークダウン構文でのテスト実行およびテスト結果のコメントの書式設定のサポートを追加しています。We are adding support for formatting Test Run and Test Result comments with markdown syntax. この機能を使って、書式設定されたテキストまたは URL へのクイック リンクをコメントに作成できます。You can use this feature to create formatted text or quick links to URLs in your comments. [結果概要] ページの [テスト結果] コメントを [分析の更新] で更新でき、[実行の概要] ページの [テスト実行] コメントを [テスト] ハブの [コメントの更新] で更新できます。You can update Test Result comments in the Result Summary page with Update analysis and Test Run comments in the Run Summary page with Update comments in Test hub.

[ビルド] または [リリース] の概要ページ、または [テスト] ハブで、テスト結果を分析しながら、既存のバグを不合格になったテストに関連付けることができるようになりました。While analyzing the test result in the Build or Release summary page or in the Test hub, you can now associate an existing bug to a failed test. これは、バグが既に登録されている既知の理由によりテストが不合格になっている場合に便利です。This is helpful when a test is failing for a known reason that has a bug already filed.

テストの実行およびテスト結果への添付情報のアップロードUpload attachments to test runs and test results

スクリーンショットやログ ファイルなどのファイルをテストの実行またはテスト結果に追加情報として添付することができます。You can now attach files such as screenshots and log files to test runs or test results as additional information. これまで、この機能は Microsoft Test Manager (MTM) クライアントからのみ使用でき、VSTS/TFS のテスト ハブと MTM クライアント間のコンテキストを切り替える必要がありました。Up to this point, this capability was only available through the Microsoft Test Manager (MTM) client, forcing you to switch context between the Test hub in VSTS/TFS and the MTM client.

テストのバッチ処理Test batching

ビルド/リリース管理の Visual Studio テスト タスクでは、効率的な実行のためにテストをグループ化 (バッチ処理) する方法を制御するためのオプションが用意されています。In the Visual Studio test task in Build/Release management, options are available to control how tests should be grouped (batched) for efficient execution. テストは次の 2 つの方法でグループ化できます。Tests can be grouped in two ways:

  1. 実行に参加しているテストとエージェントの数に基づく方法。指定されたサイズのバッチ数になるように、テストを簡単にグループ化します。Based on the number of tests and agents participating in the run, which simply groups tests into a number of batches of a specified size.
  2. テストの過去の実行時間に基づく方法。過去の実行時間を考慮して、各バッチの実行時間がほぼ同じになるようにテストのバッチを作成します (図 100)Based on past running time of tests, which considers past running time to create batches of tests such that each batch has approximately equal running time (Figure 100). 短いテストの実行は組み合わせてバッチ処理されますが、長いテストの実行は個別のバッチに属する場合があります。Quick running tests get batched together while longer running tests may belong to a separate batch. このオプションをマルチエージェント フェーズ設定と組み合わせて、合計テスト時間を最小限に抑えることができます。This option can be combined with the multi-agent phase setting to reduce the total test time to a minimum.
Test batching
(図 100) テストのバッチ処理(Figure 100) Test batching

VSTest タスクを使用した Web テストの実行Run webtests using the VSTest task

Visual Studio テスト タスクを使用して、Web テスト (Web パフォーマンス テストとも呼ばれる) を CI/CD パイプラインで実行できるようになりました。Using the Visual Studio test task, webtests, also known as web performance tests, can now be run in the CI/CD pipeline. Web テストは、タスク アセンブリの入力に、実行するテストを指定することで実行できます。Webtests can be run by specifying the tests to run in the task assembly input. Web テストにリンクされた "関連付けられたオートメーション" を含む任意のテスト ケース作業項目は、タスクでテスト計画/テスト スイートを選択することで実行できます (図 101)Any test case work item that has an “associated automation” linked to a webtest, can also be run by selecting the test plan/test suite in the task (Figure 101).

Test selection
(図 101) テストの選択(Figure 101) Test selection

Web テストの結果は、テスト結果の添付情報として使用できるようになります (図 102)Webtest results will be available as an attachment to the test result (Figure 102). これは、Visual Studio でのオフライン分析用にダウンロードできます。This can be downloaded for offline analysis in Visual Studio.

Test summary
(図 102) テストの概要(Figure 102) Test summary

この機能は Visual Studio テスト プラットフォームの変更に左右され、ビルド/リリース エージェントに Visual Studio 2017 Update 4 がインストールされている必要があります。This capability is dependent on changes in the Visual Studio test platform and requires that Visual Studio 2017 Update 4 be installed on the build/release agent. Visual Studio の以前のバージョンを使用して Web テストを実行することはできません。Webtests cannot be run using prior versions of Visual Studio.

同様に、機能テストの実行タスクを使用して Web テストを実行することもできます。Similarly, webtests can be run using the Run Functional Test task. この機能は、テスト エージェントの変更に左右され、Visual Studio 2017 Update 5 で使用することができます。This capability is dependent on changes in the Test Agent, that will be available with the Visual Studio 2017 Update 5.

これをロード テストと組み合わせて使用する方法の例については、Load test your app in the cloud using Visual Studio and VSTS quickstart (Visual Studio および VSTS のクイック スタートを使用してクラウドでアプリのロード テストを行う) を参照してください。See the Load test your app in the cloud using Visual Studio and VSTS quickstart as an example of how you can use this together with load testing.

テスト計画とテスト スイート用のグラフ ウィジェットChart widget for test plans and test suites

以前は、テスト ハブでテスト計画およびテスト スイートのグラフを作成し、それをダッシュボードにピン留めすることができました。Previously, you could create charts for test plans and suites in Test hub and pin them to dashboard. ウィジェットを追加したことで、ダッシュボードのウィジェット カタログから、テスト計画やテスト スイートのグラフを作成できるようになりました。We have now added a widget that enables creating charts for test plans and suites from the widget catalog on the dashboard. テストの作成状態またはテストの実行状態のグラフを作成することができます。You can create charts for test authoring status or test execution status. さらに、グラフ上に表示するデータが多い場合は、ウィジェットからグラフを追加することにより、より大きなグラフを作成することができます (図 103)Moreover, adding charts from the widget allows you to create larger charts when you have more data to be shown on a chart (Figure 103).

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

手動テストのために Chrome ブラウザーを使用してデスクトップ アプリに対するスクリーンショットおよび注釈をサポートScreenshot and annotation support for desktop apps with Chrome browser for manual tests

手動テストの上位推奨候補のいずれか 1 つに対するサポートを追加します。テスト ハブの Web テスト ランナーからデスクトップ アプリケーションのスクリーン ショットをキャプチャするというものです。We are adding support for one of the top suggestions from manual testing - capturing screenshots of desktop applications from the Web Test Runner in Test hub. これまで、デスクトップ アプリのスクリーンショットをキャプチャするには、Microsoft Test Managerテスト ランナーを使用する必要がありました。Until now, you had to use Test Runner in Microsoft Test Manager to capture screenshots of desktop apps. この機能を使用するには、テストとフィードバックの拡張機能をインストールする必要があります。You need to install the Test & Feedback extension to use this functionality. Chrome ブラウザーのサポートを公開しています。その後すぐに Firefox のサポートが公開されます。We are rolling out support for the Chrome browser, and Firefox will follow shortly thereafter.

SharePoint の TFS 拡張機能の廃止 Discontinuing TFS Extension for SharePoint

TFS 2018 以降のバージョンでは、SharePoint の TFS 拡張機能はサポートされなくなります。TFS 2018 and later versions will no longer support the TFS Extension for SharePoint. さらに、TFS サーバーと SharePoint サーバーの統合を構成するための画面は、Team Foundation 管理コンソールから削除されました。Additionally, the screens used to configure integration between a TFS Server and a SharePoint server have been removed from the Team Foundation Administration Console.


SharePoint と統合するように構成された以前のバージョンから TFS 2018 にアップグレードする場合は、アップグレード後に SharePoint 統合を無効にする必要があります。そうしないと、TFS SharePoint サイトの読み込みエラーが発生します。If you are upgrading to TFS 2018 from a previous version configured to integrate with SharePoint, you will need to disable the SharePoint integration after upgrade, or your TFS SharePoint sites will fail to load.

SharePoint サーバー上で統合を無効にできるソリューションを作成しました。We have created a solution that allows you to disable integration on the SharePoint server. 詳細については、The future of our TFS/SharePoint Integration (TFS/SharePoint の統合の将来) を参照してください。For more information, please see the post on the future of our TFS/SharePoint Integration.

チーム ルームの廃止 Discontinuing Team Rooms

最新の開発チームはコラボレーションに大きく依存します。Modern development teams heavily depend on collaboration. ユーザーは、アクティビティ (通知) を監視し、それについて話し合う (チャット) ための場所を望んでいます (そして必要としています)。People want (and need) a place to monitor activity (notifications) and talk about it (chat). 数年前にこの傾向を認識し、これらのシナリオをサポートするためのチーム ルームの構築に着手しました。A few years back, we recognized this trend and set out to build the Team Room to support these scenarios. その後、多くのコラボレーション用ソリューションが市場に登場しました。Since that time, we have seen more solutions to collaborate emerge in the market. 最も顕著なのは、Slack の発展です。Most notably, the rise of Slack. さらに最近では、Microsoft Teams の発表です。And more recently, the announcement of Microsoft Teams.

TFS および Visual Studio Team Services と問題なく統合する優れたソリューションが増えたため、TFS 2018 および Visual Studio Team Services からチーム ルーム機能を削除する計画を 1 月に発表しましたWith so many good solutions available that integrate well with TFS and Visual Studio Team Services, we announced in January the plans to remove our Team Room feature from both TFS 2018 and Visual Studio Team Services.

Top of Page