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

終更新日 2018/01/31

最新の更新プログラムを確認するには、英語版の「Release Notes」をご覧ください。To see the latest updates, please visit the English Release Notes.

リリース日: 2017 年 3 月 7 日Release Date: March 7, 2017

Microsoft は、Team Foundation Server 2017 Update 1 がリリースされたことをお知らせします。We are happy to announce the release of Team Foundation Server 2017 Update 1. この新しいリリースには、最新の機能の技術革新や改良が組み込まれています。This new release includes our most recent feature innovations and improvements. 要件については、Team Foundation Server の要件と互換性に関するページを参照してください。You can find requirement information on the Team Foundation Server Requirements and Compatibility page.

ダウンロード: Team Foundation Server 2017 Update 1Download: Team Foundation Server 2017 Update 1

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

TFS 2017 Update 1 の新機能What's New in TFS 2017 Update 1


既知の問題Known Issues


新機能What's New

より自由なカスタマイズ More personal experiences

個人用のコレクション ホーム ページPersonalized collection home page

このリリースでは、最も重要な成果物へのアクセスが非常に簡単になりました。With this release, it's super easy for you to access artifacts that are most important to you. 再設計されたコレクション ページ (図 1) は、自分が関心のあるプロジェクト、お気に入り、作業、およびプル要求が表示されるようにカスタマイズすることができます。The redesigned collection page (Figure 1) has a personalized experience that shows the Projects, Favorites, Work, and Pull Requests you care about. これで、すぐに 1 日をスタートさせることができます。This makes for a great way to start your day. アクセスする場所が 1 か所で済むため、必要な作業内容や関心のある内容をすばやく見つけることができます。You can go to one place and quickly find everything you need and care about. 詳細については、アカウント ハブ ページに関するページを参照してください。See Account hub pages for more information.

Redesigned collection page

(図 1) 再設計されたコレクション ページ
Redesigned collection page
(Figure 1) Redesigned collection page

プロジェクト ID を取得するYour project gets an identity

プロジェクトの概要を 1 か所で確認できるようになりました。There is now one place to get an overview of your project. 新しいプロジェクト ページでは、プロジェクト説明の表示と編集、メンバーの表示と追加、最新のアクティビティの確認を簡単に行うことができます。The new project page makes it easy to view and edit the project description, view or add members, and check on the latest activity. また、新しいプロジェクトの開始や TFS の組み込み DevOps 機能のフル活用もより簡単になります。It is even easier to get started with a new project, and leverage all the built-in DevOps functionality of TFS.

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

リポジトリ管理者のアクセス許可変更 Repo admin permission changes

Git リポジトリの__管理者__アクセス許可をより細かな権限に分割しました。For Git repos, we’ve divided the Administer permission into several more granular permissions. 誰がどのアクションを実行するのか、より柔軟に決定できます。This gives you more flexibility to decide who can perform what actions. たとえば、アカウントの全員に新しいリポジトリの作成を許可するが、リポジトリを削除することや新しいユーザーをリポジトリに追加することは禁止したい場合があります。For instance, you may allow anyone in your account to create new repositories, but disallow them from deleting repos or adding new users to a repo. 新しいアクセス許可は次のとおりです。The new permissions are:

  • アクセス許可の管理: ユーザーとアクセス許可を追加/削除できます。Manage permissions: Add/remove users and permissions.
  • 作成: 新しいリポジトリを作成できます。Create: Create a new repo.
  • 削除: リポジトリを削除できます。Delete: Delete a repo.
  • 名前変更: リポジトリの名前を変更できます。Rename: Rename a repo.
  • ポリシーの編集: 分岐ポリシーを構成できます。Edit policies: Configure branch policies.
  • 他のユーザーのロックの削除: 別のユーザーが設定した分岐ロックを削除できます。Remove others’ locks: Remove branch locks set by another user.

これらのアクセス許可は、あるプロジェクトのすべてのリポジトリに適用するか、個々のリポジトリに適用できます。These permissions can be applied to all repositories in a project, or to individual repositories.

分岐ポリシーの改善 Branch policy improvements

ポリシー セクション (図 2) で、必須のポリシーと任意のポリシーがグループ化され、各セクションに分けられました。In the Policies section (Figure 2), the required and optional policies are now grouped into sections. PR を完了するために必要なポリシーがわかりやすく表示されます。This clarifies exactly which policies are required in order to complete a PR. 必須セクションには必要なレビューもまとめられています。校閲者全員が承認した場合にのみ、合格の印が付きます。Required reviewers are also summarized in the required section, and will only be marked as passing when all required reviewers have approved.

Policies section

(図 2) ポリシー ページ
Policies section
(Figure 2) Policies section

ポリシーをバイパス (迂回) する必要がある (そのために必要なアクセス許可が与えられている) ユーザーに対する [完了] ダイアログの表示が新しくなりました (図 3)If you need to bypass policies (and have the required permissions), a new experience will be shown in the Complete dialog (Figure 3). 準拠されていないポリシーが警告メッセージに表示され、ポリシーの無視を明示的に選択する新しいオプションが提示されます。Any policies that are not met will be shown in a warning message, and a new explicit option to opt-in to override policies will be presented. 無視するオプションを選択すると、無視と完了__アクションが有効になり、PR が完了し、準拠していないポリシーが無視されます。Checking the override option will enable the __Override & Complete action, which will complete the PR, overriding any failing policies.

Complete dialog

(図 3) 完了ダイアログ
Complete dialog
(Figure 3) Complete dialog

必要なレビュー担当者ポリシーでのファイル除外のサポートSupport file exclusions in the required reviewer policy

特定のファイル パスに必要なレビュー担当者を指定する場合に、除外するパスに "!" プレフィックスを使用して、When specifying required reviewers for specific file paths, you can now exclude paths by using a “!” パスを除外できるようになりました。prefix to the path you want to exclude. たとえば、通常は必要になるサインオフから docs フォルダーを除外する場合にこれを使用することができます (図 4)For example, you can use this to exclude a docs folder from your normally required signoff (Figure 4).

File exclusion support

(図 4) ファイルの除外のサポート
File exclusion support
(Figure 4) File exclusion support

リポジトリのインポートImport repository

GitHub、BitBucket、GitLab、または他の場所から Git リポジトリをインポートできるようになりました。You can now import a Git repository from GitHub, BitBucket, GitLab, or other locations. 新しいリポジトリまたは既存の空のリポジトリにインポートしてください。Import into either a new, or existing empty repository. 詳細については、Git リポジトリのインポートに関するページを参照してください。For more information, see Import a Git repo.

リポジトリ作成時に .gitignore を追加するAdd .gitignore during repo creation

新しい Git リポジトリを作成するときに、.gitignore ファイルを追加してリポジトリに関連付けられるようになりました。While creating a new Git repository, you can now add and associate a .gitignore file with your repository. .gitignore ファイルでは、コミットの実行中に Git で無視するファイルを指定します。A .gitignore file specifies files that Git should ignore while performing a commit.

ダイアログ ボックスでは、多くの使用可能な .gitignore テンプレートのいずれかを選択することができます (図 5)The dialog allows you to select one of the many available .gitignore templates (Figure 5).

Add .gitignore during repo creation

(図 5) リポジトリ作成時に .gitignore を追加する
Add .gitignore during repo creation
(Figure 5) Add .gitignore during repo creation

チェリーピックおよび元に戻す機能Cherry-pick and revert

2 つの新機能 (チェリーピックおよび元に戻す) が追加され、Web ポータルからより簡単に変更を移植または元に戻せるようになりました。We’ve added two new features that make it easier to port or back out changes from the web portal: Cherry-pick and Revert.

cherry-pick コマンドを使用することで、プル要求の変更を複数の分岐に移植できます。Use the cherry-pick command to port changes in a pull request to multiple branches. 一般的なユース ケースは、バグの発生時に修正プログラムを実行する必要があり、メインラインでも修正が必要な場合です。A typical use case is when a bug needs to be hotfixed, but should also be fixed in the mainline. 修正を含むプル要求を作成し、修正プログラムの分岐に移植したら、マスター分岐に同じ修正を簡単にチェリーピックすることができます。Once you’ve created your pull request that contains the fix to the hotfix branch, you can easily cherry-pick the same fix into the master branch. 詳細については、チェリーピックによる変更のコピーに関するページを参照してください。See Copy changes with cherry-pick for more information.

完了した PR の変更を元に戻すことができます。You can revert changes on completed PRs. 不適切に変更された PR を見つけ、[元に戻す] をクリックし、手順に従って望ましくない変更を元に戻す PR を作成します。Find the PR that introduced the bad change, click Revert, and follow the steps to create a PR that backs out the unwanted changes. 詳細については、Git を使用して変更を元に戻す方法に関するページを参照してください。For more information, see Undo Changes with Git.

構成可能な比較分岐Configurable compare branch

既定の分岐以外にも比較分岐を設定できるようになりました。You can now set your compare branch to something other than the default branch. この設定はユーザーごとに記憶されます。This setting will be remembered on a per-user basis. [分岐] ページから作成された新しい分岐とプル要求は、比較分岐として設定した分岐に基づきます。Pull requests and new branches created from the Branches page will be based off the branch you set as the compare branch. 詳細については、分岐のマージに関するページを参照してください。See Manage your branches for more information.

ファイルまたはフォルダーの検索Find a file or folder

Team Services プロジェクトの [コード] ハブを使用して、リポジトリでファイルまたはフォルダーをすばやく検索することができます。You can quickly search for a file or folder in a repository using the Code hub in your Team Services project. 結果には、後ろにリポジトリ全体のファイルとフォルダーが続く現在のフォルダーからの項目がリストされます。The result lists items from your current folder followed by files and folders across the repository.

Git リポジトリの場合は、パス コントロール ボックス (図 6) に移動し、入力を開始して、検索対象のファイルまたはフォルダーのナビゲーション検索エクスペリエンスを開始します。For any Git repository, go to the path control box (Figure 6), and start typing to initiate a navigation search experience for the file, or folder you are looking for.

Find a file or folder

(図 6) ファイルまたはフォルダーの検索
Find a file or folder
(Figure 6) Find a file or folder

リポジトリの削除の確認Confirmation for deleting repos

リポジトリを誤って削除しないように、削除対象のリポジトリの名前を入力して削除の確認を求められるようになりました。To prevent accidental repository deletions, you now have to type the name of the repository that you wish to delete to confirm the action.

リポジトリのお気に入りRepo favorites

最も頻繁に使用するリポジトリをお気に入りに追加できるようになりました。You can now favorite the repos you work with most frequently. リポジトリ ピッカー (図 7) では、[すべてのリポジトリ][お気に入り] のタブが表示されます。In the repo picker (Figure 7), you will see tabs for All repositories and your Favorites. 星をクリックすると、お気に入りの一覧にリポジトリが追加されます。Click the star to add a repository to your list of Favorites.

Repo favorites

(図 7) リポジトリのお気に入り
Repo favorites
(Figure 7) Repo favorites

コミット履歴でファイルまたはフォルダーを検索するSearch for a file or folder in commit history

[ファイル] タブと同様に、ユーザーはリポジトリでファイルまたはフォルダーを検索し、そのファイルまたはフォルダーのコミット履歴を表示できるようになりました。Similar to the files tab, you can now search for a file or folder in a repository and see the history of commits for that file or folder. Git リポジトリの場合は、[履歴] タブ (図 8) のパス コントロール ボックスに移動し、入力を開始して、検索対象のファイルまたはフォルダーの履歴検索エクスペリエンスを開始します。For any Git repository, go to the path control box on the History tab (Figure 8), and start typing to initiate a history search experience for the file, or folder you are looking for.

Commit history

(図 8) コミットの履歴
Commit history
(Figure 8) Commit history

コミット ページの機能拡張Commit page improvements

コミットの詳細ページとコミットの履歴ページを新しくし、効率よく使用できるようにしました。We made your experience of the commit details page and commit history page up-to-date and highly performant. コミットに関する重要な情報を概観から見つけて実行できるようになりました。You can now find, and act on, important information related to the commit at a bird’s-eye view.

コミットの詳細ページの例を以下に示します (図 9)Here is an example of the commit details page (Figure 9):

Commit details

(図 9) コミットの詳細
Commit details
(Figure 9) Commit details

コミットの履歴ページを以下に示します (図 10)Here is the commit history page (Figure 10):

Commit history

(図 10) コミットの履歴
Commit history
(Figure 10) Commit history

分岐でのコミットの検索Search for commits in branches

コミットの詳細ページにある [Search in branches] (分岐で検索) ボタンをクリックすることで、指定された分岐またはタグでコミットを検索できるようになりました (図 11)You can now search for a commit in a specified branch or a tag by clicking on the Search in branches button on the commit details page (Figure 11).

Commit search

(図 11) コミットの検索
Commit search
(Figure 11) Commit search

ウィンドウでタグと分岐を選択し、これらの分岐とタグに特定のコミットが含まれていない場合でも、確認することができます (図 12)You can select tags and branches in the window to view, even if these branches and tags do not contain the particular commit (Figure 12).

Commit search dialog

(図 12) コミットの検索ダイアログ
Commit search dialog
(Figure 12) Commit search dialog

ディスカッション コントロール ツール バー Discussion control toolbar

マークダウンはプル要求にコメントを追加するための強力なツールですが、構文を覚えるのが大変です。Markdown is a powerful tool when adding comments to pull requests, but it can be hard to remember the syntax. この操作を簡単にするために、ディスカッション コントロールにツールバーを追加しました (図 13)To make this easier, we’ve added a toolbar to the discussion control (Figure 13). これで、適切なマークダウン構文を挿入して一般的な書式を追加できるようになります。This will insert the appropriate Markdown syntax to add common formatting. 見出し、太字体、斜体、リンク、コード、リストはすべて、新しいツール バー コントロールを利用して追加できます。@ や # メンションのような機能もツール バーで入力できます。Headings, boldface, italics, links, code, and lists can all be added using the new toolbar controls, and features like @ and # mentions can be entered using the toolbar as well. キーボード ショートカットが太字体 (CTRL + B)、斜体 (CTRL + I)、リンクの作成 (CTRL + K) で使用できます。Keyboard shortcuts are available for boldface (CTRL + B), italics (CTRL + I), and creating links (CTRL + K).

Discussion toolbar

(図 13) ディスカッション ツール バー
Discussion toolbar
(Figure 13) Discussion toolbar

PR コメントの改善 PR comment improvements

PR の新しいコメントを簡単に見つけられるように、既存のディスカッション スレッドの新しい返信に装飾を追加しました。To help you better identify the new comments in their PR, we’ve added some additional decoration to the new replies in existing discussion threads. ファイル ビューのコメントでも、新しいコメントが含まれるスレッドが強調表示されます (図 14)Comments in the files view will also highlight threads that have new comments (Figure 14).

PR comment

(図 14) PR コメントの改善
PR comment
(Figure 14) PR comment improvements

コミットの PR の表示 View PRs for a commit

コミットの詳細__ページに、あるコミットに関連付けられているすべてのプル要求を閲覧できます。You can now view all associated pull requests for a commit on the __Commit details page. 下の画像 (図 15) では、次のことを確認できます。From the image below (Figure 15), you can see that:

  • 関連付けられているプル要求ドロップダウンで、このコミットに 2 つのプル要求が関連付けられています。In the associated pull request drop-down, there are two pull requests associated with this commit.
  • プル要求 #2 はこのコミットをマスターに届けました。Pull request #2 brought this commit to master.
  • 同じコミットがプル要求 #1 を経由して分岐 4 に届けられました。The same commit was brought into branch 4 via pull request #1.

PR in commits

(図 15) コミットの PR
PR in commits
(Figure 15) PR in commits

プル要求のフォローFollow a pull request

プル要求をフォローし、電子メール アラートを使用して、変更が生じた場合に常に通知できるようになりました。You can now follow a pull request to stay notified of any changes via email alerts. コンテキスト メニューで、必要に応じて__フォロー__を使用できます (図 16)The option to Follow is available in the context menu (Figure 16).

Follow a pull request

(図 16) プル要求のフォロー
Follow a pull request
(Figure 16) Follow a pull request

プル要求マージの再開Restart pull request merge

さらにオプションが追加され、ターゲット分岐が更新されている場合にプル要求のマージが再試行されるようになりました。Another option has been added to re-attempt the merge for a pull request where the target branch has been updated. この [マージの再開] オプションは、ターゲット分岐が最近変更されたために競合が発生していないか、あるいは PR ビルドが壊れていないかを確認する場合に役立ちます。This Restart merge option is useful when you want to verify that recent changes to the target branch haven’t created conflicts or broken your PR build.

拒否されたプル要求では完了できないCompletion blocked on rejected pull requests

コード レビュー ポリシーが設定されている分岐では、1 人以上のレビュー担当者が PR を拒否した場合、その PR は完了できないことが示されます。Branches that have the code review policy set will show that the PR is unable to be completed if it is rejected by one or more reviewers. 多くのユーザーがこの動作を求めているため、既定の動作が変更されました。Many of you expected this behavior, so we’ve changed the default behavior. 元の動作を必要とするチームのために、分岐ポリシー設定ページには新しいオプションが用意されています (図 17)For teams that want the original behavior, there is a new option in the branch policy setting page (Figure 17).

Code review policy

(図 17) コード レビュー ポリシー
Code review policy
(Figure 17) Code review policy

プル要求の説明のマークダウンMarkdown in pull request description

マークダウンを使用すれば、プル要求の説明を少し面白いものにすることができます。Spice up your pull request description with Markdown. プル要求コメントで使い慣れた同じマークダウン サポートを、プル要求の説明でも使用できるようになりました。The same Markdown support you know and love in pull request comments is now available in the pull request description.

PR ディスカッションの添付ファイルAttachments in PR discussions

プル要求コメントに添付ファイルを追加できるようになりました (図 18)You can now add attachments to your pull request comments (Figure 18). ドラッグ アンド ドロップまたは参照することで、添付ファイルを追加することができます。Attachments can be added by drag-and-drop or by browsing. イメージの場合、クリップボードから貼り付けるだけで、添付ファイルを追加することができます。For images, attachments can be added by simply pasting from the clipboard. 添付ファイルを追加すると、自動的にコメントが更新され、新しい添付ファイルへのマークダウン参照が追加されます。Adding an attachment automatically updates the comment to include a Markdown reference to the new attachment.

Attachments in PR discussions

(図 18) PR ディスカッションの添付ファイル
Attachments in PR discussions
(Figure 18) Attachments in PR discussions

更新された PR の強調表示Highlight the PRs that have updates

プル要求の更新の表示が従来より簡単になりました。It’s now easier than ever to see the updates to your pull requests. PR リスト ビュー (図 19) には、最後に確認してから変更が加えられた PR が新しい更新列と共に表示され、変更のロールアップが示されます。In the PR list view (Figure 19), PRs with changes since you've last seen them, are shown with a new updates column that shows a roll-up of the changes.

PR updated files

(図 19) PR の更新ファイル
PR updated files
(Figure 19) PR updated files

変更がある PR を表示すると、概要に同様の概要メッセージが表示されます。When you view a PR that has changes, you’ll see a similar summary message in the overview. また、新しいプッシュおよびコメント スレッドが青色で強調表示されます (図 20)New pushes and comment threads are highlighted in blue (Figure 20). [View code updates] (コードの表示の更新) リンクをクリックすると、[ファイル] ビューに移動し、プル要求を最後に表示してから加えられた新しい変更の差分が示されます。Clicking the View code updates link will navigate to the Files view, where a diff of the new changes since you last viewed the pull request is shown. この機能を使用すれば、作成者がフィードバックに応じて変更を加えた PR を簡単にフォローアップすることができます。This feature makes it easy to follow up on a PR where the author made changes in response to feedback.

PR summary

(図 20) PR の概要
PR summary
(Figure 20) PR summary

PR マージ戦略の分岐ポリシーBranch policy for PR merge strategy

新しい分岐ポリシー (図 21) が追加され、分岐ごとにプル要求をマージするための戦略を定義できるようになりました。We’ve added a new branch policy (Figure 21) that lets you define a strategy for merging pull requests for each branch. これまでは、PR が完了した時点で、マージするかスカッシュするかを決定していました。Previously, you chose the decision to either merge or squash at the time a PR was completed. 有効にすると、このポリシーでユーザーの設定が上書きされ、ポリシーによって設定された要件が適用されます。If enabled, this policy will override your preferences, enforcing the requirement set by the policy.

Branch policy

(図 21) 分岐ポリシー
Branch policy
(Figure 21) Branch policy

マージ競合情報の公開Expose merge conflict information

プル要求に競合するファイルがある場合、その競合の詳細が概要に表示されるようになりました (図 22)If there are any files with conflicts in a pull request, the details about those conflicts will now be visible in the overview (Figure 22). 競合する各ファイルは、ソース分岐とターゲット分岐間の競合の種類の短い要約と共にリスト表示されます。Each conflicting file will be listed, along with a short summary of the type of conflict between the source and target branches.

Merge conflicts

(図 22) マージの競合
Merge conflicts
(Figure 22) Merge conflicts

マークダウンのプレビュー ボタンMarkdown preview button

コミット、プッシュ、またはプル要求でのマークダウン ファイルの差分を表示する際に、結果としてレンダリングされるビューを簡単に切り替えられるようになりました。When viewing a diff of a markdown file in a commit, push, or pull request, you can now easily toggle to see the resulting rendered view.

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

スコープ設定された ID フィールドの検索機能の向上Improved search experience for scoped identity fields

このリリースでは、スコープ設定された ID フィールド (特定のユーザー グループのみに割り当てを許可するよう構成された ID フィールド) に対する ID 選択コントロールの動作が更新されています。With this release, we updated the identity picker behavior for scoped identity fields, i.e. identity fields that are configured to only allow assignment to a specific group of users. 更新された動作では、選択コントロールの MRU 一覧と検索結果に、コレクションの有効なユーザーがすべて表示されるのではなく、構成されたグループのメンバーのみが表示されます。In the updated experience, the picker’s MRU list and search results will only return members of the configured group, rather than show results for all valid users for the collection.

ビルドの機能強化 Build Improvements

ビルド定義のロールバックRollback build definitions

ビルド定義を以前のバージョンにロールバックすることができます。You can roll a build definition back to a previous version. ビルド定義を編集しているときにロールバックを実行するには、[履歴] タブを開きます。You can do this when editing a build definition by going to the History tab.

ビルドのソースの同期とチェックアウトを無効にするDisable the sync and checkout of sources in a build

必要に応じて、Git の自動ソース同期とチェックアウトを無効にすることができます。You can optionally disable the automatic source sync and checkout for Git. これにより、エージェントの組み込み動作に依存することなく、タスクまたはスクリプトでソース操作を処理することができます。This will enable you to handle the source operations in a task or script, instead of relying on the agent’s built-in behavior. Source.Version、Source.Branch および Build.SourcesDirectory などの標準的なソースに関する変数はすべて設定されます。All standard source-related variables like Source.Version, Source.Branch, and Build.SourcesDirectory are set.

Git の浅い複製と git-lfsGit shallow clone and git-lfs

ビルド エージェントで、Git の浅い複製と git-lfs がサポートされるようになりました。The build agent now supports Git shallow clone and git-lfs. 詳細については、ビルド定義のリポジトリに関するページを参照してください。For more details, see the Build definition repository page.

ビルドとリリース定義のタスクのバージョン管理Task versioning for Build and Release definitions

ビルドまたはリリースで実行するタスクのメジャー バージョンをユーザーが管理できるようになります。We’ve given you control over the major version of a task that you run in your build or release. この変更により、エージェントとタスクのバージョンの自動更新が原因で発生していた予期しないエラーが減少します。This change will result in fewer unpredictable errors that were caused by automatic updates to the agent and task version. ここでは、定義の [ビルド] タブ、またはリリース定義の [環境] タブで、タスクのメジャー バージョンを指定します。You now specify the major version of the task on the Build tab of your definition, or on the Environments tab of your release definition.

マイナー バージョン (1.2 から 1.3 など) のリリース時に、ビルドでの変更は自動的に行われます。When a minor version is released (for example, 1.2 to 1.3), you get that change automatically in your build. ただし、新しいメジャー バージョン (2.0 など) がリリースされた場合、定義を編集し、手動で新しいメジャー バージョンに変更しない限り、ビルドはバージョン 1.3 にロックされたままになります。But if a new major version is released (for example 2.0), then your build stays locked to version 1.3 until you edit the definition and manually change to the new major version. ビルド定義のフラグは、新しいメジャー バージョンが存在することを知らせるものです。A flag in the build definition alerts you to new major versions.

パッケージ管理に必要な支払い Payment required for Package Management

パッケージ管理の利用を続行するには、Visual Studio Enterprise サブスクリプションとパッケージ管理ライセンスのいずれかを Marketplace で購入する必要があります。To continue using Package Management, you will either need a Visual Studio Enterprise subscription or a Package Management license purchased in the Marketplace. パッケージ管理のライセンスに関する詳細はここをご覧ください。You can read more about licensing Package Management.

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

パッケージ管理のリリース ビューRelease views in Package Management

パッケージ管理に__リリース ビュー__という新しい機能が追加されました (図 23)We've added a new feature to Package Management called release views (Figure 23). リリース ビューは、リリース ビューに昇格したフィードのパッケージ バージョンのサブセットを示します。Release views represent a subset of package-versions in your feed that you've promoted into that release view. リリース ビューを作成し、パッケージのコンシューマーと共有することで、依存するバージョンを制御することができます。Creating a release view and sharing it with your package's consumers enables you to control which versions they take a dependency on. これは、更新されたパッケージ バージョンを頻繁に発行する場合に、発行した各バージョンの発表やサポートは行わない継続的な統合シナリオで特に役立ちます。This is particularly useful in continuous integration scenarios where you're frequently publishing updated package versions, but may not want to announce or support each published version.

この機能を使い始めるには Web アクセスでクイック スタートを探すか、パッケージ CI/CD のリリース ビューに関する情報をご覧ください。Look for the quick start in Web Access or learn about release views for package CI/CD to get started.

Release views in Package Management

(図 23) リリース ビュー
Release views in Package Management
(Figure 23) Release views

パッケージ管理の npmnpm in Package Management

パッケージ管理フィードで、Node.js および JavaScript 開発用の npm パッケージがサポートされるようになりました。Package Management feeds now support npm packages for Node.js and JavaScript development. さらに、npm フィードでは、"キャッシュを使用するアップストリーム ソース" として npmjs.com がサポートされます。In addition, npm feeds support npmjs.com as an "upstream source with caching." このオプションを有効にすると、フィードで npmjs.com (「Use packages from npmjs.com」 (npmjs.com のパッケージを使用する) を参照してください) からのパッケージが透過的にプロキシされ、キャッシュされます。つまり、npmjs.com から特定の package@version を取得するのが一度で済み、そのパッケージに対する今後の要求は TFS サーバーから直接処理されることになります。By enabling this option, your feed will transparently proxy and cache packages from npmjs.com (see Use packages from npmjs.com), which means that you'll only need to get a particular package@version from npmjs.com once; future requests for that package will be served directly from your TFS server. npmjs.com からパッケージが削除されても、キャッシュされたバージョンを TFS から取得することができます。If a package is removed from npmjs.com, you'll still be able to get the cached version from TFS.

まず、[フィードに接続] ダイアログで新しい npm オプションを探します (図 24)To get started, look for the new npm option in the Connect to feed dialog (Figure 24).

npm in Package Management

(図 24) パッケージ管理の npm
npm in Package Management
(Figure 24) npm in Package Management

クロス プラットフォームの機能強化 Cross Platform Improvements

Xcode ビルド タスクの xcpretty フォーマットXcode Build task xcpretty formatting

xcpretty を使用して、xcode ビルドの出力を書式設定できるようになりました (図 25)You can now format your xcode build output with xcpretty (Figure 25). また、xcodebuild で Team Services に JUnit テスト結果を発行することもできます。You can also publish JUnit test results to Team Services with xcodebuild. これまでは、テスト結果を発行する際にビルド ツールとして xctool を使用する必要がありました。Previously, xctool had to be used as the build tool to publish test results. これからは、xcpretty を有効にする場合に、Xcode タスクの [詳細設定] セクションにある [xcpretty の使用] チェック ボックスをオンにし、[xctool の使用] チェック ボックスをオフにします。Now, to enable xcpretty, check Use xcpretty and uncheck Use xctool in the Advanced section of the Xcode task.

Xcode Build formatting

(図 25) Xcpretty の書式設定
Xcode Build formatting
(Figure 25) Xcpretty formatting

Jenkins テストとコード カバレッジの結果を発行するPublish Jenkins test and code coverage results

Jenkins キュー ジョブのビルドとリリース タスクで、Jenkins ジョブまたはパイプラインからテストとコード カバレッジの結果を取得できるようになりました。The Jenkins Queue Job build and release task can now retrieve test and code coverage results from a Jenkins job or pipeline. その場合、Jenkins サーバーに Jenkins 5.2.0 以降用の TFS プラグインをインストールし、ビルド後に TFS/Team Services 用に結果を収集するように構成する必要があります。This requires installation of the TFS Plugin for Jenkins 5.2.0 or later on your Jenkins server and configuring the post-build action Collect Results for TFS/Team Services. 結果を Jenkins から取得したら、テスト結果の発行またはコード カバレッジの発行ビルド タスクで発行することができます。After results are retrieved from Jenkins, they can be published with the Publish Test Results or Publish Code Coverage build tasks.

Xcode ビルド タスクでの Xcode 8 による署名とパッケージのエクスポートXcode 8 signing and exporting packages in the Xcode Build Task

Xcode タスクでは、Xcode 8 自動署名を使用するプロジェクトのビルドがサポートされるようになりました (図 26)The Xcode task now supports building your projects using Xcode 8 automatic signing (Figure 26). 証明書をインストールして、ビルド サーバーのプロファイルを手動でプロビジョニングすることができます。また、[ファイルの内容] オプションを指定し、タスクを実行してインストールすることもできます。You can install the certs and provisioning profiles on the build server manually, or have the task install them by specifying the File Contents options.

Xcode automatic signing

(図 26) Xcode の自動署名
Xcode automatic signing
(Figure 26) Xcode automatic signing

Xcode 8 では、アーカイブ (.xcarchive) からアプリ パッケージ (IPA) をエクスポートする際に、エクスポート オプションの plist (図 27) を指定する必要があります。Xcode 8 requires specifying an export options plist (Figure 27) when exporting an app package (IPA) from an archive (.xcarchive). Xcode タスクでは、Xcode 8 または Xcode 7 を使用している場合に、エクスポート メソッドが自動的に特定されるようになりました。The Xcode task now automatically identifies the export method if you are using Xcode 8 or Xcode 7. ユーザーがエクスポート メソッドを指定することも、Xcode タスクからカスタムの plist ファイルを指定することもできます。You can specify the export method or specify a custom plist file from the Xcode task. Xcode 7 より古い Xcode バージョンを使用している場合、タスクはフォールバックして、古いツール (xcrun) を使用してアプリ パッケージが作成されます。If you are using an Xcode version older than Xcode 7, the task falls back to using the old tool (xcrun) for creating the app package.

Xcode export options

(図 27) Xcode のエクスポート オプション
Xcode export options
(Figure 27) Xcode export options

テストの機能強化 Test Improvements

Visual Studio 2017 によるテスト ビルドの実行 Run tests built using Visual Studio 2017

CI/CD パイプライン (図 28) の__テスト エージェントの配置__タスクや__機能テストの実行__タスクを利用し、Visual Studio 2017 のテスト エージェントをインストールし、Visual Studio 2017 で作成したテストを実行できるようになりました。Using the Deploy Test Agent and Run Functional Tests tasks in CI/CD pipeline (Figure 28), you can now install Test Agents for Visual Studio 2017 and run tests that were built using Visual Studio 2017.

Run tests

(図 28) テストの実行
Run tests
(Figure 28) Run tests

作業項目からのバグの検証Verify bugs from work item

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

Verify bugs from work item

(図 29) 作業項目からのバグの検証
Verify bugs from work item
(Figure 29) Verify bugs from work item

テスト ステップ操作の REST クライアント ヘルパーREST client helpers for Test Step operations

REST クライアントに追加されたヘルパー クラス (RestApi-Sample を参照) を使用して、テスト ケース作業項目でテスト ステップとテスト ステップの添付ファイルを作成、変更および削除できるようになります。You will now be able to create, modify, and delete test steps and test step attachments in Test Case work items using the helper classes we have added to the REST client (see the RestApi-Sample).

Web ランナーでの既存のバグの更新Update existing bugs from Web Runner

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

Test runner

(図 30) 既存のバグの更新
Test runner
(Figure 30) Update existing bug

Web ランナーでのテスト ケースの説明Test case description in Web Runner

テスト ケースの説明フィールドは、テスト ケースの実行を開始する前に満たす必要がある前提条件をキャプチャするためによく使用されていました。The test case description field was often used for capturing the prerequisites required before the test case execution can start. この更新プログラムでは、ユーザーは [説明を表示] オプションを使用して、Web ランナーでテスト ケースの説明情報を表示できるようになりました (図 31)With this update, you are now be able to view the test case description information in the Web runner by using the Show description option (Figure 31).

Test case description

(図 31) テスト ケースの説明
Test case description
(Figure 31) Test case description

テスト ハブの貢献ポイントTest hub contribution point

[テスト計画] ハブ内に新しい貢献ポイント ("ms.vss-test-web.test-plan-pivot-tabs") (図 32) が追加されました。これにより、開発者は、[テスト] および [グラフ] タブの横に表示される、ピボット タブとして拡張機能を作成することができます。We have added a new contribution point (“ms.vss-test-web.test-plan-pivot-tabs”) (Figure 32) within the Test plan hub to allow developers to write extensions as a pivot tab that appears next to the Tests and Charts tab.

Contribution point

(図 32) 貢献ポイント
Contribution point
(Figure 32) Contribution point

テスト成果物を削除するDelete test artifacts

このリリースより前のバージョンでは、削除オプションは作業項目に限定されていました。Prior to this release, your delete option was limited to work items. この更新プログラムでは、作業項目フォーム コンテキスト メニューの [完全に削除] オプション (図 33) を使用して、[テスト] ハブと [作業] ハブの両方からテスト成果物 (テスト計画、テスト スイート、テスト ケース、共有パラメーターおよび共有ステップ) を完全に削除できるようになります。With this update, you now have the ability to permanently delete test artifacts—test plans, test suites, test cases, shared parameters, and shared steps—both from the Test hub and the Work hub, by using the Permanently delete (Figure 33) option in the work item form context menu.

Delete test artifacts

(図 33) テスト成果物を削除する
Delete test artifacts
(Figure 33) Delete test artifacts

テスト計画のお気に入りFavorites for Test Plans

最も頻繁に使用するテスト計画をお気に入りに追加できるようになりました。You can now favorite the Test Plans you work with most frequently. [テスト計画] ピッカーには、すべて__のテスト計画および__お気に入り__に対応するタブが表示されます (図 34)In the __Test Plans picker, you will see tabs for All your Test Plans and Favorites (Figure 34). 星のアイコンをクリックすると、お気に入りの一覧にテスト計画が追加されます。Click the star icon to add a Test Plan to your list of favorites. お気に入りに追加されたテスト計画には、[テスト計画] ピッカーと、新しいアカウント ホーム ページの [お気に入り] タブからアクセスできます。The favorited Test Plans are accessible in the Test Plans picker and from the Favorites tab in the new account home page. また、タイトル フィールドで検索し、テスト計画をフィルターすることもできます (図 35)You can also filter Test Plans by searching on the title field (Figure 35).

Test plans

(図 34) テスト計画
Test plans
(Figure 34) Test plans

Test favorites

(図 35) テストのお気に入り
Test favorites
(Figure 35) Test favorites

管理対象自動テストのテスト影響分析Test Impact Analysis for managed automated tests

管理対象自動テストのテスト影響分析を、バージョン 2.* (プレビュー) バージョンの VSTest タスクのチェック ボックスで使用できるようになりました (図 36)Test Impact Analysis for managed automated tests is now available via a checkbox in the Version 2.* (preview) version of the VSTest task (Figure 36).

Test impact analysis

(図 36) テスト影響分析
Test impact analysis
(Figure 36) Test impact analysis

有効な場合、特定のコード変更を検証するために必要な、関連する一連の管理対象自動テストのみが実行されます。If enabled, only the relevant set of managed automated tests needed to validate a given code change, will run. テスト影響分析には最新バージョンの Visual Studio が必要になります。現在、管理対象自動テスト用の CI でサポートされています。Test Impact Analysis requires the latest version of Visual Studio, and is presently supported in CI for managed automated tests.

Firefox 用のテストとフィードバック拡張機能のサポートFirefox support for Test & Feedback extension

Firefox 用のテストとフィードバック拡張機能の一般提供の開始をお知らせします。We are happy to announce the General Availability of the Test & Feedback extension for Firefox. marketplace サイトから Firefox アドオンをダウンロードすることができます。You can download the Firefox add-on from our marketplace site.

注: Edge ブラウザーのサポートも準備中です。次の更新プログラムまでしばらくお待ちください。Note: Support for the Edge browser is also in the works; stay tuned for more updates.

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

変数グループのサポート Variable groups support in Release

変数グループは、変数とその値をグループ化し、複数のリリース定義にわたって利用できるようにするために使用されます。Variable groups are used to group your variables and their values to make them available across multiple release definitions. 変数グループのセキュリティを管理したり、リリース定義の変数グループから変数を表示し、編集したり、使用したりすることもできます。You can also manage security for variable groups and chose who can view, edit, and consume the variables from the variable groups in your release definitions.

ビルドとリリース ハブの [ライブラリ] タブを開き、ツール バーの [+ 変数グループ] を選択します (図 37)Open the Library tab in the Build & Release hub and choose + Variable group in the toolbar (Figure 37). 現在のところ、変数グループはリリース定義でのみ使用できます。Currently, variable groups can be consumed only in release definitions. 変数グループの Microsoft リリース管理のリリース定義に関する詳細をご覧ください。Find more information about variable groups, Release definitions in Microsoft Release Management.

下図のように、変数グループを作成 (図 37) して編集 (図 38) します。Create (Figure 37), then edit (Figure 38) a variable group, as shown below:

Create variable group

(図 37) 変数グループの作成
Create variable group
(Figure 37) Create variable group

Edit variable group

(図 38) 変数グループの編集
Edit variable group
(Figure 38) Edit variable group

リリースの複数のスケジュールMultiple schedules in releases

1 日に何度も作成するようにリリースをスケジュールしなくて済むように、Want to schedule your releases to be created more than once a day? リリース定義でスケジュールされた複数のトリガーを構成できるようになりました (図 39)You can now configure multiple scheduled triggers in a release definition (Figure 39).

Release schedule

(図 39) リリースのスケジュール
Release schedule
(Figure 39) Release schedule

ビルドとリリースのインライン サービス接続Inline service connections in Build and Release

この機能を使用すれば、[サービス] タブに移動しなくても、ビルド/リリース定義でサービス接続をすぐに作成することができます。これは、Docker、Jenkins、VMWare、および SCVMM などの、宣言的に定義されているすべての拡張機能で自動的に有効になります。With this feature, you can create service connections right in the build/release definition without navigating to the Services tab. This will be auto-enabled for all extensions which are defined declaratively, such as Docker, Jenkins, VMWare, and SCVMM.

これまでは、リリース定義でリンクできるのは、現在のプロジェクトからの成果物ソースのみでした。Until now, release definitions could only link artifact sources from the current project. これからは、別のプロジェクトからもビルド成果物 (図 40) をリンクできます。Now, you can link build artifacts (Figure 40) from another project as well. 成果物のリンク時に、プロジェクトのドロップダウンにアカウントのすべてのプロジェクトがリストされます。While linking an artifact, the project drop down will list all the projects in the account.

Link build artifacts

(図 40) ビルド成果物のリンク
Link build artifacts
(Figure 40) Link build artifacts

Azure リソース グループの機能強化Azure resource group improvements

このリリースより前のバージョンでは、Azure リソース グループ タスクでは、ARM テンプレート構文や、リソースを実際に展開せずに受け入れられるかどうかを検証できませんでした。Prior to this release, the Azure resource group task could not validate the ARM template syntax, or it would be accepted without actually deploying the resources. この機能強化により、検証のみ__という新しい展開モードを使用できるようになりました。これで、実際に Azure リソースを作成する前にテンプレートの作成に関する問題を見つけることができます。This enhancement allows a new deployment mode called __Validation Only, where you can find problems with the template authoring before creating actual Azure resources.

さらに、Azure リソース グループ タスクでは、増分または完全な展開も使用できるようになりました (図 41)Another enhancement to the Azure resource group task is to allow either incremental, or complete deployments (Figure 41). 以前のタスクでは増分モードを使用して ARM テンプレートが展開されました。Previously, the task deployed the ARM templates using the Incremental mode. ただし、リソース グループに存在するリソースのうち、テンプレートに指定されていないものは変更されません。However, it did not modify resources that existed in the resource group not specified in the template. 完全モードでは、テンプレートに含まれていないリソースが削除されます。Complete mode deletes resources that are not in your template. 既定は増分モードです。The default is incremental mode.

Azure resource groups

(図 41) Azure リソース グループ
Azure resource groups
(Figure 41) Azure resource groups

Azure CLI タスクAzure CLI task

新しい Azure CLI タスク (図 42) では、Windows、Linux および Mac などのクロス プラットフォーム エージェントでの Azure CLI コマンドの実行がサポートされます。The new Azure CLI task (Figure 42) supports running Azure CLI commands on cross platform agents like Windows, Linux, and Mac. このタスクでは、クラシックと ARM の両方のサブスクリプションがサポートされます。The task supports both Classic and ARM subscriptions. スクリプトの 2 つのプロビジョニング モード (1 つはリンクされた成果物、もう 1 つはインライン スクリプトとして) がサポートされます。It supports two modes of providing the script, one as a linked artifact and another as an inline script.

Azure CLI task

(図 42) Azure CLI タスク
Azure CLI task
(Figure 42) Azure CLI task

コード検索の更新 Code Search Update

TFS 2017 Update 1 では、コード検索サービスに Elasticsearch バージョン 2.4.1 が含まれています。In TFS 2017 Update 1, the Code Search service includes Elasticsearch version 2.4.1. コード検索サービスが TFS 2017 を実行するサーバーで構成されている場合、TFS のアップグレードの一部として、コード検索サービスが更新されます。If the Code Search service is configured on a server running TFS 2017, the Code Search service will be updated as part of the TFS upgrade. コード検索サービスがリモート サーバーで構成されている場合は、インストーラーに付属する__検索サービス パッケージ__の内容をリモート コンピューターにコピーし、readme ファイルの指示に従って、手動で検索サービスをアップグレードします。If the Code Search service is configured on a remote server, then copy the content of the Search Service Package provided with the installer to the remote machine and follow the instructions in the readme file to upgrade the search service manually.

コード洞察の機能強化 Code Insights Improvements

SonarQube MSBuild タスクSonarQube MSBuild tasks

SonarQube MSBuild タスクが、SonarSource によって提供される拡張で使用できるようになりました。SonarQube MSBuild tasks are now available from an extension provided by SonarSource. 詳細については、「SonarSource have announced their own SonarQube Team Services / TFS integration」 (SonarSource が独自の SonarQube Team Services / TFS 統合を発表) を参照してください。For more details, please read SonarSource have announced their own SonarQube Team Services / TFS integration.

管理の機能強化 Administration Improvements

新しい通知設定の操作New notification settings experience

通知は、チームが Team Services プロジェクトでのアクティビティを常に把握するのに役立ちます。Notifications help you and your teams stay informed about activity in your Team Services projects. この更新プログラムでは、ユーザーとユーザーのチームが受け取る通知をより簡単に管理できるようになりました。With this update, it’s now easier to manage what notifications you and your teams receive.

通知設定を管理するアカウントレベルの機能がプロファイル メニューに追加されました (図 43)You now have your own account-level experience in the profile menu for managing your notifications setting (Figure 43).

Notification settings

(図 43) 通知設定
Notification settings
(Figure 43) Notification settings

このビューでは、作成した個人のサブスクリプションを管理できます (図 44)This view lets you manage personal subscriptions you create (Figure 44). アカウント内のすべてのプロジェクトのチーム管理者によって作成されたサブスクリプションも表示されます。It also shows subscriptions created by team administrators for all projects in the account.

Manage personal subscriptions

(図 44) 個人のサブスクリプションの管理
Manage personal subscriptions
(Figure 44) Manage personal subscriptions

個人の通知設定の管理の詳細については、こちらを参照してください。Learn more about managing personal notification settings.

TfsConfig への addProjectReports の追加addProjectReports is now in TfsConfig

コマンド addProjectReports を使用して、レポートをチーム プロジェクトに追加できるようになりました。You can now use the command addProjectReports to add reports to your team projects. これは、以前はパワー ツールのコマンドでしたが、TfsConfig.exe コマンドに追加されました。This was a previous Power Tool command and is now part of the TfsConfig.exe command. 詳細については、「Upload reports to a team project (チーム プロジェクトへのレポートのアップロード)」を参照してください。For more information, see Upload reports to a team project.

チーム ルームの廃止 Team Room Deprecation

SlackMicrosoft Teams など、TFS および Team Services とも問題なく統合できる優れたソリューションが非常に多く存在するため、TFS と Team Services の両方のチーム ルーム機能を廃止することにしました。With so many good solutions available that integrate well with TFS and Team Services, such as Slack and Microsoft Teams, we made a decision to deprecate our Team Room feature from both TFS and Team Services. Team Services で作業を行う場合、計画を伝える新しい黄色のバナーが表示されます。If you are working in Team Services, you will see a new yellow banner appear that communicates our plan. 今年中には、チーム ルーム機能を完全に無効にする予定です。Later this year, we plan to turn off the Team Room feature completely.

使用できる代替方法がいくつかあります。There are several alternatives you can use. チーム ルームは通知ハブとチャットの両方で使用されます。The Team room is used both for a notification hub as well as for chat. TFS と Team Services は既に、Microsoft TeamsSlackHipChatCampfire および Flowdock を含む他の数多くのコラボレーション製品と統合されています。TFS and Team Services already integrate with many other collaboration products including Microsoft Teams, Slack, HipChat, Campfire, and Flowdock. Zapier を使用して、独自の統合を作成することも、表示する通知を非常に細かく制御することもできます。You can also use Zapier to create your own integrations, or get very granular control over the notifications that show up.

チーム サービスのチーム ルームの廃止に関する詳細をここでご覧ください。See more about the deprecation of Team Rooms in Team Services.

マークダウンでのファイル リンク サポートの停止 Markdown no longer supports file links

Update 1 では、ウェルカム ページ、チーム ダッシュボードのマークダウン ウィジェット、およびかんばんボードの完成の定義でマークダウンのファイル リンクがサポートされなくなりました。With Update 1, welcome pages, the markdown widget on team dashboards, and the Definition of Done on the Kanban boards will no longer support file links in their Markdown. 回避策として、マークダウンにテキストとしてファイル リンクを含めることができます。As a workaround, you can include your file link as text in the Markdown. 詳細については、マークダウンのガイダンスを参照してください。For more information, see Markdown guidance.

プロセス テンプレート エディターの発表 Announcing the Process Template Editor

Visual Studio 2017 のプロセス テンプレート エディターの拡張機能をリリースしました。We have released the Process Template Editor extension for Visual Studio 2017. この拡張機能では、プロセス テンプレートを便利な方法で表示し、更新できます。また、グローバル リストや作業項目の種類を更新するためのツールと作業項目フィールドの属性を表示するためのツールを利用できます。This extension provides a convenient method for viewing and updating process templates, as well as tools for updating global lists and work item types, and viewing the attributes of work item fields. これは TFS 2017 および TFS 2017 Update 1 サーバーに対して動作します。This works against TFS 2017 and TFS 2017 Update 1 servers.


既知の問題 Known Issues

TFS 2013 以前から TFS 2017 Update 1 build 15.112.26301.0 にアップグレードするとき、ビルドが機能しません。Build doesn't work when upgrading to TFS 2017 Update 1 build 15.112.26301.0 from TFS 2013 or earlier

  • 問題:Issue:

    この問題は、2017 年 3 月 7 日にリリースされた TFS 2017 Update 1 ビルド 15.112.26301.0 にアップグレードする場合にのみ発生します。Note that this issue only occurs if you upgraded to TFS 2017 Update 1 build 15.112.26301.0, released on 7 March, 2017. 3 月 9 日にリリースされたビルド 15.112.26307.0 にアップグレードする場合、この問題は発生しません。If you upgraded to build 15.112.26307.0, released on 9 March, you will not encounter this.

    TFS 2013 (RTM または何らかの更新) 以前からアップグレードした後、"counter with name TaskReferenceId does not exist" (TaskReferenceId という名前のカウンターは存在しません) というエラーがビルドに表示されます。After upgrading from TFS 2013 (RTM or any update) or earlier, Build shows an error of "counter with name TaskReferenceId does not exist".

  • 回避策:Workaround:

    アップグレードしたコレクション データベースで次のスクリプトを実行します。Run the following script on your upgraded collection databases:

    INSERT  tbl_Counter (PartitionId, DataspaceId, CounterName, CounterValue)
    SELECT  DISTINCT
              dpm.PartitionId,
              ds.DataspaceId,
              N'TaskReferenceId',
              1
      FROM    tbl_DatabasePartitionMap dpm
      INNER LOOP JOIN Task.tbl_Hub h
      ON      h.PartitionId = dpm.PartitionId
      INNER LOOP JOIN tbl_Dataspace ds
      ON      ds.PartitionId = dpm.PartitionId
              AND ds.DataspaceCategory = h.DataspaceCategory
              AND ds.DataspaceIdentifier <> '00000000-0000-0000-0000-000000000000'
      WHERE   dpm.PartitionId > 0
              AND dpm.HostType = 4
              AND NOT EXISTS (
                  SELECT  *
                  FROM    tbl_Counter c
                  WHERE   c.PartitionId = dpm.PartitionId
                          AND c.DataspaceId = ds.DataspaceId
                          AND c.CounterName = N'TaskReferenceId'
              ) 
    

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

  • 問題:Issue:

    1.3.1 より前の Git LFS バージョンのサポートは終了しました。Git LFS versions before 1.3.1 are no longer supported.

  • 回避策:Workaround:

    Git LFS を使用している場合は、Git LFS バージョン 1.3.1 以降に更新する必要があります。If you are using Git LFS, you must update to Git LFS version 1.3.1 or higher. これより古いバージョンの LFS クライアントは、このバージョンの TFS で行われた認証に関する変更と互換性がありません。Older versions of the LFS client are not compatible with authentication changes in this version of TFS.

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

  • 問題:Issue:

    従来の複数値コントロールなど、作業項目フォームで従来のカスタム コントロールを使用する場合、作業項目フォームをレンダリングできないことがあります。If you use a legacy custom control in your work item forms, such as the legacy multi-value control, your work item forms may fail to render.

  • 回避策:Workaround:

    コントロールを最新バージョンに更新する必要があります。You will need to update to the latest version of your control. TFS 2017 Update 1 の最新の複数値コントロールは、こちらで見つけることができます。You can find the latest multi-value control for TFS 2017 Update 1 here.

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

作業項目で読み取り専用フィールドが非表示にならないWork item forms do not hide read only fields

  • 問題:Issue:

    HideReadonlyEmptyFields プロパティを true に設定した古い作業項目をレイアウトで使用していると、読み取り専用で空のフィールドが非表示になりません。If you use old workitem form with HideReadonlyEmptyFields property set to true in the layout, your form will fail to hide read only and empty fields.

  • 回避策:Workaround:

    この問題の回避策はありません。There is no workaround at this time. この問題は TFS 2017 Update 2 で修正される予定です。This will be fixed in TFS 2017 Update 2.

作業項目フォームの表示がダーティになるWork item forms become dirty on viewing

  • 問題:Issue:

    これは、TFS 2017 Update 1 の IE 11 で新しい作業項目フォームを表示したときに固有の問題です。This issue is specific to IE 11 on TFS 2017 Update 1 when opting into the new work item form. ユーザー プロファイルがフランス語、韓国語、ロシア語、トルコ語、日本語、または中国語に設定されていて、作業項目が ID に割り当てられている場合、作業項目フォームの表示がダーティになります。If you have your profile set to French, Korean, Russian, Turkish, Japanese, or Chinese, and the work item is assigned to any identity, you will see the work item form as dirty when viewing the work item. 作業項目を保存した場合、[担当者] フィールドが割り当てなしに設定されます。If you save the work item, the Assigned To field will be set to unassigned.

  • 回避策:Workaround:

    IE11 以外の他のブラウザーを使います。Use another browser besides IE11. IE11 を使っている場合は、[作業項目] ツールバーの[元に戻す]/[更新] をクリックすると、[担当者] が正しい値に戻ります。If you are using IE11, click undo/refresh from the work item toolbar to restore the correct Assigned To value.

アップストリーム NPM パッケージのキャッシュが失敗するCaching of upstream NPM packages fail

  • 問題:Issue:

    TFS サーバーがプロキシを使用している場合は、アップストリーム NPM パッケージのキャッシュが失敗します。If your TFS server is behind a proxy, the caching of upstream NPM packages will fail.

  • 回避策:Workaround:

    TFS サーバーが企業プロキシを使用している場合は、TFS サーバーの web.config (%ProgramFiles%\Microsoft Team Foundation Server 15.0\Application Tier\Web Services\web.config) に次の変更を加えます。If your TFS server is behind a corporate proxy, make the following changes to your TFS server web.config (i.e. %ProgramFiles%\Microsoft Team Foundation Server 15.0\Application Tier\Web Services\web.config).

    この構成ブロックを変更します。Replace this configuration block:

      <!-- ASP.NET Proxy Usage for HttpWebRequests 
            "usesystemdefault" 
               false - stops the server using the default proxy configuration or proxy
                     auto-detection. 
            "bypassonlocal"
               true - this tells all requests to a local address to ignore configured proxies.
        -->
      <defaultProxy>
        <proxy usesystemdefault="False" bypassonlocal="True" />
      </defaultProxy>
    

    以下に置き換えます。With this:

      <defaultProxy useDefaultCredentials="true" />
    

コード ドロップダウン メニューに正しくないバージョン コントロール ページが表示されるCode dropdown menu shows incorrect Version Control pages

  • 問題:Issue:

    下図 (図 45) に示すように、Git リポジトリの管理ページにアクセスし、[コード] ハブをクリックすると、[履歴] リンクではなく、[変更セット] リンクと [シェルブセット] リンクが表示されます。If you navigate to the admin page on a git repository, as shown in the image below (Figure 45), and click on the Code hub, they will see the Changesets and Shelvesets links, instead of the History link.

    Code dropdown menu

    (図 45) [コード] ドロップダウン メニュー
    Code dropdown menu
    (Figure 45) Code dropdown menu

  • 回避策:Workaround:

    Git リポジトリの管理ページ以外のページに移動すると、正しいリンクが表示されます。Navigate out of the git repository admin page and you will see the correct links.

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

  • 問題:Issue:

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

  • 回避策:Workaround:

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

公開 URL が正しく設定されていない場合、拡張機能を取得できないか、拡張機能が正しく動作しません。Extensions cannot not be acquired or will not function correctly if Public URL is not set correctly

  • 問題:Issue:

    Visual Studio Marketplace から拡張機能を取得できません。Extension acquisition from Visual Studio Marketplace will fail.

    既に取得している拡張機能が正常に機能しない可能性があります。Already acquired extensions are likely to not function as expected.

  • 回避策:Workaround:

    この問題は TFS 2017 Update 2 で修正されたため、アップグレードすることをお勧めします。This is fixed in TFS 2017 Update 2 and we recommend upgrading. Update 1 で実行できるようにする必要がある場合は、企業環境内の別のシステムから URL に到達できるように、TFS サーバー管理者コンソールで ‘公開 URL’ を設定します (図 46)If you need this to work on Update 1, set the ‘Public URL’ in the TFS Server Administrator Console such that the URL is reachable from another system within your corporate environment (Figure 46).

Code menu

(図 46) コード メニュー
Code menu
(Figure 46) Code menu