Team Foundation Server 2017 Update 2 リリース ノートTeam Foundation Server 2017 Update 2 Release Notes

終更新日 2018/01/31

この記事では、Team Foundation Server 2017 Update 2 の最新リリースに関する情報を紹介します。In this article, you will find information regarding the newest release for Team Foundation Server 2017 Update 2. ボタンをクリックしてダウンロードします。Click the button to download.

Download the latest version of Team Foundation Server

その他の形式や言語については、ダウンロード サイトを参照してください。For other formats or languages, please see the download site.

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


フィードバックFeedback

皆様のご意見をお待ちしております。We’d love to hear from you! 問題は開発者コミュニティ ポータルで報告し、追跡できます。You can report a problem and track it through the Developer Community portal. ご提案がございましたら、Visual Studio Team Services 製品の更新プログラム サイトからお寄せください。Send us your suggestions through the Visual Studio Team Services Product Updates site.


リリース日: 2017 年 7 月 24 日Release Date: July 24, 2017

TFS 2017 Update 2 の更新の概要Summary of Updates in TFS 2017 Update 2

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

新機能の詳細をすべて確認できます。機能領域別に機能改善を表示してください。You can see the details of all the new features by viewing the improvements by feature area:


このリリースの新機能What's New in this Release

作業項目トラッキングの機能強化 Work Item Tracking Improvements

作業項目の種類アイコン Work item type icons

Microsoft はお客様にとって便利な製品を作ることを世界中のお客様に約束しております。We have made a global commitment to make our products fully accessible to our customers. その取り組みの一環として、キーボードの配列から視覚的なデザイン/レイアウトに至るまで、さまざまな利便性問題を見つけ、対処しています。As part of that commitment, we have been working to find and address many accessibility issues – anywhere from keyboard patterns to visual design and layout.

作業項目のトラッキングでは、これまでほぼ色だけで作業項目の種類を伝えていました。Work item tracking has relied solely on color in many experiences to convey work item type. しかしながら、色の識別が困難なお客様や弱視のお客様にとっては似たような色の区別が難しくなる場合がありました。However, this is problematic for our color blind or low vision users who may not be able to distinguish between items due to similarities in color. すべてのお客様が作業項目の種類をもっと簡単に確認できるように、作業項目の種類の視覚的言語にアイコンを導入しました。To increase the scanability of work item type for all our customers, we have introduced icons to the visual language of work item type. ユーザーは作業項目の種類をカスタマイズできます。Microsoft のアイコン ライブラリから選択してください。You can customize your work item types by choosing from a selection of our icon library.

バックログ/クエリ グリッドで種類を伝えていたカラー バーが色付きアイコンに代えられました (図 1)Color bars conveying type on the backlog and queries grids have been replaced with colored icons (Figure 1).

Wit icons in query

(図 1) クエリの色付きアイコン
Wit icons in query
(Figure 1) Colored icons in query

ボードのカードに種類アイコンが導入されました (図 2)Cards on the board now include a type icon (Figure 2).

Board with icon type

(図 2) 種類アイコンが表示されたボード
Board with icon type
(Figure 2) Board with icon type

配信計画 Delivery Plans

配信計画は、チーム間で程度に差のない可視性とチーム間調整を支援する組織ツールです。繰り返しベースの予定表で作業状態を追跡記録します。Delivery Plans is an organizational tool that helps you drive cross-team visibility and alignment by tracking work status on an iteration-based calendar. アカウントのプロジェクト全体からあらゆるチームまたはバックログ レベルを含めるように計画を調整できます。You can tailor your plan to include any team or backlog level from across projects in the account. さらに、計画に__フィールドの条件__を利用すると、ビューをさらにカスタマイズできます。また、マーカー__で重要な日付を強調表示できます。Furthermore, __Field Criteria on Plans enables you to further customize your view, while Markers highlight important dates.

配信計画のマーケットプレース ページをご覧ください。拡張の詳細を確認し、インストールできます。Check out the marketplace page for Delivery Plans to learn more and install the extension.

インターネットから切断されている TFS インスタンスを所有しているユーザーの場合、配信計画は VSTS Marketplace プレースに移動することなく、Web アクセスの [拡張機能の管理] オプションから直接使用できます。For users with a TFS instance that is disconnected from the Internet, Delivery Plans will be available directly from the Manage extensions option in web access, without navigating to the VSTS Marketplace. [拡張機能の管理] から [ローカルの拡張機能の参照] をクリックし、[配信計画] を選択して [インストール] をクリックします。From Manage extensions, click on Browse local extensions, then select Delivery Plans and click Install. 詳細については、プレインストールされた拡張機能に関するドキュメントを参照してください。See the documentation on pre installed extensions for more information.

作業項目とビルドの自動リンクAutomatic linking from work items to builds

ビルド定義にこの設定が新しく追加されたことで、作業を組み込んだビルドを、大量のビルドから手作業で検索しなくても、追跡記録できます。With this new setting in the build definition, you can track the builds that have incorporated your work without having to search through a large set of builds manually. ビルドと作業項目が正しく関連付けられると、作業項目フォームの開発セクションに自動的に表示されます。Each successful build associated with the work item automatically appears in the development section of the work item form.

この機能を有効にするには、ビルド定義の [オプション] の下にある設定を切り替えます (図 3)To enable this feature, toggle the setting under Options in your build definition (Figure 3).

WIT build linking

(図 3) WIT のビルド リンク
WIT build linking
(Figure 3) WIT build linking

古い作業項目フォームの非推奨Deprecation of old work item form

新しい作業項目フォームには概ね肯定的な意見が寄せられており、Microsoft がホストするアカウントで現在、100% 採用されています。Overall feedback for the new work item form has been positive and we now have 100% adoption on our hosted accounts. VSTS の利用者様に好評をいただいているこの機能をオンプレミスのお客様にもご利用いただきたく、古い作業項目フォームと古い拡張性モデルの非推奨を決定しました。We want on-premises customers to tap into the same value that has delighted our VSTS users and so we have made the decision to deprecate the old work item form and old extensibility model. 計画の詳細については、Microsoft アプリケーション ライフサイクル管理ページをご覧ください。Read more about our plans on the Microsoft Application Lifecycle Management page.

作業項目の検索 Work Item Search

作業項目の検索機能では、あるコレクションの全プロジェクトを対象に高速かつ柔軟に全作業項目を検索できます (図 4)Work Item Search provides fast and flexible search across all your work items over all projects in a collection (Figure 4). 作業項目の検索のフル テキスト検索エンジンを利用すれば、すべての作業項目フィールドを対象に語句を簡単に検索し、関連する作業項目を効率的に見つけることができます。You can use the Work Item Search full text search engine to easily search for terms across all work item fields and efficiently locate relevant work items. 作業項目フィールドでインライン検索フィルターを利用すると、作業項目の 1 つのリストに簡単に絞り込むことができます。Use in-line search filters, on any work item field, to quickly narrow down to a list of work items.

検索サービスを TFS で構成すると、他に何もインストールしなくても検索を開始できます。Once the Search service is configured in TFS, you can get searching without the need to install anything else. 作業項目の検索機能でできること:By using Work Item Search you can:

  • プロジェクト全体を検索する: 自分のチーム/パートナー チームのバックログで検索します。Search over all your projects: Search in your own and your partner teams' backlog. プロジェクトをまたいで全作業項目を検索する機能を利用し、組織の作業項目全体から検索します。Use cross-project searches over all the work items to search across your organization's entire work items. プロジェクトや区分パスのフィルターを利用し、検索を絞り込みます。Narrow your search by using project and area path filters.
  • 全作業項目フィールドを対象に検索する: 全作業項目フィールド (カスタム フィールドを含む) を対象に検索し、関連する作業項目を簡単に見つけます。Search across all work item fields: Quickly and easily find relevant work items by searching across all work item fields (including ere fields). 全フィールドを対象にフル テキスト検索を実行し、関連する作業項目を効率的に見つけます。Use a full text search across all fields to efficiently locate relevant work items. スニペット ビューには、一致が見つかった箇所が示されます。The snippet view indicates where matches were found.
  • 特定の領域で検索する: 作業項目フィールドにクイック インライン検索フィルターを適用すれば、数秒で作業項目の 1 つのリストに絞り込まれます。Search in specific fields: Use the quick in-line search filters, on any work item field, to narrow down to a list of work items in seconds. 候補リストのドロップダウンを利用すれば、さらに簡単に検索を実行できます。The dropdown list of suggestions helps complete your search faster. たとえば、AssignedTo:Chris WorkItemType:Bug State:Active のような検索を実行すると、Chris という名前のユーザーに割り当てられているアクティブなバグがすべて見つかります。For example, a search such as AssignedTo:Chris WorkItemType:Bug State:Active finds all active bugs assigned to a user named Chris.
  • 作業項目トラッキングとの統合の活用: 作業項目検索インターフェイスには、作業ハブでおなじみのコントロールが組み込まれています。表示、編集、コメント、共有などの操作が可能です。Take advantage of integration with work item tracking: The Work Item Search interface integrates with familiar controls in the Work hub, letting you view, edit, comment, share, and much more.

Workitem search

(図 4) 作業項目の検索
Workitem search
(Figure 4) Workitem search

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

新しくなったブランチ ポリシー構成 New branch policies configuration experience

ブランチ ポリシーの構成画面のデザインを変更し、優れた機能をいくつか新しく追加しました (図 5)We’ve redesigned the branch policies configuration experience and added some great new capabilities (Figure 5). 最も強力な機能の 1 つは、ブランチ フォルダーにポリシーを設定する機能です。One of the most powerful features is the ability to configure policies for branch folders. これは [ブランチ] ビューで設定できます。ブランチ フォルダーを選択し、コンテキスト メニューから [ブランチ ポリシー] を選択します。You can do this from the Branches view by selecting a branch folder and choosing Branch policies from the context menu.

Configure branch policies

(図 5) ブランチ ポリシーの構成
Configure branch policies
(Figure 5) Configure branch policies

これで新しいポリシー構成 UX が開きます。この画面でポリシーを設定し、ブランチ フォルダー内の全ブランチに適用できます (図 6)This will open the new policies configuration UX, where you can configure policies that apply to all of the branches in the branch folder (Figure 6).

Policies page

(図 6) ポリシー ページ
Policies page
(Figure 6) Policies page

ビルド ポリシーを使用している場合、1 つのブランチに複数のビルドを構成できるようになりました。If you’re using the build policy, you can now configure multiple builds for a single branch. 自動または手動のトリガーを指定するオプションも追加されました (図 7)There are also new options to specify an automatic or manual trigger (Figure 7). 実行に時間がかかる自動化テスト実行のようなものには手動トリガーが役立ちます。1 回実行するだけでプル要求が完了します。Manual triggers are useful for things like automated test runs that might take a long time to run, and you only really need to run once before completing the pull request. ビルド ポリシーには表示名もあります。これは、複数のビルドを構成している場合に便利です。The build policy also has a display name that is useful if you’re configuring multiple builds.

Manual build

(図 7) 手動ビルド
Manual build
(Figure 7) Manual build

手動トリガーのポリシーを構成したら、それを実行できます。プル要求の [ポリシー] セクションにある [ビルドをキューに挿入] オプションを選択してください (図 8)Once you’ve configured a manually triggered policy, you can run it by selecting the Queue build option in the Policies section for the pull request (Figure 8).

Manual build queue

(図 8) 手動ビルド キュー
Manual build queue
(Figure 8) Manual build queue

必須のレビュー担当者ポリシーのために (図 9)、ポリシーの適用時にプル要求タイムラインに追加するメモを指定する管理者向けの機能を追加しました (図 10)For required reviewer policies (Figure 9), we added the ability for administrators to specify a note that will be appended to the pull request timeline when the policy applies (Figure 10).

Required reviewer dialog

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

Required reviewer note

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

アクティブなコメントなしの新しいポリシーNew policy for no active comments

プル要求の全コメントが新しい__コメント__ ポリシーで対処されていることを確認します。Ensure that all comments in your pull requests are being addressed with the new Comments policy. このポリシーを有効にすると、アクティブなコメントは PR の完了をブロックし、全コメントの解決を強制します。With this policy enabled, active comments will block completion of the PR, forcing all comments to be resolved. レビュー担当者が、PR 作成者にコメントを残したが、プル要求は承認した場合でも、マージを希望する作成者がコメントを見逃すことがないので安心です。Reviewers that leave comments for the PR author but optimistically approve the pull request can be sure that an author that’s eager to merge won’t miss any comments.

ファイル ハブの機能強化Files hub improvements

ファイル ハブのプログラムをいくつかの面で更新し、表示機能と編集機能を改善しました。We’ve made several updates to the Files hub to improve the viewing and editing experiences.

表示に関しては、ピボットを追加しました。ピボットを利用すると、現在のフォルダーの README を表示したり (図 11)、マークダウン ファイルをプレビューしたり、ファイルを前のバージョンと比較したり (図 12)、注釈を表示したりできます。For viewing, we’ve added pivots that let you view the README in the current folder (Figure 11), preview Markdown files, compare a file to a previous version (Figure 12), and view blame.

Files viewing

(図 11) ファイルの表示
Files viewing
(Figure 11) Files viewing

Files compare

(図 12) ファイルの比較
Files compare
(Figure 12) Files compare

編集に関しては、変更をプレビューしたり、コメントを簡単に追加したり、新しいブランチにコミットしたり、作業項目をリンクしたりできるようになりました (図 13)For editing, you can now preview your changes, easily add a comment, commit to a new branch, and link work items (Figure 13).

Files editing

(図 13) ファイルの編集
Files editing
(Figure 13) Files editing

Git リポジトリを視覚化する Visualize your git repository

リポジトリやファイルのコミット履歴を表示しながらグラフを表示できるようになりました。You can now see a graph while showing commit history for repositories or files. この機能により、Git グラフを利用し、Git リポジトリのすべてのブランチやコミットの関係を頭で簡単に理解できます (図 14)This allows you to easily create a mental model of all your branches and commits for your git repositories using git graph (Figure 14). このグラフでは、すべてのコミットが位相幾何学的に表示されます。The graph shows all your commits in topological order.

Git graph

(図 14) Git グラフ
Git graph
(Figure 14) Git graph

Git グラフの主要要素 (図 15):The key elements of the git graph include (Figure 15):

  1. Git グラフは右揃えです。そのため、既定のブランチや選択したブランチに関連付けられているコミットは右に表示され、グラフの残りの部分は左に表示されます。the git graph is right-aligned, so commits associated with the default branch or the selected branch appear on the right while the rest of the graph grows on the left.
  2. マージ コミットは、最初の親と 2 番目の親につながれた灰色の点で表されます。merge commits are represented by grey dots connected to their first parent and second parent.
  3. 通常のコミットは青色の点で表されます。normal commits are represented by blue dots.
  4. コミットの親コミットが次の 50 コミットでビュー ポートに表示されない場合、コミット接続が実行されます。if the parent commit of a commit is not visible in the view port on the next 50 commits, then we excise the commit connection. 矢印をクリックすると、コミットがその親コミットに接続されます。Once you click the arrow, the commit is connected to its parent commit.

Git graph elements

(図 15) Git グラフの要素
Git graph elements
(Figure 15) Git graph elements

コミットの Git タグを見る View git tags on commits

チームが Git タグを利用し、リポジトリの履歴に特定の点を付けている場合、作成したタグがコミットに表示されます。If your team has been using Git tags to mark a specific point in the history of your repository, then your commits will now show the tags that you have created. コミット リスト ビューと__詳細__ページで特定のコミットのタグを表示できます (図 16)You will be able view tags (Figure 16) for a specific commit in the commit list view and the details page.

Show tags

(図 16) タグの表示
Show tags
(Figure 16) Show tags

コミットにタグを追加するAdd tags to commits

コマンド ラインからタグを作成し、リポジトリにタグをプッシュする代わりに、コミットに移動し、タグを追加できるようになりました (図 17)Instead of creating tags from the command line and pushing the tags to the repository, you can now simply go to a commit and add a tag (Figure 17). タグの作成ダイアログでは、リポジトリに他の参照をタグ付けすることもできます。The tag creation dialog will also let you tag any other ref on the repo.

Create tag details

(図 17) タグの詳細の作成
Create tag details
(Figure 17) Create tag details

コミット リスト ビューにはコンテキスト メニューもあります (図 18)The commit list view also supports a context menu (Figure 18). コミット詳細__ページに移動してタグや新しいブランチを作成する必要がありません (図 19)No need to go to the __commit details page to create tags and create new branches (Figure 19).

Create tag history

(図 18) タグの履歴の作成
Create tag history
(Figure 18) Create tag history

Tag branch

(図 19) タグのブランチ
Tag branch
(Figure 19) Tag branch

変更セット ページとシェルブセット ページの更新Updated changeset and shelveset pages

TFVC の変更セット ページとシェルブセット ページを現代風に変更しました。We have modernized the changeset and shelveset pages in TFVC. いずれのページも、補助技術を利用するユーザーのために、さらに便利になっています。Both pages are made more accessible for those of you who use assistive technologies. 新しいページには、変更セットの表題と、作成者など、変更セットに関する情報を含む新しいヘッダーも追加されました (図 20)The new pages also have a new header that contains the changeset title and associated information about the changeset, such as author details (Figure 20).

Changeset page

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

変更セット ページとシェルブセット ページのいずれにも、新しいマークダウン ディスカッション コントロールが追加されました (図 21)。マークダウンにコメントを入力したり、ユーザーを @mention したり、# を利用して作業項目を関連付けたり、ファイルや画像を簡単に添付したりできます。Both changeset and shelveset pages also host the a new markdown discussion control (Figure 21) that will allow to type comments in markdown, @mention users, associate work items using #, and easily attach files and images.

Changeset discussion

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

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

高度なフィルター処理オプションを利用し、コミット履歴結果をフィルター処理できるようになりました (図 22)You can now filter the commit history results (Figure 22) by advanced filtering options. コミットのフィルター処理基準:You can filter commits by:

  • すべての履歴full history.
  • すべての履歴と簡略化されたマージfull history with simplified merges.
  • 最初の親first parent.
  • 簡易履歴 (既定のフィルター処理設定)simple history (this is the default filter setting).

Improved commit filtering

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

TFVC から Git にリポジトリをインポートするImport repositories from TFVC to Git

同じアカウントで TFVC リポジトリから Git リポジトリにコードを移行できます。You can migrate code from your TFVC repositories to Git repositories in the same account. 移行を開始するには、リポジトリの選択ドロップダウンから [リポジトリのインポート] を選択します (図 23)To start migration, select import repository from the repository selector drop-down (Figure 23).

Repository selector drop-down

(図 23) リポジトリの選択ドロップダウン
Repository selector drop-down
(Figure 23) Repository selector drop-down

個々のフォルダーまたはブランチを Git リポジトリにインポートできます。あるいは TFVC リポジトリ全体 (ブランチを除く) をインポートできます (図 24)Individual folders or branches can be imported to the Git repository, or the entire TFVC repository can be imported (minus the branches) (Figure 24). また、最大 180 日間の履歴をインポートできます。You can also import up to 180 days of history.

Import repo complete

(図 24) リポジトリ インポート完了
Import repo complete
(Figure 24) Import repo complete

Git LFS ファイル ロックGit LFS file locking

Git LFS ファイル ロック機能を追加しました。We have added the Git LFS file locking feature. この機能により、チームで大きな比較できないファイルを扱うとき、2 人以上で同じファイルを同時に編集しようとしても作業が失われることがありません。This allows teams working with large, undiffable files to avoid losing work when two or more people attempt to edit the same file at once. ファイルの編集を始めるには先にロックし、サーバーに通知する必要があります。Before anyone can begin editing the file, they take a lock, which notifies the server. 他のユーザーがロックを試行するとサーバーに拒否されるので、そのファイルで既に作業している人がいることを理解できます。When anyone else attempts to take a lock, the server rejects the request, letting the second person know that someone else is already working on that file. この機能を利用する場合、Git LFS 2.1 以降にアップグレードしてください。Please upgrade to Git LFS 2.1 or higher to use this feature.

Git コミット コメントで新しいディスカッション コントロールを使用Git commit comments use the new discussion control

Git コミットに残される軽いコメントで新しいディスカッション コントロールが使用されるようになりました。Lightweight comments left on Git commits has been updated to use the new discussion control. これでこのようなコメントがマークダウン対応になり、Git と TFVC の両方について、Web でのあらゆるコード コメント機能が完全なものになり、最先端の操作性が与えられます。This brings support for Markdown in those comments, and rounds out all of the code-commenting features in the web for both Git and TFVC to use the latest experience.

新しいツリー ビュー コントロールNew tree view control

プル要求ファイル ビュー、Git コミット詳細、Git プッシュ詳細、TFVC シェルブセット詳細、TFVC 変更セット詳細、TFVC 変更セット ハブ、Git 履歴ハブに新しいツリー ビュー コントロールが追加されました (図 25)The Pull Request Files view, Git commit details, Git push details, TFVC Shelveset details, TFVC Changeset details, TFVC Changesets hub and Git history hub have been updated with a new tree view control (Figure 25). ツリー ビューはいくつかの面で改善され、使いやすくなりました。The tree view has a few usability improvements. まず、空のフォルダー ノードを自動的に圧縮する圧縮ツリー ビューを表示するようにビューを変更しました。可能な限りたくさんのファイルが表示されます。First, we’ve changed the view to show a condensed tree view that automatically collapses empty folder nodes, maximizing the number of files that are in view.

また、コメントがもっと簡潔に、スペースに無駄なく表示されるようになりました。The tree also shows comments in a more compact way. コメント付きのファイルの場合、コメント スレッドごとに子項目が表示されます。そのスレッドを作成したユーザーのアバターが表示されます。Files with comments show a child item for each comment thread, with the avatar indicating the user that created the thread. 新しいコメント スレッドと返信のあるコメント スレッドには青い点が付きます。また、返信数が表示されます。New comment threads and those with replies are indicated by the blue dot, and the count of replies is summarized with a count.

New tree view

(図 25) 新しいツリー ビュー
New tree view
(Figure 25) New tree view

プル要求の機能強化 Pull Request Improvements

PR の作成者とレビュー担当者の操作呼び出しの改善Improved CTAs for PR author and reviewers

チームでブランチ ポリシーを利用する場合、プル要求を表示するとき、厳密にどのようなアクションが必要になるのか、判断が難しい場合があります。For teams using branch policies, it can sometimes be hard to know exactly what action is required when you view a pull request. 主要な操作呼び出し (Call To Action, CTA) が [完了] ボタンの場合、完了準備ができているということなのでしょうか。If the main call to action is the Complete button, does that mean it’s ready to complete? PR ビューでは、ページを閲覧している人に関する情報、設定されているブランチ ポリシーに関する情報を利用し、そのユーザーに最も道理にかなう操作呼び出しが表示されるようになりました。Using information about the person viewing the page and the state of configured branch policies, the PR view will now present the call to action that makes the most sense for that user.

ポリシーが設定されているがまだ承認されていないとき、[完了] ボタンを押すと (図 26)オートコンプリート__機能の使用が奨励されるようになりました。When policies are configured, but aren’t yet passing, the __Complete button (Figure 26) will now encourage the use of the Auto-complete feature. ポリシーがブロックされている場合、PR を完了できることはおそらくないでしょう。そのため、ポリシーがやがて承認されたときに PR を完了するオプションが与えられています。It’s not likely that you’ll be able to complete the PR successfully if policies are blocking, so we offer an option that will complete the PR when those policies eventually pass.

 Auto-complete feature

(図 26) オートコンプリート機能
 Auto-complete feature
(Figure 26) Auto-complete feature

レビュー担当者に関しては、PR の完了より承認を望むことが多いでしょう。そのため、承認していない場合、主要な CTA として [承認] ボタンがレビュー担当者に表示されます (図 27)For reviewers, it’s more likely that you’ll want to approve a PR than complete it, so reviewers will see the Approve button (Figure 27) highlighted as the main CTA if you haven’t approved yet.

CTA approve

(図 27) CTA 承認
CTA approve
(Figure 27) CTA approve

承認後、レビュー担当者が PR を完了する役割も担う場合、[完了] (または [オートコンプリート]) ボタンが CTA としてレビュー担当者に強調表示されます。Once approved, reviewers will see the Complete (or Auto-complete) button highlighted as the CTA for those cases where a reviewer is also the person completing the PR.

コメントに基づく措置Actionable comments

PR に相当な数のコメントが付いている場合、すべての会話を追跡記録することは難しくなります。In a PR with more than a few comments, it can be hard to keep track of all of the conversations. コメントを効率的に管理するために、さまざまな拡張機能で対処していた項目の解決プロセスを簡略化しました。To help you better manage comments, we’ve simplified the process of resolving items that have been addressed with a number of enhancements:

  • すべての PR のヘッダーに、解決されたコメントの数が表示されるようになりました (図 28)In the header for every PR, you’ll now see a count of the comments that have been resolved (Figure 28).

PR header

(図 28) PR ヘッダー
PR header
(Figure 28) PR header

  • 対処済みのコメントは 1 回のクリックで解決できます (図 29)When a comment has been addressed, you can resolve it with a single click (Figure 29).

Resolve button

(図 29) 解決ボタン
Resolve button
(Figure 29) Resolve button

  • 解決中にコメントを追加する場合、1 回のクリックで返信し、解決できます (図 30).If you have comments to add while you’re resolving, you can reply and resolve in a single gesture (Figure 30).

Reply and resolve

(図 30) 返信して解決
Reply and resolve
(Figure 30) Reply and resolve

  • 全部対処されるまで、コメントが解決されるたびに数が増えます (図 31)As comments are resolved, you’ll see the count go up until everything has been addressed (Figure 31).

Comment count address rate

(図 31) コメント数解決レート
Comment count address rate
(Figure 31) Comment count address rate

  • 概要のフィルターが機能強化されました。コメントのさまざまな状態別にフィルター処理したり、フィルター オプションごとにコメント数を表示したりできます (図 32)The filter in the Overview has been improved to enable filtering by various comment states and to show the count of comments for each filter option (Figure 32).

Filter improvements

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

更新ビューのリベースと強制プッシュUpdates view shows rebase and force push

[プル要求の詳細] ビューの [更新] タブが改善され、強制プッシュの発生時やベース コミットの変更時に情報を表示するようになりました (図 33)In the Pull Request details view, the Updates tab has been improved to show when a force push has occurred and if the base commit has changed (Figure 33). この 2 つの機能は、PR の完了前にトピック ブランチでリベースが変更された場合、本当に便利です。These two features are really useful if you rebase changes in your topic branches before completing your PRs. レビュー担当者は情報が十分に与えられ、現状を正確に理解できます。Reviewers will now have enough info to know exactly what’s happened.

Updates views

(図 33) 更新ビュー
Updates views
(Figure 33) Updates views

プル要求をユーザー別にフィルタリングPull request filtering by people

プル要求が見つけやすくなりました。It’s now easier to find pull requests! 新しいフィルター処理オプションが追加され、特定の作成者により作成された PR や特定のレビュー担当者に割り当てられた PR を見つけることができます (図 34)We’ve added new filtering options to allow you to find PRs created by a specific author or assigned to a specific reviewer (Figure 34). 作成者またはレビュー担当者フィルターからユーザーを選択すると、一覧が更新され、フィルターに一致する PR だけが表示されます。Simply select a user from the author or reviewer filter, and the list will be updated to show only the PRs that match the filter.

Filtering by people

(図 34) ユーザーでのフィルター処理
Filtering by people
(Figure 34) Filtering by people

プル要求ポリシーの回避時の理由が必須Reason required when bypassing pull request policies

プル要求ポリシーを回避するとき、理由を指定する必要があります。When you are bypassing a pull request policies, you are required to specify a reason. 回避を選択すると、[プル要求の完了] ダイアログに [理由] フィールドが表示されます (図 35)In the Complete pull request dialog, you will see a new Reason field, if they choose to bypass (Figure 35).

Bypass dialog

(図 35) 回避ダイアログ
Bypass dialog
(Figure 35) Bypass dialog

理由を入力し、プル要求を完了とすると、[概要] にメッセージが表示されます (図 36)After entering the reason and completing the pull request, the message will be displayed in the Overview (Figure 36).

Bypass message

(図 36) 回避メッセージ
Bypass message
(Figure 36) Bypass message

プル要求をチームと共有Share pull requests with teams

プル要求を共有する__という行為はレビュー担当者に通知する方法として便利です (図 37)The __Share Pull Request action is a handy way to notify reviewers (Figure 37). 今回のリリースでは、チームとグループのためのサポートが追加されました。1 回の手順で関係者全員にプル要求を通知できます。In this release, we’ve added support for teams and groups, so you can notify everyone involved the pull request in a single step.

Share PR with teams

(図 37) チームとの PR の共有
Share PR with teams
(Figure 37) Share PR with teams

チームのためのプル要求の機能強化Pull request improvements for teams

複数のチームに属している場合、すべてのチームに割り当てられているすべての PR が [自分のプル要求] ビューに一覧表示されます (図 38)If you’re a member of multiple teams, you will now see all of the PRs assigned to those teams listed in the My Pull Requests view (Figure 38). つまり、[自分のプル要求] ビューだけで、自分に与えられたすべての PR を確認できます。This makes the My Pull Requests view the one stop you need to visit to see all the PRs on your plate.

PR improvements for teams

(図 38) チームのための PR 機能強化
PR improvements for teams
(Figure 38) PR improvements for teams

今後のリリースでは、プル要求__ハブの [コード] にチームを追加し、1 つのプロジェクトで与えられているすべての PR を簡単に表示できるようにする予定です。In a future release, we’ll add teams to the __Pull Requests hub under Code to make it easier to see all of your PRs for a single project.

プル要求コメントの既定の通知Default notifications for pull request comments

コメント通知が新しくなり、PR に常に最新の会話が表示されるようになりました (図 39)Stay up to date with the conversations happening in your PRs with the new comment notifications (Figure 39). 自分が作成した PR については、あるユーザーが新しいコメント スレッドを追加したり、既存のスレッドに返信を追加したりしたとき、自動的に通知が届きます。For PRs that you've created, you will automatically be notified any time a user adds a new comment thread or replies to an existing thread. 他のユーザーの PR にコメントすると (コメント スレッドを作成したり、コメント スレッドに返信したりすると)、その後返信があったときに通知が届きます。When you comment on another user's PR, you'll be notified about any future replies to comment threads that you create or reply to.

Default PR notifications

(図 39) 既定の PR 通知
Default PR notifications
(Figure 39) Default PR notifications

このような通知機能は、難しい設定の要らないサブスクリプションに含まれています。[通知] 設定ページで変更できます。These notifications are available as part of the out of the box subscriptions, and are configurable on the Notifications settings page.

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

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

パッケージ管理を更新した結果、操作がさらに簡単になりました。ユーザーから報告があった問題に対処しています。また、今後予定されているパッケージ ライフサイクル機能のための場所が用意されました (図 40)We've updated the Package Management user experience to make it faster, address common user-reported issues, and make room for upcoming package lifecycle features (Figure 40). 更新の詳細については、Updated experience (新しくなった操作性) ページを参照してください。Learn more about the update on the Updated experience page.

Package Management

(図 40) パッケージの管理
Package Management
(Figure 40) Package Management

パッケージ管理に npm README とダウンロード ボタンを追加Package Management adds npm READMEs and download button

パッケージに README.md を含む npm パッケージの README が表示されるようになりました (図 41)You can now see the README of any npm package that includes a README.md in the package (Figure 41). README は、パッケージに関する知識をチームが記録し、共有する際に役立ちます。READMEs can help your team document and share knowledge about your packages.

コマンド バーの [ダウンロード] ボタンで npm パッケージをダウンロードすることもできます。You can also download any npm package using the Download button in the command bar.

Package Management npm README

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

NuGet 復元および NuGet コマンド ビルド タスクNuGet Restore and NuGet Command build tasks

NuGet インストーラー (NuGet 復元__に名称変更) タスクが大幅に変更されました。また、新しい NuGet タスクが追加されました。__NuGet コマンド__です。We’ve made major updates to the __NuGet Installer (now called NuGet Restore) task, and added a new NuGet task: NuGet Command. 最も注目に値するところでは、NuGet コマンド タスクと NuGet 復元__タスクで nuget.exe 4.0.0 が既定で使用されるようになりました。Most notably, the __NuGet Command and NuGet Restore tasks now use nuget.exe 4.0.0 by default.

NuGet 復元__は、Visual Studio ビルド手順の前にパッケージを復元するという最も一般的なシナリオに合わせて最適化されました。__NuGet Restore is now optimized for the most common scenario of restoring packages before a Visual Studio Build step. 1 つの NuGet フィードを共有する小規模プロジェクトのサポートも改善されました。チーム サービス フィードを選択し、自動生成された NuGet.Config に追加できるようになりました。It also has better support for small projects that share a single NuGet feed: you can now pick a Team Services feed and have it added to an auto-generated NuGet.Config.

より複雑な NuGet 操作のために、NuGet コマンド タスクであらゆるコマンドや引数セットを指定できるようになりました (図 42)For more complex NuGet operations, the NuGet Command task provides the flexibility to specify any command and set of arguments (Figure 42).

NuGet command

(図 42) NuGet コマンド
NuGet command
(Figure 42) NuGet command

ビルドとリリースの機能強化 Build and Release Improvements

新しいビルド定義エディター New build definition editor

ビルド定義エディターのデザインを変更しました。さらに直観的な操作が可能になり、いくつかの弱点が修正され、新しい機能が追加されました。We’ve redesigned our build definition editor to provide a more intuitive experience, fix some pain points, and add new capabilities. テンプレートの使用、タスクの追加、設定の変更が簡単になったと考えております。We hope that you’ll find it easier to use templates, add tasks, and change settings. また、プロセス パラメーターを使用できるようになりました。最も重要なデータを簡単に指定できるようになりました。タスク内をあちこち閲覧する必要がありません。And now you can use process parameters to make it easier to specify the most important bits of data without having to go deep into your tasks.

テンプレートの検索Search for a templates

必要なテンプレートを探して適用するか、空のプロセスから始めます (図 43)Search for the template you want and then apply it, or start with an empty process (Figure 43).

Build template search

(図 43) ビルド テンプレートの検索
Build template search
(Figure 43) Build template search

タスクを簡単に見つけ、必要な場所に追加するQuickly find and add a task right where you want it

使用するタスクを検索します。見つかったら、左側で現在選択されているタスクの後に追加できます。あるいは、必要な場所までドラッグし、ドロップします (図 44)Search for the task you want to use, and then after you’ve found it, you can add it after the currently selected task on the left side, or drag and drop it where you want it to go (Figure 44).

Build task search

(図 44) ビルド タスクの検索
Build task search
(Figure 44) Build task search

タスクはドラッグ アンド ドロップで移動することもできます。あるいは、Ctrl キーを押しながらドラッグ アンド ドロップすると、タスクをコピーできます。You can also drag and drop a task to move it, or drag and drop while holding the Ctrl key to copy the task.

プロセス パラメーターを利用し、主要な引数をタスクに渡すUse process parameters to pass key arguments to your tasks

ビルド定義やテンプレートを利用する場合、プロセス パラメーター (図 45) を利用すれば、最も重要なデータを簡単に指定できます。タスク内をあちこち閲覧する必要がありません。You can now use process parameters (Figure 45 to make it easier for those who use your build definition or template to specify the most important bits of data without having to go deep into your tasks.

Process parameters

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

一部の組み込みテンプレート (Visual StudioMaven など) から新しいビルドを作成する場合、そのしくみを示す例を参照できます。If you create a new build from some of the built-in templates (for example Visual Studio and Maven) you can see examples of how these work.

新しいエディターは他の面でもいくつか機能強化されています。たとえば、ソース設定を簡単に表示できるようになりました。The new editor includes a few other enhancements, such as giving you quicker access to your sources settings.

新しいエディターで最初のビルド定義を作成するためのチュートリアルが必要な場合、初心者のための CI/CD ページをご覧ください。For a walkthrough of creating your first build definition using the new editor, see CI/CD for newbies.

詳細については、2017 ユーザー エクスペリエンス ページをご覧ください。Learn more on the 2017 user experience page.

複数バージョンの拡張機能タスクMultiple versions of Extension tasks

拡張機能の作成者は、特定のタスクについて複数バージョンの拡張機能を作成できるようになり、運用環境にあるメジャー バージョンごとに修正プログラムを出荷できます。Extension authors can now create extensions with multiple versions of a given task, which enables them to ship patches for each major version they have in production.

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

条件付きビルド タスク Conditional build tasks

整理整頓作業や異常時のメッセージ送信などのビルド タスクをさらに制御するために、4 つの選択肢が組み込まれました (図 46)。タスクの実行タイミングを制御できます。If you’re looking for more control over your build tasks, such as a task to clean things up or send a message when something goes wrong, we’re now offering four built-in choices for you to control when a task is run (Figure 46).

Conditional build tasks

(図 46) 条件付きビルド タスク
Conditional build tasks
(Figure 46) Conditional build tasks

特定のブランチの場合にのみタスクを実行するなど、特定のトリガーでさらに細かく操作するために、カスタム条件を作成できます。If you are looking for more flexibility, such as a task to run only for certain branches, with certain triggers, under certain conditions, you can express your own custom conditions:

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

タスクを実行する条件の指定方法に関するページをご覧ください。See Specify conditions for running a task page.

コンテナー ベースのアプリケーションを構築し、デプロイするための組み込みタスクBuilt-in tasks for building and deploying container based applications

今回のリリースでは、Docker 拡張のほとんどのタスクが改善され、既定でこの製品に入りました。新しいタスクとテンプレートが導入され、一連のコンテナー シナリオの実現が簡単になりました。With this release we have pulled most of the tasks in our Docker extension into the product by default, improved them, and introduced a set of new tasks and templates for making a set of container scenarios easier.

  • Docker: Docker イメージを構築、プッシュ、実行するか、Docker コマンドを実行します。Docker: Build, push, or run Docker images, or run a Docker command. このタスクは Docker または Azure コンテナー レジストリで利用できます。This task can be used with Docker or Azure Container registry. ACR による組み込みのサービス プリンシパル認証を利用できるようになり、さらに使いやすくなりました。You can now use our built-in service principal authentication with ACR to make it even easier to use.
  • Docker-Compose: マルチコンテナー Docker アプリケーションを構築、プッシュ、実行します。Docker-Compose: Build, push, or run multi-container Docker applications. このタスクは Docker または Azure コンテナー レジストリで利用できます。This task can be used with Docker or Azure Container registry.
  • Kubernetes: kubectl コマンドを実行することで、Azure Container Service の Kubernetes クラスターをデプロイ、構成、更新します。Kubernetes: Deploy, configure, or update your Kubernetes cluster in Azure Container Service by running kubectl commands.
  • Service Fabric: Service Fabric クラスターにコンテナーをデプロイします。Service Fabric: Deploy containers to a Service Fabric Cluster. Service Fabric は現在、クラウドで Windows コンテナーを実行するために最適な選択肢です。Service Fabric is the best choice today for running Windows Containers in the cloud.

Azure Web App デプロイ更新Azure Web App deployment updates

Azure Web App のさまざまな機能を強化しました。We have made many enhancements for Azure Web Applications:

  • Azure App Service デプロイ タスクでは、Java WAR ファイル、Node.js、Python、PHP アプリケーションをデプロイできます。Azure App Service deployment task supports Java WAR files, Node.js, Python, and PHP applications to be deployed.
  • Azure App Service デプロイ タスクでは、コンテナーを利用し、Azure Web App for Linux にデプロイできます。Azure App Service deployment task supports deploying to Azure Web App for Linux using containers.
  • Azure Portal の継続的配信機能が強化され、ノード アプリケーション対応になりました。Azure portal Continuous Delivery is expanded now support Node applications.
  • Azure App Service 管理タスクが、Azure App Service の開始、停止、再開、スロット スワップに追加されました。Azure App Service manage task is added to Start, Stop, Restart or Slot swap for an Azure App Service. また、サイト拡張をインストールし、必須の PHP または Python バージョンを有効にしたり、IIS Manager または Application Insights をインストールしたりできるようになりました。It also supports installing site extensions to enable installation of the required PHP or Python version or installing IIS Manager or Application Insights.

また、CI/CD を構成するための CI/CD サポートを最新版の Azure CLI に導入しました。We have also introduced CI/CD support into the latest version of the Azure CLI for configuring CI/CD. 次に例を示します。Here is an example:

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

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

最新の更新プログラムでは、project.json に加え、*.csproj ファイルをサポートするように .NET コア タスクを機能強化しています。With the current update, we are enhancing .NET core tasks to support *.csproj files in addition to project.json. ビルド エージェントで Visual Studio 2017 を使用し、csproj ファイルで .NET コア アプリケーションを開発できるようになりました。You can now use Visual Studio 2017 on your build agents to build .NET core applications using csproj files.

SSH デプロイ機能強化SSH deployment improvements

SSH によるファイルのコピー ビルド/リリース タスクで、宛先パスにチルダ (~) を使用できるようになりました。リモート ユーザーのホーム ディレクトリにファイルをコピーする作業が簡単になりました。The Copy Files Over SSH build/release task now supports tildes(~) in the destination path to simplify copying files to a remote user’s home directory. また、コピーするファイルが見つからないときにビルド/リリースを実行しないオプションが追加されました。Also, a new option allows causing the build/release to fail when no files are found to copy.

SSH ビルド/リリース タスクの利用時、リモートの Linux または macOS コンピューターで Windows 行末のスクリプトを実行できるようになりました。The SSH build/release task now supports running scripts with Windows line endings on remote Linux or macOS machines.

ビルドまたはリリース中に SSH キーをインストールするInstall an SSH key during a build or release

SSH キーのインストール (プレビュー) という新しいプレビュー タスクでは、ビルドまたはリリースの前に SSH キーがインストールされ、ビルドまたはリリースの完了時にエージェントから削除されます。A new preview task, Install SSH Key (Preview), installs an SSH key prior to a build or release and removes it from the agent when the build or release completes. インストールしたキーは、Git リポジトリまたはサブモジュールからコードを取得するとき、デプロイ スクリプトを実行するとき、SSH 認証を必要とするその他の操作を実行するときに使用できます。The installed key can be used for fetching code from a Git repository or submodules, running deployment scripts, or other activities that require SSH authentication. 今後、パスフレーズやその他の機能に対応するように改善される予定です。It will be improved in the future to support passphrases and other capabilities.

Visual Studio 2017 が指定されているがエージェントにない場合、タスクが失敗するTasks fail if Visual Studio 2017 is specified but not present on agent

Visual Studio ビルド タスクと MSBuild タスクでは、特定のバージョンの Visual Studio を選択できます。The Visual Studio Build and MSBuild tasks enable you to select a specific version of Visual Studio. 今までは、Visual Studio 2017 バージョンを利用できない場合、次に利用できるバージョンが自動的に選択されていました。Until now, if the Visual Studio 2017 version was not available, these tasks would automatically pick the next available version.

この動作を変更しています。We’re changing this behavior. Visual Studio 2017 を選択したがエージェントにない場合、ビルドは失敗します。Now the build will fail if you select Visual Studio 2017 but it is not present on the agent.

この変更を行った理由:We made this change for the following reasons:

  • .NET Core のような新しい種類のアプリは以前のビルド ツールでコンパイルされません。Newer app types such as .NET Core do not compile with older build tools. Visual Studio 2017 以降を必要とします。They explicitly require Visual Studio 2017 or newer.

  • まったく同じバージョンの Visual Studio を使用したときに、一貫性と予測可能性に優れた結果が得られます。You get more consistent and predictable results when you use the same exact version of Visual Studio.

  • ビルド タスクがフォール バックすると、解釈が難しいコンパイル エラーが発生することがあります。Whenever build tasks fall back, you may get compilation errors that are difficult to understand.

ヒント

以前のバージョンの Visual Studio しかないエージェントではなく、Visual Studio 2017 があるエージェントを含むプールと接続されているキューを必ず使用してください。Make sure to use a queue connected with a pool that has agents with Visual Studio 2017, and no agents that have only earlier versions of Visual Studio.

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

古くなった作業ディレクトリやリポジトリを定期的にクリーンアップするようにエージェント プールを構成できるようになりました (図 47)You can now configure an agent pool to periodically clean up stale working directories and repositories (Figure 47). たとえば、プールでは、ビルドやリリースの定義が削除された後に残されたワークスペースが削除されます。For example, the pool will delete workspaces left behind by deleted build and release definitions.

Agent maintenance

(図 47) エージェント メンテナンス
Agent maintenance
(Figure 47) Agent maintenance

このオプションを利用すると、プライベートのビルドまたはリリース エージェントがディスク領域不足になる可能性が減ります。Using this option should reduce the potential for your private build and release agents to run out of disk space. この保守管理は (コンピューター単位ではなく) エージェント単位で行われます。そのため、1 台のコンピューターに複数のエージェントがある場合、ディスク領域問題に遭遇する可能性があります。The maintenance is done per agent (not per machine), so if you have multiple agents on a single machine you could still run into disk space issues.

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

エージェントがアップグレードされるとき、キューとプールの管理ポータルにアップグレードの状態が表示されるようになりました。When an agent is being upgraded, it now indicates the status of the upgrade in the queue and pool management portal.

使用されていないコンピューターでプライベート エージェントを選択するSelection of private agents on machines not in use

ビルドまたはリリースをプライベート エージェントに割り当てるとき、コンピューター名が決定要素として使用されるようになりました。The system now uses machine name as a factor when allocating a build or a release to a private agent. 結果的に、ジョブを割り当てるとき、ビジー状態のコンピューターのエージェントより、アイドル状態のコンピューターのエージェントが優先されます。As a result, the system will prefer an agent on an idle machine over an agent on a busy machine when it allocates the job.

パイプライン キューPipelines queue

エージェント ベースの価格モデルから、パイプライン ベースの価格モデルに移行しました。We have now moved from the agent-based pricing model to pipeline-based pricing model. この新しいモデルでは、ユーザーは自分のアカウントで構成されているパイプラインの数と同じ数のビルドまたはリリースを同時に実行できます。In this new model, users can run as many builds or releases concurrently as the number of pipelines configured in their account. この制限を超えて追加したビルドおよびリリースは、キューに入れられて、前のビルドおよびリリースが完了するのを待機します。Additional builds and releases beyond this limit are queued and wait for earlier builds and releases to complete. パイプライン キュー__機能は、ビルドまたはリリースの現在の状態に関する詳しい情報をユーザーに提供します。The __Pipelines queue feature provides users with more visibility into where their builds or releases are.

パイプライン キュー__の起動時には、次の情報を確認できます。On launching the __Pipelines queue, you can see the following information:

  1. パイプラインによる実行を待っているビルドおよびリリースと、待機キュー内でのそれぞれの位置。Builds and releases waiting for a pipeline to execute and their position in the waiting queue.
  2. 使用可能なパイプラインを使って現在実行されているビルドおよびリリース。Builds and releases currently running using available pipelines.

ビルド/リリースがパイプラインを待機している間に、ビルド/リリース ログ ページ内からこのビューを直接起動し、パイプライン キュー内での現在位置や他の詳細を検索することもできます。While your build/release is waiting for a pipeline, you can also directly launch this view from inside the build/release logs page and find its current position in the pipeline queue and other details.

ビルドの概要でのリリース アクションRelease action in Build summary

[リリース] アクションを [ビルド] 概要アクション バーで使用できるようになり、ビルドのリリースを簡単に作成できます。We are now supporting a Release action, available in the Build summary action bar, so it is easy for you to create a release for a build.

変数グループのセキュリティSecurity for variable groups

変数グループのセキュリティを、作成者__や__管理者__などの一連のロールで管理できるようになりました。Security for variable groups is now governed through a set of roles such as __Creator and Administrator.

既定では、次のロールが割り当てられます。By default, the below roles are assigned.

  • 共同作成者に対しては作成者ロールCreator role to Contributors
  • プロジェクト コレクション管理者、プロジェクト管理者、ビルド管理者、リリース管理者に対しては管理者ロールAdministrator role to Project Collection Administrators, Project Administrators, Build Administrators, and Release Administrators
  • 有効なプロジェクト ユーザーに対しては閲覧者ロールReader role to Valid Project Users

すべての変数グループまたは特定の変数グループについて、既定の設定を上書きできます。The defaults can be overridden for all variable groups or for a specific one.

iOS DevOps の機能強化iOS DevOps enhancements

Apple App Store 拡張は 2 段階認証 (2 要素認証) 対応になりました。また、ビルドを外部テスターに公開できるようになりました (図 48)The Apple App Store extension now supports two-step verification (two-factor authentication) and releasing builds to external testers (Figure 48).

Apple App Store connection

(図 48) Apple App Store の接続
Apple App Store connection
(Figure 48) Apple App Store connection

Apple 証明書のインストール (プレビュー) は、後続の Xcode または Xamarin.iOS ビルドで使用するために、エージェントに P12 署名証明書をインストールする新しいビルド タスクです。Install Apple Certificate (Preview) is a new build task that installs a P12 signing certificate on the agent for use by a subsequent Xcode or Xamarin.iOS build.

Apple プロファイルのインストール (プレビュー) は、後続の Xcode または Xamarin.iOS ビルドで使用するために、エージェントにプロビジョニング プロファイルをインストールする新しいビルド タスクです。Install Apple Profile (Preview) is a new build task for installing provisioning profiles on the agent for use by a subsequent Xcode or Xamarin.iOS build.

MSBuild、Xamarin.Android、Xamarin.iOS ビルド タスクでは、Visual Studio for Mac ツール セットでビルドできるようになりました。MSBuild, Xamarin.Android, and Xamarin.iOS build tasks now support building with the Visual Studio for Mac tool set.

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

コード カバレッジ結果の発行__ビルド タスクでは、ビルドの一環として Cobertura または JaCoCo のコード カバレッジが報告されます。The __Publish Code Coverage Results build task reports Cobertura or JaCoCo code coverage as part of a build. [概要ファイル] フィールドと [レポート ディレクトリ] フィールドにワイルドカードや minimatch パターンを指定できるようになりました。ビルドによってパスが変わる場合、ビルド基準でファイルやディレクトリを解決できます。It now supports specifying wildcards and minimatch patterns in Summary File and Report Directory fields, allowing the files and directories to be resolved on a per-build basis for paths that change between builds.

Maven と SonarQube の機能強化Maven and SonarQube improvements

Maven ビルド タスクで、SonarQube プロジェクトを指定できるようになりました。分析結果に関して、Maven pom.xml ファイルに指定されているものとは異なる場合に役立ちます。The Maven build task now allows specifying a SonarQube project for analysis results in cases where it differs from what is specified in the Maven pom.xml file.

Jenkins 統合の機能強化Improved Jenkins integration

Jenkins キュー ジョブ ビルド/リリース タスクで、Team Services に Jenkins コンソール出力を表示しているとき、Jenkins マルチブランチ パイプライン ジョブを実行できるようになりました (図 49)The Jenkins Queue Job build/release task now supports running Jenkins multibranch pipeline jobs while displaying the Jenkins console output in Team Services (Figure 49). パイプライン結果が Team Services ビルド概要に公開されます。Pipeline results are published to the Team Services build summary.

Improved Jenkins integration

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

Azure 仮想マシン スケール セットのデプロイAzure virtual machine scale set deployment

デプロイに使用されている一般的なパターンは、アプリケーションのバージョンごとにマシンのフル イメージを作成し、それをデプロイするというものです。A common pattern being used for deployment is to create a full machine image for each version of the application and then deploy that. その作業を簡単にするために、不変のマシン イメージの作成__タスクを新しく用意しました。To make that easier we have a new __Build immutable machine image task. このタスクでは Packer を利用し、アプリケーションとすべての必須要件をデプロイした後にマシン イメージを生成します。This task uses Packer to generate a machine image after deploying applications and all the required prerequisites. このタスクではデプロイ スクリプトと Packer 構成テンプレートのいずれかを利用し、マシン イメージを作成し、それを Azure Storage アカウントに保存します。The task takes either the deployment script or the packer configuration template to create the machine image and stores it in an Azure Storage account. このイメージは、この種類の不変イメージ デプロイと連動する Azure 仮想マシン スケール セット デプロイに利用できます。This image can then be used for Azure virtual machine scale set deployments that work well with this type of immutable image deployment.

Azure リソース グループ デプロイのテンプレート パラメーターのオーバーライドOverride template parameters in Azure resource group deployments

Azure リソース グループ デプロイ タスクでは現在のところ、ユーザーは template.json と parameters.json を選択し、特定の構文に従い、テキスト ボックスのオーバーライド パラメーター値を提供します。Currently in Azure resource group deployment tasks, users select the template.json and the parameters.json and provide the override parameter values in a text box, following a specific syntax. この機能が強化され、編集とオーバーライドを可能にするグリッドでテンプレート パラメーターが表示されるようになりました (図 50)This experience is now enhanced so the template parameters are rendered in a grid which allows them to be edited and overridden (Figure 50). この機能を使用するには、オーバーライド パラメーター フィールドの横にある ... をクリックします。ダイアログが開き、テンプレート パラメーター、既定値、入力可能値 (テンプレートとパラメーターの .json ファイルに定義されている場合) が提示されます。You can access this feature by clicking the ... next to the override parameters field, which opens a dialog with the template parameters along with their default values and allowed values (if defined in the template and parameter .json files). この機能を利用するには、ソースで CORS ルールが有効になっている必要があります。This feature requires that CORS rules are enabled at the source. テンプレートとパラメーターの json ファイルが Azure Storage BLOB にある場合、Azure Storage サービス ドキュメントを参照して CORS を有効にしてください。If template and parameter json files are in Azure storage blob, refer to the Azure Storage Services documentation to enable CORS.

Azure RG parameters

(図 50) Azure の RG パラメーター
Azure RG parameters
(Figure 50) Azure RG parameters

複数のリリース トリガー、ブランチ、タグ フィルターMultiple release triggers with branch and tag filters

リリース管理では、種類が “ビルド” の複数の成果物ソースに CD トリガーを設定できるようになりました。Release management now supports setting up CD triggers on multiple artifact sources of type “Build”. 追加すると、指定の成果物ソースで新しい成果物バージョンが利用できるようになったとき、新しいリリースが自動的に作成されます。When added, a new release is created automatically when a new artifact version is available for any of the specified artifact sources. リリースをトリガーするとき、新しいビルドのソースにするソース ブランチも指定できます。You can also specify the source branch that the new build should be from to trigger a release. また、タグ フィルターを設定し、リリースをトリガーするビルドをさらに絞り込むことができます。Additionally, Tag filters can be set to further filter the builds that should trigger a release.

リリースの成果物ソースの初期値設定Set defaults for artifact sources in a release

定義で成果物ソースをリンクするとき、リリースでデプロイする既定の成果物バージョンをユーザーは定義できます (図 51)Users can define the default artifact version to deploy in a release when linking an artifact source in a definition (Figure 51). リリースが自動的に作成されると、すべての成果物ソースの既定バージョンがデプロイされます。When a release is created automatically, the default version for all the artifact sources would be deployed.

Default artifact version

(図 51) 既定の成果物のバージョン
Default artifact version
(Figure 51) Default artifact version

デプロイの依頼者と承認者の職掌分散Separation of duties for deployment requester and approvers

以前は、環境の所有者は、リリースを環境にデプロイする行為の承認をリリース作成者に禁止できました。Previously, environment owners could restrict release creators from approving deployments of the release to an environment. しかしながら、別のユーザーが作成したリリースのデプロイを手動で開始し、自分で承認できました。You could, however, manually start deployment of a release created by another user, and approve it yourself.

デプロイの作成者を別個のデプロイ ユーザー ロールととらえることでこの欠陥が解消されました。We have now filled this gap by considering the deployment creator as a separate user role for deployments. リリース作成者とデプロイ作成者のいずれかにデプロイの承認を禁止できます。Either the release creator or deployment creator can be restricted from approving the deployments.

リリース レベルの承認Release level approvals

別の環境に正常にデプロイされた後に自動的にトリガーされたデプロイの自動承認を選択できるようになりました (図 52)You can now choose to automatically approve deployments that were automatically triggered after successful deployment to another environment (Figure 52). 1 つ 1 つすべてのデプロイを承認しないことを選択した場合、(承認者が同じ) 一連のデプロイの承認を 1 回で完了できます。Approving a chain of deployments (which have the same approvers) can be done at one go if you choose to not approve every deployment.

たとえば、Dev という環境と Test という環境があるとします。事前デプロイの承認者は “userA” と “userB” に設定されています。いずれにもデプロイの承認が要求されます。Let’s say you have two environments Dev and Test, with the predeployment approvers set to “userA” and “userB,” with both of them required to approve the deployment. Test のポリシーが下の画像のように設定されている場合、デプロイ中、userA と userB が Dev だけを承認すれば十分となります。If the policy on Test is set as shown below, during deployment time it will be sufficient for userA and userB to approve only Dev. Test へのデプロイは自動承認されます。Deployment to Test will get auto-approved. Test へのデプロイが手動でトリガーされる場合、正しく承認するには、デプロイの前に承認が必要になります。If the deployment to Test is triggered manually, the approvals will be required before deployment to ensure correct approvals.

Release level approvals

(図 52) リリース レベルの承認
Release level approvals
(Figure 52) Release level approvals

Azure Government Cloud へのデプロイDeploy to Azure Government Cloud

政府クラウドで Azure サブスクリプションをご利用のお客様は、国内のクラウドを対象とするように Azure Resource Manager サービス エンドポイントを構成できるようになりました。Customers with Azure subscriptions in Government Clouds can now configure Azure Resource Manager service endpoint to target national clouds.

この機能により、リリース管理を利用し、政府クラウドにホストされている Azure リソースに同じデプロイ タスクでアプリケーションをデプロイできます (図 53)With this, you can now use Release Management to deploy any application to Azure resources hosted in government clouds, using the same deployment tasks (Figure 53).

Government cloud

(図 53) 政府クラウド
Government cloud
(Figure 53) Government cloud

並行デプロイの最大数の設定Set maximum number of parallel deployments

この機能では、複数の保留リリースを特定の環境にデプロイする方法を制御できます (図 54)This feature gives you control on how multiple pending releases are deployed into a given environment (Figure 54). たとえば、QA 環境でリリース パイプラインがビルドを検証するとき、ビルドの生成率がデプロイの完了率より速ければ、並列で検証されるように複数のエージェントと同じ数のビルドを構成できます。For example, if your release pipeline performs validation of builds in a QA environment and the rate of generation of builds is faster than the rate of completion of the deployments, you may configure multiple agents and as many builds to get validated in parallel. つまり、生成されたビルドが 1 つ 1 つ検証され、待ち時間は利用できるエージェントの数に依存します。That means each of the builds generated gets validated, and the wait time is dependent in the number of available agents. この機能では、検証を最適化できます。最も新しい n 個のビルドを検証し、古いデプロイ要求をキャンセルできます。With this feature, we let you optimize validations by enabling you to perform validation on the n most recent builds in parallel and cancel the older deployment requests.

Parallel deployments

(図 54) 並行デプロイ
Parallel deployments
(Figure 54) Parallel deployments

手動介入タスクのタイムアウト機能強化Timeout enhancements for the Manual Intervention task

保留開始後、指定したタイムアウト機能強化期間と 60 日間のいずれかが先に到達したときに__手動介入__タスクを自動的に却下または再開できるようになりました。The Manual Intervention task can now be automatically rejected or resumed after it is pending for the specified timeout or 60 days, whichever is earlier. タイムアウト値はタスクのコントロール オプション セクションで指定できます。The timeout value can be specified in the control options section of the task.

リリース管理の並列実行Release Management parallel execution

リリース管理で、あるフェーズに並列実行オプションを指定できるようになりました (図 55)Release Management now supports a parallel execution option for a phase (Figure 55). このオプションを選択すると、フェーズ乗数オプションとして複数構成と複数エージェントのいずれかを利用し、フェーズがファンアウト (展開) されます。Select this option to fan out a phase by using either Multi-configuration or Multi-agent as a phase multiplier option.

Parallel execution support

(図 55) 並列実行のサポート
Parallel execution support
(Figure 55) Parallel execution support

複数構成: このオプションを選択すると、複数構成値ごとにフェーズが実行されます。Multi-configuration: Select this option to run the phase for each multi-configuration value. たとえば、2 つの異なる地域に同時にデプロイする場合、値 "east-US, west-US" を含む [変数] タブに定義されている変数 ReleasePlatform を使用すると、フェーズが並列実行されます。1 つは値 "east-US" で、もう 1 つは値 "west-US” で実行されます。For example, if you wanted to deploy to two different geos at the same time, using a variable ReleasePlatform defined on the Variables tab with values "east-US, west-US" would run the phase in parallel, one with a value of "east-US" and the other "west-US”. 複数エージェント: このオプションを選択すると、複数のエージェントの 1 つまたは複数のタスクでフェーズが並列実行されます。Multi-agent: Select this option to run the phase with one or more tasks on multiple agents in parallel.

Azure Portal における Web アプリのデプロイの履歴Web app deployment history in Azure portal

リリース管理では、App Service デプロイ タスクを利用してデプロイを完了したとき、Azure App Service のデプロイ ログが更新されるようになりました。Release management now updates the deployment logs of Azure App Service when a deployment is done by using the App Service deployment task. [App Service] ブレードで [継続的配信] オプションを選択すると、Azure Portal でデプロイの履歴を表示できます。You can view deployment history in the Azure portal by selecting the Continuous delivery option in the App Service blade.

テストの機能強化 Testing Improvements

エージェント フェーズを利用したテスト実行Run tests using agent phases

Visual Studio テスト タスク__を利用し、自動化されたテストをエージェント フェーズを利用して実行できるようになりました (図 56)Using the __Visual Studio Test task, you can now run automated tests using agent phases (Figure 56).

ビルド、リリース、テストの自動化エージェントが統一されました。We now have a unified automation agent across build, release and test. これには、次のような利点があります。This brings in the following benefits:

  1. テストに必要であれば、エージェント プールを活用できます。You can leverage an agent pool for your testing needs.
  2. ニーズに基づき、同じ Visual Studio テスト タスク__を利用し、さまざまなモードでテストを実行します。単一エージェントに基づく実行や複数エージェントに基づく分散テスト実行です。あるいは、複数構成実行で、たとえば、さまざまなブラウザーでテストを実行します。Run tests in different modes using the same __Visual Studio Test task, based on your needs—single agent–based run, multi-agent–based distributed test run or a multi-configuration run to run tests on, say, different browsers.

Run tests using Agent Phases

(図 56) エージェント フェーズを利用したテスト実行
Run tests using Agent Phases
(Figure 56) Run tests using Agent Phases

詳細については、アプリケーション ライフサイクル管理に関するこの投稿をご覧ください。For more information, refer to this Microsoft Application Lifecycle Management post.

自動化されたテストのオンデマンド トリガーOn-demand triggering of automated tests

テスト ハブでは、テスト計画やテスト スイートから自動化されたテストをトリガーできるようになりました (図 57)The Test hub now supports triggering automated test cases from test plans and test suites (Figure 57). テスト ハブから自動化されたテストを実行するには、リリース環境でテストをスケジュール実行する場合と同様の設定が必要になります。Running automated tests from the Test hub will need a setup similar to the way you run tests in a scheduled fashion in release environments. Run automated tests from test plans (自動化されたテストをテスト計画から実行) テンプレートを利用し、リリース定義に環境を設定し、自動化されたテストを実行するテスト計画を関連付ける必要があります。You will need to setup an environment in the release definition using the Run automated tests from test plans template and associate the test plan to run the automated tests. 環境を設定し、テスト ハブから自動化されたテストを設定する方法についてはこのドキュメントをご覧ください。詳細な説明があります。See the documentation for the step by step guidance on how to setup environments and run automated tests from the Test hub.

On-demand automated tests trigger

(図 57) オンデマンドの自動テスト トリガー
On-demand automated tests trigger
(Figure 57) On-demand automated tests trigger

ウェアハウスの機能強化 Warehouse Improvements

Analysis Services キューブ処理でのパフォーマンスの向上Performance improvements in Analysis Services cube processing

vDimWorkItemTreeOverlay ビューのパフォーマンスが向上されました。このビューは、リンクに基づいて__作業項目ツリー階層__ディメンションを作成する場合に使用します。We’ve made performance improvements to the vDimWorkItemTreeOverlay view, which is used to create Work Item Tree Hierarchy dimension based on the links. このビューは System.LinkTypes.Hierarchy リンクに依存していますが、処理時間について他のリンク (System.LinkTypes.Related など) も影響していることがわかりました。Although it depends on System.LinkTypes.Hierarchy links, we observed that the processing duration was affected by other links as well (e.g. System.LinkTypes.Related). データの読み取り量を制限している他の種類のリンクをスキップするようにビューを最適化しました。We optimized the view to skip addition link types which limits the amount of data read. この変更により、特定のウェアハウスの処理時間が大幅に短縮されます。This change significantly decreases processing time for certain warehouses.

大文字と小文字の区別のあるスキーマの調整Case-insensitive schema reconciliation

ウェアハウス データベースのスキーマは、スキーマの調整プロセスにおいて、接続されているすべてのコレクション データベースからのフィールドを結合して作成されます。The schema of the warehouse database is created by merging fields from all the attached collection databases in the schema reconciliation process. 以前は、すべての比較で大文字と小文字が区別されていたため、管理者はフィールド参照名を厳密に一致させる必要がありました。Previously, all comparisons were case-sensitive and administrators had to make sure there is an exact match on field reference names. この場合、大文字と小文字に少しの違いがあっても問題になっていました。This led to problems where there were subtle differences in casing. このリリースでは、そのような相違に対してプロセスが寛容になりました。With this release we make the process more tolerant to such discrepancies.

管理の機能強化 Administration Improvements

通知時に電子メールの受信者を結合するCombined email recipients for notifications

同じ電子メール通知の受信者が宛先にまとめて表示され、1 回のメールで送信されるようになりました。Recipients for the same email notification are now included together on the to: line and sent a single email. 以前は、個別の電子メールが各受信者に送信されていました。Previously, individual emails were sent to each recipient. そのため、誰が通知を受け取ったか判別できず、電子メールでイベントについて知らせることは困難でした。This made it difficult to know who else received the notification and to have a conversation about the event over email. この機能は、Out-of-the-Box サブスクリプションと複数の受信者を宛先にできるチーム サブスクリプションに適用されます。This feature applies to out-of-the-box as well as team subscriptions that are capable of targeting multiple recipients. たとえば、プル要求のすべてのレビュー担当者には、プル要求が変更されたとき、1 件のメールが送信されるようになりました。For example, all reviewers of a pull request are now sent a single email when a change is made to the pull request.

電子メール受信者の結合についてはこのページをご覧ください。Learn more about combining email recipients.

面倒な設定の要らない通知Out-of-the-box notifications

自分に直接関連するアカウントで動きがあったとき、ユーザーとチームに自動的に通知が届くようになりました。たとえば、次のタイミングで送信されます。Users and teams are now automatically notified via email when there is activity in the account directly relevant to them, such as:

  • 作業項目がユーザーに割り当てられたとき。when a work item is assigned to a user.
  • ユーザーまたはチームがレビュー担当者としてプル要求に追加されたとき。when a user or team is added as a reviewer to a pull request.
  • ユーザーまたはチームがレビュー担当者になっているプル要求が更新されたとき。when a user or team is a reviewer on a pull request that is updated.
  • 別のユーザーがプル要求コメントに返信したとき。when another user responds to a pull request comment.
  • ユーザーが要求したビルドが完了したとき。when a build requested by a user completes.
  • 拡張機能がインストールまたは要求されたとき (管理者のみ)。when an extension is installed or requested (admins only).

ユーザーは以上のサブスクリプションを解除できます。ユーザー プロファイル メニューの [通知] 設定を開き、該当するスイッチをオフにします。Users can unsubscribe from any of these subscriptions by going to Notification settings under the user profile menu and then switching off the appropriate toggle(s).

アカウント管理者は 1 つまたは複数の自動サブスクリプションを無効にできます。設定歯車からコレクション レベルの [通知] ハブを開いてください。An account admin can disable one or more of these automatic subscriptions by navigating to the collection-level Notifications hub under the settings gear. "..." アクションの下にある [無効にする] をクリックすると、サブスクリプションが無効になります。Any of these subscriptions can be disabled by clicking Disable under the "..." action. サブスクリプションを無効にすると、ユーザーの個人通知設定ページから表示が消えます。Once a subscription is disabled, it will no longer appear for users in their personal notification settings page.

面倒な設定の要らない通知の詳細についてはここをご覧ください。Learn more about out-of-the-box notifications.

拡張管理のアクセス許可Extension management permissions

管理者は、コレクションの拡張機能を管理するアクセス許可をユーザーやグループに与えることができるようになりました (図 58)An admin can now grant other users and groups permission to manage extensions for the collection (Figure 58). 以前は、コレクション管理者 (Project Collection Administrators グループのメンバーなど) のみが拡張要求を確認し、拡張機能をインストール、無効化、アンインストールできました。Previously only collection administrators (i.e. members of the Project Collection Administrators group) could review extension requests, install, disable, or uninstall extensions.

このアクセス許可を与えるには、管理者は Marketplace メニューを開き、拡張機能の管理を選択して拡張機能管理ハブに移動します。それから、セキュリティ ボタンをクリックします。To grant this permission, an administrator can navigate to the Extensions admin hub by opening the Marketplace menu, selecting Manage extensions, and then click the Security button:

Extension management permissions

(図 58) 拡張管理のアクセス許可
Extension management permissions
(Figure 58) Extension management permissions

拡張機能がインストールされたときや注意が必要なときなどに通知を受け取るGetting notified when extensions are installed, require attention, and more

管理者または拡張機能を管理する資格が与えられているユーザーには、拡張機能がインストール、アンインストール、有効化、無効化されたとき、あるいは注意が必要なとき、自動的に通知が届くようになりました。Admins, or those with the ability to manage extensions, are now automatically notified when an extension is installed, uninstalled, enabled, disabled, or requires attention. これは、複数のユーザーが拡張機能の管理を担当するような大規模デプロイで特に役立ちます。This is especially useful in larger deployments where multiple people have the responsibility of managing extensions. 管理者はこのような通知をオフにできます。プロファイル メニューの [通知] 設定を開き、拡張機能のスイッチをオフにします。Admins can turn off these notifications by navigating to Notification settings under the profile menu and switching off the extensions toggle.

管理者は拡張機能関連のイベントに独自のサブスクリプションを定義することもできます。Admins can also define custom subscriptions for extension-related events. たとえば、拡張機能が更新されるたびに管理者が通知を受け取るように定義できます。For example, an admin can get notified whenever any extension is updated.

ユーザーも、拡張機能要求に関する自動通知をオフにできるようになりました。Users can also now turn off automatic notifications about their extension requests.

詳細アクセス レベルにサブスクライバーを追加することを TFS 管理者に許可するAllowing TFS admins to add subscribers to the advanced access level

詳細__アクセス レベルは Team Foundation Server の将来のバージョンから削除されます。The __Advanced access level will be removed from future versions of Team Foundation Server. ただし、削除されるまでは、MSDN Platform と Visual Studio Test Professional のサブスクライバーを__詳細__アクセス レベルに追加する権限が更新プログラム 2 で TFS 管理者に与えられる予定です。However, until that happens, TFS admins will have the ability to add MSDN Platform and Visual Studio Test Professional subscribers to the Advanced access level with Update 2.

Visual Studio Enterprise サブスクライバーは__詳細__ではなく Visual Studio Enterprise アクセス レベルに追加してください。Visual Studio Enterprise subscribers should be added to the Visual Studio Enterprise access level instead of Advanced. Test Manager 拡張を購入している場合、購入したチーム プロジェクト内のユーザー ハブで引き続きこれを管理してください。If you have purchased the Test Manager extension, please continue to manage this in the Users hub within the Team Project that you made the purchase.

Microsoft Teams の統合 Microsoft Teams Integration

Microsoft Teams を使用して共同作業を行っている組織は、チームのチャネル内で TFS のプロジェクトからアクティビティを確認できるようになりました。Organizations using Microsoft Teams to collaborate can now see activity from their TFS projects within their team’s channels. これにより、チームは Microsoft Teams で作業しながら、関連する作業項目の変更、プル要求、ビルド、リリースなどについて最新の情報を取得することができます。This allows teams to stay informed about relevant work item changes, pull requests, builds, and releases and more as they are working in Microsoft Teams. 詳細については、こちら を参照してください。For more information see our documentation.


既知の問題Known Issues

作業項目フォームが Web で正しくレンダリングされないWork item forms do not render correctly in the web

  • 問題:Issue:

    Web クライアント用ではなく、Visual Studio クライアント用に、複数値のコントロールなどのカスタム コントロールをインストールしている場合、作業項目フォームが Web で正しくレンダリングされません。If you have a custom control, such as the multi-value control, installed for the Visual Studio client but not the web client, work item forms in the web fail to render.

  • 回避策:Workaround:

    コントロールを最新バージョンに更新する必要があります。You will need to update to the latest version of your control. 不足しているコントロール要素を含まない Web レイアウトを追加する必要があります。It is necessary to add a web layout that doesn’t contain the missing control element. TFS 2017 Update の最新の複数値コントロールは、TFS 作業項目追跡用のカスタム コントロールにあります。You can find the latest multi-value control for TFS 2017 Update on the Custom Controls for TFS Work Item Tracking page. レイアウトに関する詳細については、「すべての FORM XML 要素のリファレンス (TFS 2015)」ページをご覧ください。For more information on the layout, see All FORM XML elements reference (TFS 2015) page.

TFS のバージョンが、最終リリースではなく RC2 であるTFS version is RC2 instead of the final release

  • 問題:Issue:

    2017 年 8 月 1 日より前に TFS 2017 Update 2 をダウンロードしてインストールをした場合は、RC2 バージョンを所有しています。After downloading TFS 2017 Update 2 before August 1, 2017, and installing, you have an RC2 version.

  • 回避策:Workaround:

    これは、2017 年 8 月 1 日に修正されたインストール リンクに断続的な問題があったためです。This was due to an intermittent issue in the installation links that was fixed on August 1, 2017. TFS 2017 Update 2 をもう一度ダウンロードして、この最終リリースをインストールしてください。Please redownload TFS 2017 Update 2 and install this final release.


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


ページのトップへ
Top of Page