クリスマス休暇中の展開をスキップしたため、今回Sprint 128と129の両方の機能をまとめて展開しています。Visual Studio Team Services(VSTS) Sprint 129のアップデートでは、チーム全体に恩恵を受けられるいくつかの機能強化があります。特に、GitHub.comのリポジトリのフォークされたリポジトリからpull requestを作成したり、GitHub.comやGitHub Enterpriseの公式ビルドソースからフォークしたリポジトリのpull requestの継続的インテグレーションを強化したりしています。
そのほかの機能強化ハイライトです。
- ステークホルダーのAnalyticsウィジェットビュー - ステークホルダーに分析に基づく対話をもたらします
- pull requestマージコミットビュー - PRでのマージコミットを明確にします
- 作業項目のAreaとIterationの提案 - 素早く、適切なAreaとIterationを選択できます
- Wikiの検索および、印刷が一般提供 - Wikiは検索と印刷を使って、チームのナレッジの維持に役立ちます
- Azure ADグループを直接パーミッションに設定 - Azure ADの既存のグループを使ってパーミッションを簡単にします
注意事項
ここで議論されている機能は今後二週間にわたって順次展開されます。
Analytics拡張機能をインストールすると、6つの強力なウィジェットがウィジェットカタログに追加されます：累積フローダイアグラム、リードタイム、サイクルタイム、ベロシティ、バーンダウンおよび、バーンアップ。今回の更新で、無料のStakeholderライセンスを持っている人にも、すべてのAnalyticsウィジェットの内容が閲覧できます。
ただし、Analytics ODataエンドポイントまたはPower BIを使用してAnalyticsに接続するには、依然としてBasicライセンスが必要です。
VSTS Power BI Desktop Connectorのデフォルトビューは、VSTSデータをすぐ閲覧するために役立ちます。一般的な履歴定義で追加のビューを追加して、傾向分析やバグ分析をより簡単に実行できるようにしました。詳細については、connecting to VSTS with Power BI Data Connectorを参照してください。
2月にリリースされるPower BI Desktopでは、独自のビューを作成する機能が追加され、Power BIで必要な特定のデータがさらに簡単に処理できるようになります。
Pull request差分ビューは、ソースブランチで導入された変更を強調表示する際に優れています。ただし、ターゲットブランチを変更すると、diffビューが予想外に見えることがあります。View merge commitという、Pull Requestの差分を表示するための"Preview"という新しい差分ビューが使用可能になりました。このマージコミットは、マージの競合をチェックし、pull request時のビルドチェックのために作成され、最終的にPull Requestが完了したとき、マージコミットのアウトラインに反映します。ターゲットブランチの変更が差分に反映されていない場合、マージコミットの差分は、ソースブランチとターゲットブランチの両方の最新の変更を確認するとき便利です。
View merge commitコマンドと併用すると便利な別のコマンドとして、Restart merge(同じコマンドメニューで利用可能)です。Pull Requestが最初に作成されてからターゲットブランチが変更された場合、このコマンドを実行すると、新しいプレビューマージコミットが作成され、マージコミット差分ビューが更新されます。
Pull Requestに関する追加情報をレビュー担当者に伝えることが重要な場合もあります。進行中の作業や、今後のリリースのためのPull Requestであることがあります。そのような場合、タイトルに追加のテキスト(おそらく "[WIP]"プレフィックスまたは "DO NOT MERGE")を追加しています。さらにラベルを使用すると、Pull Requestに重要な詳細を伝え、Pull Requestを整理するために役立つ余分な情報のタグ付けができます。
将来のリリースでは、ラベルをさらに便利にするために、Pull Requestをラベルで簡単にフィルタ処理できるようにする予定です。
ブランチポリシーの自動補完は、ブランチポリシーを使用するチームにとっては便利な機能ですが、オプションのポリシーを使用する場合、pull requestがブロックされているかどうか確実なことは分かりません。pull requestに対して、自動補完を設定すると、設定したポリシーのうち完了したものからリストがコールアウトボックスに表示されます。pull requestがマージされるまで、各要件が満たされるごとに、残りの要件が一つずつリストから削除されます。
pull requestのコメントに数式や数式を含める必要がありますか？インラインコメントとブロックコメントの両方を使用して、コメントにTeX書式の数式が含められます。詳細については、サポートされている数式のリストを参照してください。
前はGitリポジトリを見ることができる人なら誰でもそのpull requestを扱うことができました。pull requestの作成とコメントへのアクセスを制御するリクエストを取得するために、Contribute to pull requestsという新しい権限を追加しました。以前にReadアクセス権を保持していたすべてのユーザーおよびグループには、デフォルトでこの新しいアクセス許可も与えられます。この新しいアクセス許可の導入により、管理者は柔軟性と制御性をさらに高めることができます。Readersグループが本当に読み取り専用である必要がある場合は、Contribute to pull requests権限を拒否すれば、pull requestの拒否ができます。
この変更に関連して、誰が名前および、説明の編集、pull requestに投票できるか、というロジックを更新しました。これまではリポジトリを読むことができる人ならば誰でも可能でした。今回から、pull requestの作成者かContribute権限を持っているメンバーである必要があります。リポジトリへの主要貢献者には、必要な柔軟性を引き続き提供します。カジュアルな貢献者は、コメントスレッドに重点を置くことができますが、pull request自体を変更することはできません。
詳細については、quickstart documentation for setting repository permissionsを参照してください。
ブランチポリシーを使用すると、チームは高品質なブランチの状態を維持し、pull requestワークフローのベストプラクティスに準拠できます。今度は、pull requestステータスのAPIとブランチポリシーを使用して、カスタムツールをpull requestワークフローに統合できます。サードパーティ製のCI / CDソリューションと統合している場合でも、独自の内部プロセス要件を適用している場合でも、ステータスAPIが役立ちます。 詳細については、コード、サンプル、ドキュメントを参照してください。
同じAreaまたはIterationで作業し、作業項目を移動するときに階層を繰り返し参照することが一般的です。AreaとIterationのパスコントロールには最近使用した値のリストがSuggestionsとして追加され、設定と移動に素早くアクセスできます。
さらに、Iterationの対象日付が名前の右側に含まれているため、作業項目を解決しなければならない期間を素早く判断できます。
VSTSでGitHubでフォークされたリポジトリのpull requestでも自動的にビルドできるようになりました。これにより、変更がマージされる前にビルドとテストが行われ、成功するかどうか確認できます。デフォルトでは、ビルド定義に関連付けられたsecretsは、フォークリポジトリのpull request時のビルドには使用できません。 詳細については、security considerationsを参照してください。
GitHub Enterpriseをバージョン管理に使用している場合、継続的インテグレーション(CI)ビルドを実行するためのVSTSとの連携が向上しました。以前は、External Gitコネクタを使用してコード変更をポーリングすることしかできませんでした。ポーリングではサーバーへの負荷が増大し、ビルドが開始されるまでに遅延が発生する可能性がありました。VSTSの公式GitHub Enterpriseサポートを使えば、チームのCIビルドがすぐに開始されます。さらに、LDAPや組み込みアカウントなどのさまざまな認証方法を使用して認証を構成できます。
テンプレートの1つを使用して新しいビルド定義を作成すると、デフォルトでhosted agentキューが選択されます。たとえば、AntテンプレートとMavenテンプレートのデフォルトはHosted Linuxキューになります。XcodeとXamarin.iOSのテンプレートは、デフォルトでHosted macOS Previewになります。ASP.NET Coreテンプレートの既定値はHosted VS2017です。もちろん、キューを自分の好みに変更することはできますが、このデフォルトでは新しいビルドプロセスを定義するときに設定変更する時間が節約され、適切なエージェントキューを再設定する必要はありません。
最新バージョンのTest＆Feedback extensionでは、Chromeブラウザを通じてデスクトップアプリケーションのスクリーンショットをキャプチャのサポートを開始しました。ブラウザの拡張機能をインストールして、テストするアプリケーションを選択し、スクリーンショットを撮ったり、注釈を付けたり、バグやタスクを作成したりします。
時間が経つとテスト資産が肥大します。大規模なアプリケーションの場合、テスト結果は容易に数万という数値になります。以前のスプリントでは、TestタブにBuild and Release - Container(DLL)とOwner(コンテナ所有者)の2つの新しいフィルタを追加しました。このエクスペリエンスをさらにリッチにするために、Test Nameでフィルタリングする機能を追加しました。関心のあるテストをすばやく検索できます。さまざまなフィルタが累積して追加されます。
去年、ビルド、リリース、テストの各段階でエージェントを統一するための旅を始めました。これは、WinRMベースのDeploy Test AgentとRun Functional Testsタスクの使用に関連するさまざまな苦労点に対処することを目的としていました。今までこれらのタスクがカバーしていた次のようなテストのニーズにはVisual Studio Test(VSTest)タスクで対応できます。
- Unit tests
- Functional (UI/non-UI) tests
- MSTestでのテスト
- サードパーティのフレームワークベースのテスト
- アセンブリベースのテスト仕様および、Test Plan / Test Suiteでのテスト実行
- 複数のエージェントでの分散と、一つのエージェントでの実行
統一されたエージェントアプローチにより、管理者はCI / CDで使用されているすべてのマシンを統一的に管理することもできます。
直近のいくつかのスプリントで、この機能を有効にするためにいくつかの重要な要素を提供しました。
- エージェントをUIテスト用に設定する
- Visual Studio Test Platform Installerを使用すると、Visual StudioがプリインストールされていなくてもVSTestタスクを実行できます
- ビルドとリリースの定義で、複数のフェーズで作成でき、フェーズごとに異なるエージェントキューを使用できます
- 自動化されたテストケースは、VSTestタスクを使用してテストハブから実行できます
以上の条件がすべて整ったので、私たちはこれら2つのタスクを廃止する用意ができました。廃止予定のタスクを使用する既存のビルド/リリース定義は引き続き機能しますが、今後の機能拡張もあるため、時間の経過とともにVSTestへ移行することをお勧めします。
12月に公開されたWiki検索がプレビューの後、一般提供開始状態になっています。お気に入りのWikiページをタイトルやコンテンツでコードや作業項目の横に並べて検索できます。
Wikiはさまざまなコンテンツに使用できます。Wikiのコンテンツを印刷して余分な時間に読んだり、ペンや紙を使ってコメントを追加したり、オフラインのPDFコピーをVSTSプロジェクトの外部の人と共有したりすることが便利な場合があります。このような場合、ページのコンテキストメニューをクリックし、Print pageを選択します。 この機能は、提案に基づいて優先順位が付けられました。
現在のリリースでは、Firefoxをサポートしていません。
キーボードショートカットを使用して、Wikiでの一般的な編集や表示操作をさらに高速に実行できるようになりました。
たとえば、ページの表示中にサブページの追加、編集、または作成ができます。
ページの編集中に、即時保存、名前を付けて保存、閉じる、または破棄ができます。
ショートカットは例えば太字の場合はCtrl + B、イタリックの場合はCtrl + I、リンクする場合はCtrl + Kなどの標準的なショートカットに準拠しています。詳細については、キーボードショートカットの完全なリストを参照してください。
Marketplaceのすべての有料VSTS拡張機能とVSサブスクリプションに対して、Pricingタブの中に電卓が追加されました。選択された数量に対応する価格を、通貨で、拡張ページから離れることなく把握できるようになりました。
注：最終価格は購入に使用されたAzureサブスクリプションにまとめて請求されます。
VSTS内のグループの余分な管理レイヤーの作成をさせないようにするため、Azure Active Directoryグループを直接パーミッションとして使用できるようになりました。これにより、VSTSグループとAzure ADグループが同じレベルで使用できるようになります。
詳細については、アクセス許可とグループのドキュメントを参照してください。
従来のAzureポータル(manage.windowsazure.com)が廃止されました。これで、Azureポータル(portal.azure.com)のアカウントブレードのConnectコントロールからVSTSアカウントをAzure Active Directoryに接続または切断できます。詳細については、Azure ADに接続するためのドキュメントを参照してください。
Microsoftアカウント(MSA)ベースのVSTSアカウントの場合、アカウントに複数のユーザーが含まれており、なおかつ単一のProject Collection Administratorによって管理されている場合、Securityタブに警告を表示するようにしました。現在の管理者が退社した場合、VSTSのアカウントがロックアウトされるのを避けるために、複数の管理者を置くことをお勧めします。このメッセージは推奨事項であり、既存の設定には影響しません。
これらの機能についてどう思っているかお聞きしたいと思います。フィードバックメニューを使用して、優先順位を付けたいと思っていることに関するアイデアがある場合は、問題を報告するか、提案をしてください。
アドバイスや回答が必要な質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Jamie Cool