注意事項:このポストで紹介されている機能については今後三週間で順次展開されます。
私たちは皆さんのTeam Servicesのエクスペリエンスの向上に重点を置いてきました。 このスプリントには、モバイルワークアイテムフォームの改善やカスタムバックログレベルなど、いくつかの項目が含まれています。 これらの新機能の紹介を始めます！
Delivery Plansの追加により、リリース計画がよりカスタマイズ可能になっています。 これにより、計画にどの作業項目が表示されるかをより詳細に制御できます。 基準とするフィールドを計画の一部にできるため、常に誰もが同じ視点で確認できます。 以下の例では、タグ値(Argo)を含む特定の作業項目タイプ(バグ)のみを表示するフィールド条件を使用していることがわかります。
私たちのモバイルディスカッションのエクスペリエンスは、コメントを追加するためのモバイルフレンドリーで合理的なエクスペリエンスを提供するように最適化されています。 ディスカッションは、モバイルデバイスで行われる最も一般的なアクションです。 私たちはあなたの新しいエクスペリエンスについてどう考えているのか、聞きたいです！
あなたのスマートフォンから別のユーザに作業項目を割り当てることが非常に簡単になりました。 このコントロールは、ユーザーのフィルタリング、検索、および選択時に、優れたモバイルエクスペリエンスの提供に最適化されています。
ユーザーは、新しいバックログレベルを追加して、作業項目の階層を管理し、作業項目の種類に合った方法で名前を付けることができます。 ユーザは、ストーリーやフィーチャなど、既存のバックログレベルの名前を変更したり、再作成することもできます。詳細はCustomize your backlogs or boards for a processを参照してください。
ユーザーは自分のプロジェクトにカスタムIDフィールドを追加できるようになりました。 これにより、ユーザは“Assigned To”のような、人を選択するためのフィールドを追加のフィールドとして定義することができるようになります。 この最初のリリースでは、Team Servicesアカウントのすべてのユーザーが各IDフィールドの有効な値になります。
あなたが複数のチームのメンバーであれば、My Pull Requestsビューにリストされているチームに割り当てられているすべてのPRが表示されます。 これにより、My Pull Requestsに訪れるだけであなたのプレートの見るべきすべてのPRをワンストップで確認できます。
将来のリリースでは、Codeの下にPull Requestハブを追加して、単一のプロジェクトのあなたのPRを全て確認できるようにします。
新しいCommentsポリシーでpull request内のすべてのコメントが対処されているか確認できるようになりました。 このポリシーを有効にすると、アクティブなコメントがあった場合、すべてのコメントが解決するまでPRの完了がブロックされます。PR作成者にコメントを残しても、プルリクエストを楽観的に承認するレビュー担当者は、マージしたい作者がコメントを見落とさないようにできます。
エージェントがアップグレードされると、キューおよびプール管理ポータルにアップグレードのステータスが示されます。
少し前にGitHubリポジトリへのCIビルドの提供を始めました。 GitHubにプルリクエストが作成されると、新しいビルドトリガーが自動的に作成されます。 ビルドが完了すると、あなたのGitHubプルリクエストにコメントが追加されます。
セキュリティのため、ソースとターゲットの両方が同じリポジトリ内にある場合にのみプルリクエストを作成します。フォークされたレポジトリからのプルリクエストには対応しません。
あなたが意識できるように、私たちは、すぐにout-of-the-box notificationsを次回のアップデートまでの三週間以内にデフォルトで有効にする予定です。 この機能が既にアカウントで有効になっている場合は、影響はありません。 この機能を有効にしていない場合は、次回のアップデートでデフォルトで有効になります。 アカウント管理者にはこの機能をオプトアウトするオプションがあります。
管理者、またはアカウントの拡張機能を管理する機能を持つアカウントは、拡張機能のインストール、アンインストール、有効化、無効化、またはアカウントでの注意が必要な場合に自動的に通知されるようになりました。 これは、複数の人が拡張機能を管理する責任を負っている大規模なアカウントで特に役立ちます。 管理者は、プロファイルメニューのNotificationに移動し、トグルスイッチをオフにすることで、これらの通知をオフにできます。
管理者は、アカウント内の内線関連イベントのカスタムサブスクリプションの定義もできます。 たとえば、管理者は、アカウントで拡張機能が更新されるたびに通知を受け取れます。
ユーザーは、拡張要求に関する自動通知をオフにすることもできます。
展開が成功した後に自動的にトリガーされたデプロイを、別のリリース環境への展開時、自動的に承認できます。 すべての展開を承認する場合、(同じ承認者を持っていれば)一連の展開を承認することができます。
デプロイメントを承認するために必要なデプロイメント承認者が "userA"と "userB"に設定されている、DevとTestという2つの環境があるとします。 Testのポリシーが以下のように設定されている場合、デプロイ時には、userAとuserBがDevのみを承認すれば十分です。 テストへの展開は自動的に承認されます。 Testへの導入が手動で開始された場合、適切な承認を得るために導入前に承認が必要になります。
今回のアップデートでは、project.jsonに加えて* .csprojファイルをサポートする.NET Core Taskを強化しています。 ビルド・エージェントでVisual Studio 2017を使用して、csprojファイルを使用して.NET Coreアプリケーションを構築できるようになりました。
これらの機能はフィードバックを取りながらワークフローを改善するのに役立つと考えていますが、あなたの意見を聞くことが大好きです。 WebポータルでSmileアイコンや嫌な顔アイコンを選択したり、Team Services Developer Communityから他のコメントを送ることを躊躇しないでください。 いつものように、あなたが私たちに見せたいものについてのアイデアを持っているなら、UserVoiceであなたのアイデアを追加したり、既存のものに投票してください。
ありがとうございました。
Aaron Bjork