Last Update: 8/4/2017
Sprint 121 Updateでは、Visual Studio Team Services(VSTS)にネイティブWikiのほかに、あなたのワークフローにより一貫性を持たせ、統合できるような新機能を用意しました。いくつかのハイライトを紹介します。
- Wikiがパブリックプレビュー - チームメンバーがプロジェクトを理解し、使用し、貢献できるようにします。
- Release機能にAnsibleを統合 - Ansibleのplaybookを保有ノードで実行します。
- ブランチ管理 (古いもの,再作成,プッシュページ) - 古くなったブランチ、削除されたブランチを再作成、pushのビューをわかりやすく
- Pull Request拡張がパブリックプレビュー - 新しいAPIを使って、Pull Requestワークフローを拡張する
- テスト追跡性の改善 - テストの作業項目のデフォルトと関連付けを改善
- boards と test casesでフィルタリングの一貫性を保つ - 作業項目の発見が素早く簡単になります。
また、VSTS内のフィードバックをお寄せいただき、製品の改善に役立てています。 製品内のフィードバックの詳細については、下記のFeedbackセクションをご覧ください。
注意事項
ここで紹介している新機能は今後三週間にわたって順次展開されます。
継承されたプロセステンプレートのコピーを作成して、新しいプロセスを開始するために使用したり、プロセスの変更前の準備としてテストしたりできます。
1つ、または複数のチームプロジェクトで使用されているプロセスを変更すると、これらのチームプロジェクトはそれぞれ、直ちに変更が実施されます。とはいえ、いつもそれが望まれるとは限りません。プロセステンプレートの変更を確認し、すべてのチームプロジェクトにロールアウトする前に変更内容をテストする必要があります。 次の手順でこれを行うことができます：
- 変更したいプロセステンプレートの複製をつくります。
- 複製テンプレートに変更を加えます。チームプロジェクトにプロセスが使われるまで、だれにもこの変更は影響しません。
- 変更点をテストするとき、もしまだプロジェクトがない場合は複製されたプロセスからテストプロジェクトを作ります。すでにテストプロジェクトを作成している場合は、コンテキストメニューからChange team project to use <process name>オプションを使用して、テストプロジェクトのプロセスを変更できます。
- 変更したプロセステンプレートを展開するタイミングがきました。変更されたプロセステンプレートが必要なチームプロジェクトのプロセスを変更します。コンテキストメニューからChange team project to use <process name>オプションを選択します。
- オプションで、元のプロセステンプレートを無効、もしくは削除します。
作業項目の種類に新しくカスタム項目を追加した場合、カンバンの最後の列が常に最も最近クローズされたカードを提示したことに気づいたかもしれません。私たちは、クローズになったカードをすぐ見返すことがよくあるのではないかと気づきました。
この動作の根本的な原因は、カンバンボードの最後の列がClosed Dateフィールドの降順に並べられていることです。 各プロセス(Scrum、Agile、CMMI)では、各作業項目の種類には、プロセスおよび作業項目の種類に応じて、ClosedまたはDone状態に移行するときにこのフィールドを設定する規則が含まれています。 ただし、独自のstateを追加した場合、新しい状態をサポートするために、Closed Dateフィールドを設定するルールは自動的に追加されませんでした。作業項目をNew状態からClosedまたはDone状態に移動すると、Closed Dateは空の値になります。 私たちのクエリエンジンは降順が指定されると、空の値を優先します。よって、カンバンボードでは、最も最近クローズされたカードが上に表示されるという動作になります。
最初にカスタムstateを追加する場合、適切な一連のルールが作業項目に追加されることを確認しました。作業項目を閉じるときに空のClosed Dateが表示されなくなります。既存のclose状態の作業項目には埋め戻しません。カンバンボードの一番上に最近close状態になったカードが表示されるように、カンバンボードの最後の列の順序ロジックを更新して、空のClosed Dateフィールドを持つカードを一番下に配置します。
チームプロジェクトがどのプロセステンプレートを使用しているか知りたい場合、プロセスを使用しているすべてのプロジェクトを表示する新しいページに移動してください。
カンバンボードでは、一般的なエクスペリエンスとして、作業項目のエクスペリエンスのグリッドフィルタリングと同等のフィルタリングコンポーネントを使用するようになりました。この新しいフィルタリングコントロールは、チームのすべてのメンバーに使いやすさと一貫したインターフェイスを提供します。
カンバンと他のエクスペリエンスで共通のフィルタリングコンポーネントになったので、コマンドバーでの検索時にはその位置を変更し、残りのフィルタで表示されるようになりました。アクセスするには、フィルタアイコンをクリックします。 あなたの作業項目を検索するには、ワンクリックして、さらにアイコンをクリックするとすぐにキーワードフィルタに焦点が当てられます。次のスプリントでは、キーボードを使用するだけでフィルタを表示できるようにするキーワードショートカット(Ctrl + F)を有効にします。以前はフィルタボタンの隣に検索インタラクションがあったことに注目してください。
VSTSの各プロジェクトにおいて、それぞれのWikiをサポートします。チームメンバーがプロジェクトを理解し、使用し、貢献するために役立つページを簡単に作成できます。
新しいWikiには重要な新機能が含まれています。
-
markdown構文を使った簡単な編集をサポート
-
順序変更、親子関係の付け替え、ページ管理機能を備えた、強力なページ管理ペイン
-
巨大なwikiのタイトルによるページフィルタリング
-
パワーユーザー向けのWikiのオフライン更新 を使うにはgetting started with Wikiを見てください。
Marketplace上のWiki拡張機能は廃止されました。 既存のWiki拡張ユーザーを使っている場合、この移行ツールでwikiページを新しいwikiに移行できます。 migrate your existing wiki pages to the new Wikiを見てください。
新しいWiki編集はmarkdownの中でHTMLタグをサポートしています。
markdownフォルダーにある画像のリサイズができます。
Wikiをさらに使いこなすと、意図しない変更を保存する可能性があります。特定のリビジョンのWikiページに戻すことができます。リビジョンの詳細に移動し、Revertボタンをクリックします。
Wikiの作成中、Wikiページ上に存在しないリンクを含む目次を作成するパターンがありました。リンク切れ解消のため、リンクをクリックして実際のページを作成します。以前はリンクが壊れているか、ページが存在しなかったことを示す警告を表示して、このシナリオを処理していました。Wikiの代表的なシナリオとして、ページを作成できるようにしました。
TFVCを使用するチームは、Visual Studioでチェックインポリシーを使用してコードの品質を保証することがよくあります。ただし、クライアントではチェックインポリシーが適用されますが、Web上で編集されたコードには同じポリシーが適用されません。
Web編集によるチェックインポリシーを回避するための変更をさせないために、Web編集を無効にする方法がないかと問い合わせがありました。そこで、プロジェクト/リポジトリごとにTFVCのWeb編集(追加、削除、名前変更、編集)を無効にする方法を追加しました。
FileページからWeb編集を禁止するには、Settings、Version Controlの順に選択します。ツリーのTFVCリポジトリをクリックし、Optionsピボットに移動し、Enable web-editing for this TFVC repositoryのチェックを外します。 デフォルトでは、Web編集が有効になっています。
注：Project Overview pageページからのREADMEの編集は影響を受けません。
Web編集を無効にしたプロジェクトでWeb編集を試みると、Web編集が許可されていないことが通知されます。
関連した提案に基づいています
不要になったブランチを削除してリポジトリをきれいに保つことで、チームは気になるブランチを見つけて適切な粒度でお気に入りに設定できます。しかし、リポジトリにブランチがたくさんある場合、どのリポジトリが非アクティブであり、削除できるかを判断するのは難しいかもしれません。 これで、「古い」ブランチ(3か月以上経過したブランチを指すブランチ)を識別しやすくなりました。 古くなったブランチを見るには、BranchesページのStaleピボットに行きます。
ブランチがサーバーから誤って削除された場合、そのブランチに何が起きたか把握するのが難しい場合があります。削除されたブランチを検索し、削除した人と誰がいつ削除されたかを確認し、必要に応じて再作成できます。
削除されたブランチを検索するには、ブランチ検索ボックスに完全なブランチ名を入力します。テキストと一致する既存のブランチが表示されます。削除されたブランチのリストで完全一致を検索するオプションも表示されます。 削除されたブランチを検索するには、リンクをクリックします。
一致するものが見つかった場合、それを誰がいつ削除したかがわかります。また、ブランチの復元もできます。
ブランチを復元すると、最後にポイントされたコミットのタイミングで再作成されます。ただし、ポリシーとアクセス許可は復元されません。
Branch Updatesページには大きな価値があります。しかし、それはHistoryハブの下のピボットとして隠されていました。ブランチ更新ページは、Codeの下にPushと呼ばれるハブとして、Commits, Branches, TagsおよびPull Requestとともに表示されます。 プッシュページの新しいURLは、https://<accountname>/<projectname>/_git/<reponame>/pushesです。 古いURLは引き続き機能します。
同時に、Historyハブの名前がCommitsに変更されました。ハブにはコミットのみが表示されるからです。コミットリストビューでは詳細なオンホバーのみが表示されていたため、コミットに関連する問題のトラブルシューティングが難しいという意見がありました。VSTSのコミットリストビューには、日時がdd/mm /yy hh:mm形式で表示されます。 コミットページの新しいURLは、https://<accountname>/<projectname>/_git/<reponame>/commitsです。 古いURLは引き続き機能します。
CodeハブのFilesピボット内の特定のファイルにディレクトリをフィルタリングし、その後Historyピボットにフリップすると、コミットによって1,000個以上のファイルが変更された場合、ファイル名が保持されないというフィードバックが寄せられました。その結果、ファイルを検索してコンテンツをフィルタリングして生産性に影響を与えていた人が増えました。 開発者は通常、同じディレクトリで作業し、変更を追跡するときに作業するディレクトリに保持します。 今度は、コミット時に変更されたファイルの数に関係なく、Codeハブのピボット間を移動するときにファイル名を保持します。 これは、あなたが望むファイルを見つけるためにLoad Moreをクリックする必要がないことを意味します。
ブランチポリシーを使用すると、コードの品質を向上させることができます。しかし、これらのポリシーは、VSTSによってネイティブに提供されている機能のみに限定されていました。新しいPR Status APIと対応するブランチポリシーを使用することで、サードパーティのサービスもネイティブVSTS機能と同様にPRワークフローに参加できます。
サービスがプルリクエストのステータスAPIにポストすると、サービスはすぐに新しいステータスセクションのPR detailsビューに表示されます。Statusセクションには説明が表示され、サービスが提供するURLへのリンクが作成されます。 ステータスエントリは、Web拡張機能によって追加される新しいアクションのために拡張可能なアクションメニュー(...)もサポートしています。
ステータスだけではPRの完了をブロックすることはできず、ポリシーの所在地です。PRステータスがポストされると、ポリシーの設定ができます。ポリシーのエクスペリエンスでは、Require approval from external servicesという新しいポリシーが使用できます。プロセスを開始するには+Add serviceを選択します。
ダイアログで、ステータスを通知するサービスをリストから選択し、目的のポリシーオプションを選択します。
ポリシーがアクティブになると、ステータスはPoliciesセクションのRequiredまたはOptionalに適切に表示され、必要に応じてPR完了が強制されます。
ステータスAPIの詳細を知り、自分で試してみるには、ドキュメントとサンプルをチェックしてください。
以前は、ビルドサマリーセクションを使うビルドタスクを持つ拡張機能を使用していた場合、そのビルドでビルドタスクを使用していなくても、ビルドサマリーセクションが表示されています。この機能で、ビルドサマリーページでそのセクションを非表示にするか、拡張コードに次の行を追加して値をtrueまたはfalseに設定することができます。
VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);
サンプルはMicrosoft vsts-extension-samples repositoryにあります.
Variableグループはリリース定義で使用できるようになっただけではなく、ビルド定義でも使用できるようになりました。 詳細はcreating variable groupを参照してください。 これは、プロジェクトレベルのビルド/リリース変数とビルド定義の変数グループに関連する提案に優先づけられて開発されました。
次のメジャーバージョンアップとなるdotnetタスク(2.x)では、多くのフィードバックリクエストと、しばらく追跡してきた一連のバグを修正します。
- 最初に、dotnetはパッケージ管理のような認証されたパッケージソースをサポートするようになりました。したがって、NuGetタスクを使用してプライベートパッケージソースからパッケージを復元する必要はありません。
- プロジェクトの**Path to project(s)**の動作が、2.0バージョンのタスクで変更されました。以前のバージョンのタスクでは、指定されたパターンに一致するプロジェクトファイルが見つからなかった場合、タスクは警告を記録してから成功しました。このようなシナリオでは、ビルドが成功した理由を理解するのは難しいかもしれませんが、依存関係は復元されませんでした。指定されたパターンに一致するプロジェクトファイルが見つからない場合、タスクは失敗します。これは他のタスクの振る舞いとあわせたものであり、わかりやすく使いやすくなっています。
- 以前のバージョンのタスクの発行コマンドでは、明示的な出力パスを渡したときでも、プロジェクトファイル名の後に名前が付けられたフォルダにすべてのファイルを入れて、出力パスを変更しました。コマンドを連鎖させることが難しくなっていましたが、出力パスファイルを制御できるようになりました。
また、新しいdotnet Tool Installerタスクをリリースしました。このタスクは、PATH上で使用可能なdotnetのバージョンを制御し、新しいdotnetタスクで使用されます。したがって、新しいバージョンのdotnetを使用するには、ビルドの始めにdotnet Tool Installerタスクを追加するだけです。
私たちは、コマンドラインインターフェース経由でInventoryノードの特定のリストに記載されたPlaybookを実行する、ビルド/リリースタスクを含む、Ansibleと統合された拡張機能をリリースしました。AnsibleはYAMLフォーマットで手順を記録したPlaybooksを使って簡単に構成、展開、オーケストレーションします。各Playbookは、ホストのグループを一連のロールにマッピングします。各ロールはAnsibleタスクによって呼び出されます。Inventoryファイルは、Ansibleがアクセスできるホストノードの詳細が格納されています。
このタスクでは、PlaybookとInventoryファイルを、プライベートLinuxエージェントまたはAnsibleオートメーションエンジンがインストールされているリモートマシンに配置する必要があります。SSHエンドポイントは、Ansibleがリモートマシン上にある場合に設定する必要があります。Inventoryは、インライン、Dynamic Inventory、またはHostリストとして指定することもできます。
新しいRelease Definition Editorは、古いエディタにある機能を検証しながら移行し続けます。このリリースでは、Variableグループにリンク解除/リンクしている個々のリリース環境のための保持ポリシーを設定したうえで、Optionタブからリリース番号フォーマットとしてリリース定義レベルの設定の変更ができます。Taskタブでは、リリース環境をデプロイメントテンプレートとして保存し、環境レベルの権限を設定し、フェーズを並べ替えることもできます。リリース環境全体でプロセス変数をフィルタリング/比較する機能は、わずか数スプリントの成果です。
リリース環境レベルの操作で、テンプレートとして保存して、セキュリティの設定を実行します。
今ままで、コミットがお客様の本番環境にデプロイされているかどうかを知りたい場合、最初にすべてのリリース環境に対して、どのビルドがデプロイされているか調べて、そのビルドはどのcommitによって発生したか調べなくてはなりませんでした。Codeハブのステータスバッジにデプロイメントステータスを統合して、コードがデプロイされている環境の一覧を表示することで、このエクスペリエンスははるかに簡単になりました。すべてのデプロイメントに対して、デプロイメントの一部であった最新のコミットに状態ががポストされます。 コミットが(複数の環境で)複数のリリース定義にデプロイされている場合、各環境はバッジにエントリを持ち、各環境にステータスが表示されます。 これにより、コードコミットのトレーサビリティが向上します。
デフォルトでは、リリース定義を作成すると、すべてのリリース環境に展開ステータスが通知されます。 ただし、ステータスバッジにデプロイステータスを表示する環境を選択して選択することもできます(プロダクション環境のみを表示するなど)。
リリース定義にビルド成果物を追加する際、フォルダ階層で定義を表示し、希望のビルド定義を簡単に選択できるようになりました。これにより、同じビルド定義名を異なるフォルダで区別することが容易になります。
ビルド定義リストがフィルタしたい単語を含む状態でフィルタされています。
現在、リリース定義が更新された場合、直前のバージョンに戻すことができません。変更前に戻す唯一の方法は、リリース定義の履歴を調べて変更の差分を見つけ、リリース定義を手動で編集することです。 今回のスプリントで追加されたRevert Definitionを使用して、リリース定義のHistoryタブから古いバージョンのリリース定義を選択して戻すことができます。
私たちは探索テストを行っているチームから得たフィードバックに基づいて、Test＆Feedback拡張機能からバグ、タスク、またはテストケースを抽出しながら、トレーサビリティリンクを改善しています。要件探索テスト中に作成されたバグとタスクは、チームのデフォルトではなく、要件と同じエリアパスとイテレーションに作成されるようになりました。 要件探索テスト中に作成されたテストケースは、Parent<->Childリンクの代わりにTests<->Tested Byの間でリンクされ、作成したテストケースが要件ベースのテストスイートに自動的に追加されます。最後に、要件を特に整理していない間に作成された作業項目は現在のイテレーションではなく、チームのデフォルトイテレーションに保存され、スプリント計画が完了した後には新しい作業項目は現在のイテレーションに追加されません。
TestハブのWeb Test Runnerからデスクトップアプリケーションのスクリーンショットのキャプチャサポートは、手動テストのなかで最も多く寄せられた提案の1つでした。これまでは、Microsoft Test ManagerのTest Runnerを使用して、デスクトップアプリケーションのスクリーンショットをキャプチャする必要がありました。この機能を使用するには、Test＆Feedback拡張機能をインストールする必要があります。 私たちはChromeブラウザのサポートを開始しており、Firefoxもまもなく続きます。
Outcome、Configuration、およびTesterなどのTestフィールドのフィルタに加えて、Title、State、Assigned ToなどのTest Case作業項目フィールドをフィルタリングできるようになりました。
VSTSダッシュボード上でRelease Environmentsのステータスを追跡できるように、Test Result Trendウィジェットにリリース環境のサポートを追加しました。Buildでのテスト結果と同様に、テスト合格率、合計数、合格または不合格のテスト、およびRelease Environmentのテスト期間を示す傾向グラフを作成できるようになりました。 Test Runタイトルフィルタを使用して、環境内の特定のテスト実行にチャートをファイリングすることもできます。
Test RunコメントとTest Resultのコメントをmarkdown構文で書けるようにしています。この機能を使用して、書式設定されたテキストを作成するか、コメント内のURLへのクイックリンクを作成できます。 Test Resultのコメントは、Result SummaryページのUpdate AnalysisおよびTest RunのRun SummaryページにあるTestハブのUpdate commentsで更新できます。
BuildまたはReleaseの概要ページ、またはTestハブでテスト結果を分析している間、既存のバグを失敗したテストに関連付けることができるようになりました。 これは、既にバグが提起されている既知の理由でテストが失敗した場合に役立ちます。
各グループヘッダーの上向き矢印と下向き矢印を使用して、それぞれのMy favoritesページのグループを並べ替えることができます。
拡張機能をインストールするには、コピーしてからインストールを実行し、Visual Studio Codeから参照する必要がありました。今回の更新で、Marketplaceから拡張機能をワンクリックで直接インストールできます。エンタープライズでVisual Studio Codeを使用している場合は、VSIXパッケージのダウンロードオプションも利用できます。 PowerShell拡張モジュールの例を以下に示します。
今回のリリースでは、業界標準の「どのようにお勧めしますか」という質問と、オプションの説明を使用して、VSTSのフィードバックを求める小さな入力欄を表示します。これにより、VSTS全体について定期的にどのように感じているのかを洞察することができ、推奨するフィードバックと改善したほうが良いフィードバックの両方から迅速に学ぶことができると期待しています。 このタイプのフィードバックを収集するためにこれまでに使用してきた電子メール調査よりも、これがより正確でタイムリーなアプローチになると期待しています。
これをロールアウトするとき、私たちはこれが迷惑にならないように、VSTSを使うときの邪魔にならないように、極めて慎重に実施しています。 メジャーリリースごとに統計的に関連性の高い結果を収集するために、必要な人数を最小限にするよう促します。 中断をさらに最小限に抑えるために、私たちはアカウントとプロジェクトホームページを訪れる人のみに問い合わせます。 また、ダイアログを閉じたりクリックしたりすると、プロンプトが表示されなくなるまでに数回だけメッセージが表示されます。私たちは、3か月ごとに1回のみフィードバックを表示し、全体的な回答率に基づいてフィードバックすることを約束します。 また、すべてのフィードバックを読んで、傾向を探し、時には高水準の洞察を共有することを約束します。
このフィードバックチャンネルに参加していただきありがとうございます。私たちはあなたのことを学び、お客様のニーズに合わせてサービスを改善していきます。
私たちはあなたがこれらの機能について何を考えているのか聞いてみたいと思います。 新しいフィードバックメニューで優先順位をつけたいと思っていることに関するアイデアがある場合は、問題を報告するか、提案を提出してください。
あなたの疑問に対する回答がほしい場合、Stack Overflowコミュニティで聞いてみてください。
ありがとうございました。
Anand Kamat