注意事項:これらの強化点は次の三週間までにわたって順次展開されます。
私たちはこのスプリントでいくつかの機能強化を行いました。紹介しましょう！
チームに割り当てられたプルリクエスト機能はとても簡単に使えます。 PRが作成または更新されると、PRに割り当てられたすべてのチームのすべてのメンバーに電子メールアラートが送信されます。
この機能はプレビューであり、アカウント管理者がPreview featuresパネル(プロファイルメニューの下にあります)から有効にしてください。
for this accountで有効にした後、Team expansion for notificationsでチームへの通知機能を有効にできます。
将来のリリースでは、PRをAzure Active Directory(AAD)のグループおよび、チームを含むAADグループに割り当てる機能を追加します。
ブランチポリシーを使用しているチームでは、pull requestを表示しても、必要なアクションの選択がわかりづらいことがあります。 主な行動を促す言葉がCompleteボタンであったとして、それは完了する準備ができているのでしょうか？ページを閲覧している人に関する情報と設定済みのブランチポリシーの状態を使用して、PRビューはそのユーザに最も合理的な行動を促すようになりました。
ブランチポリシーが設定されていて、まだ通過していない場合、CompleteボタンがAuto-complete機能の使用を提案します。 ポリシーでブロックされている場合は、PRを正常に完了できない可能性があるため、ポリシー条件を満たすとPRを完了するオプションを提供します。
レビュワーにとって、PRよりもPRを承認したいと思う可能性が高いと考えられるので、まだ承認されていない場合、ApproveボタンがメインのCTAとして強調表示されます。
承認されると、レビュワーがPRを完了した人物である場合、レビュワーにはComplete(またはAuto-complete)ボタンがCTAとして強調表示されます。
少数のコメント以上のPRでは、すべての会話の追跡は難しいかもしれません。 ユーザーがコメントをよりうまく管理できるように、いくつかの強化機能で解決までのプロセスを簡素化しました。
-
どのPRのヘッダにも、解決されたコメントの数が表示されます。
-
コメントの位置からシングルクリックで解決済みにできます
-
もしも、解決するまでの間に追加するコメントがあれば、一回のボタンクリック動作で解決とコメントを追加できます。 reply and resolve
-
コメントが解決済みになれば、すべてのコメントが解決するまでカウントが加算されます。
-
概要のフィルタが改善され、さまざまなコメント状態によるフィルタリングが可能になり、各フィルタオプションに対応するコメント数が表示されます。
Pull Request detailsビューにおいてUpdatesタブが強化され、強制プッシュが発生したときと、ベースコミットが変更されたことが表示されるようになりました。 これらふたつの機能は、PRを完了する前にトピックブランチの変更をリベースする時、非常に便利です。 レビュー担当者は何が起こったかを正確に知るための十分な情報がわかります。
高度なフィルタリングオプションを使用して、コミット履歴の結果をフィルタリングできるようになりました。 コミットを次の方法でフィルタリングできます。
- full history (完全な履歴)
- full history with simplified merges (簡潔にマージされた完全な履歴)
- first parent (最初の親)
- simple history (This is the default filter setting) (簡単な履歴(既定のフィルタ設定))
少し前からGitHubリポジトリのCIビルドを提供しました。今回、新しいトリガーが追加され、GitHubのpull request時に自動的にビルドが実行されるというトリガーが作れるようになりました。ビルドが完了すると、GitHubのpull requestにコメントが返されます。
セキュリティのため、ソースとターゲットの両方が同じリポジトリ内にある場合にのみpull requestのビルドを実行します。フォークされたレポからはpull requestを作成しません。
古いプールの作業ディレクトリとリポジトリを定期的にクリーンアップするようにエージェントプールの設定ができるようになりました。 これにより、エージェントのディスク領域が不足する可能性が低減されます。 メンテナンスはマシンごとではなく、エージェントごとに行われます。 1台のマシンに複数のエージェントがある場合、ディスクスペースの問題が発生する可能性があります。
エージェント選択では、ビルドまたはリリース用のエージェントを割り当てるときに、マシンの使用状況を考慮に入れるようになりました。 これにより、現在使用中の他のエージェントを持つマシン上のエージェントを選択する前に、アイドル状態のマシン上のエージェントにビルドまたはリリースが送信されます。
Visual Studio Test taskでは、エージェントフェーズを使用して自動テストを実行できるようになりました。
ビルド、リリース、およびテストで統一された自動化エージェントが用意されました。 これにより、次のような利点がもたらされます。
- テストニーズに合わせてエージェントプールを活用できます。
- 単一のエージェントベースの実行、マルチエージェントベースの分散テストの実行、または異なるブラウザなどのテストを実行するためのマルチ構成の実行など、同じVisual Studio Testタスクを使用して、さまざまなモードでテストを実行します。
詳細は このブログを読んでください。
拡張機能の作成者はタスクで複数のバージョンの拡張機能を作成できるようになりました。
詳細はReference for creating custom build tasks within extensions.を読んでください
任意のユーザーまたはグループに、アカウントの拡張機能を管理する権限を付与できるようになりました。 以前は、アカウント管理者だけが拡張機能の要求の確認、拡張機能のインストール、無効化、またはアンインストールがことができました。 この権限は管理者がMarketplaceメニューを開き、Manage extensionsを選択してから、Securityボタンをクリックして、Extensions管理ハブで設定します。
また、このスプリントでは新たに拡張機能の追加を要求したユーザーは、その要求が承認または拒否されたときに電子メールで通知されるようになりました。
ユーザーからよく報告された問題に対処するために、パッケージ管理のユーザーエクスペリエンスを更新して、今後のパッケージライフサイクルのためのスペースをPackagesハブに確保しました。
Team ServicesをAzure Active Directory(AAD)条件付きアクセスポリシーの対象として明示的に選択できるようになりました。 これにより、企業はユーザーがどこで、どのようにVSTSにアクセスできるかを制御できます。詳細は Microsoft Azure documentation site を読んでください。
Team Servicesのすべてのアカウントをエージェントベースの価格モデルからパイプラインベースの価格モデルに移行しました。 この新しいモデルでは、ユーザーは自分のアカウントで設定されたパイプラインの数だけ同数のビルドまたはリリースを同時に実行できます。この制限を超える追加のビルドおよびリリースはキューに入れられ、前のビルドおよびリリースが完了するまで待ちます。Pipelines queue機能は、ビルドやリリースがどこにあるかをより詳細に表示することができます。
Pipelines queueを起動すると、次の情報が表示されます。
- パイプラインが実行されるのを待って、待機キュー内の位置をビルドおよび解放します。
- 現在、ビルドとリリースがパイプラインのどの位置にいるかわかります。
あなたのビルド/リリースがパイプラインを待っている間に、ビルド/リリースログページ内からこのビューを直接起動し、パイプラインキュー内の現在の位置やその他の詳細を見つけることもできます。
これらの機能はフィードバックを受けながら、ワークフローを改善するのに役立つと考えていますが、あなたの意見を聞くことが大好きです。 WebポータルでSend a Smileや、[Team Services Developer Community]を通じて他のコメントをお送りください。
ありがとうございました。
Jamie Cool