Last Update: 7/14/2017
注意事項: ここで紹介している機能は今後三週間にわたって順次展開されます。
前回のスプリントでは、私たちのウェブエクスペリエンスの継続的なリフレッシュについて話しました。 私たちがこのスプリントでもっとも興奮しているのは、新しいRelease Definition Editorがプレビューになることです。これは、ずっと前にリリースした新しいCIエディタに基づいています。これは、我々が進めている全体的な方向性の良い例です。洗練されたエクスペリエンスだけでなく、リリースプロセスを視覚化できるという点で構造的にも違います。システムについて考える方法でリリースで作業ができます。この同じアプローチをランタイムビューにも導入し、リリースが進行するにつれてそのリリースを視覚化できるようにする予定です。よりリッチで、視覚化をより簡単に使用して、すべてのデータをアンロックすることは、製品全体でやろうとしていることです。 Release Definition Editor Preview をご覧ください。
そしてもちろん、このスプリントでは、製品全体に他にも多くの改善点があります。詳しく紹介しましょう！
同じシステムプロセス内のプロセス間でチームプロジェクトを移行するエクスペリエンスが改善されました。以前、チームプロジェクトでMyScrum Aの代わりにMyScrum Bを使用させたい場合は、最初にチームプロジェクトをScrumシステムプロセスに移動する必要がありました。混乱の原因となっただけでなく、継承したプロセスにカスタム作業項目の種類が含まれている場合の移行ができませんでした。 改善されたエクスペリエンスでは、同じカスタムアイテムアイテムタイプを持つ場合に限り、チームプロジェクトのプロセスの変更ができます。
多くのお客様から既存のお客様に影響なく、準備とテスト変更の方法について尋ねられました。この機能はそのためのエクスペリエンスの重要な部分です。次のデプロイでは、継承したプロセスのコピーが行えるようになります。これが完成すると、プロセスのコピーを行い、コピー先のプロセスを変更できるようになります。そして、テスト変更を行った、プロセスを使って一時的なチームプロジェクトを作成します。変更を検証したら、プロダクションのチームプロジェクトを変更します。
すべてのワークアイテムトラッキンググリッドエクスペリエンス(クエリ、バックログ、スプリントバックログ、テストケース管理)はすべて、共通の一貫したフィルタリングコンポーネントを使用します。 表示された列にキーワードフィルタを適用し、タグを選択する以外にも、この新しいコンポーネントを使用して、作業項目の種類、状態をフィルタリングして、すぐに作業項目に到達することができます。 ここでちょっとどんな感じなのか見てみましょう：
次回からの数回にわたるスプリントで、Kanbanのボード、タスクボード、Delivery Plansの拡張機能に、このフィルタリングのエクスペリエンスを引き継いでいきます。
今日から、ボードの設定でhide empty fieldsを実施すると、空のフィールドを非表示になるので、カードに追加されたフィールドボードが表示されていない、という不必要な混乱を取り除くことができるようになりました。この機能の欠点は、空のフィールドが非表示にした場合、フィールドを更新する唯一の方法は作業項目フォームを開くことでした。 Kanbanカードで新たに利用可能な拡張オプションを使用すると、ボード上の空のフィールドを隠せるという利点がありますが、カード上の特定のフィールドを更新するためにはシングルクリックアクセスが必要になります。カードの上にマウスを置くだけで、カードの下にあるシェブロンを探して隠れたフィールドを更新できます。
カードの下部にあるシェブロンをクリックしてフィールドを更新します。
作業項目をPRにリンクしている場合、最新状態への更新が簡単になります。PRが正常にマージされた後、 PRを完了にすると、リンクされた作業項目も自動的に完了状態にできます。 ポリシーを使用していて、PRを自動完了に設定している場合は、同じオプションが表示されます。 PRが完了したら、VSTSがあなたのために自動的に変更するので、作業項目を再度表示して、作業項目の更新をしなければならないと、覚えておく必要はもうありません。
PRでのより厳格な承認ワークフローを選択したチームは、新しい機能が選択できるようになりました。これは、新しい変更がプッシュされたときに投票をリセットする機能です。 新しい設定は、ポリシーの下で最低限の査読者を要求するオプションです。
このオプションを設定すると、PRのソースブランチが更新されるたびに、すべてのレビューアのすべての投票がリセットされます。 PRタイムラインは、このオプションの結果として投票がリセットされるたびにエントリーを記録します。
Pull Requestメールアラートは、それらを明確かつ簡潔かつ実行可能にするために更新されました。 件名はPRタイトルと2次情報(レポジトリ名など)で始まり、IDは最後まで出てきません。 作成者の名前が件名に追加され、PRを作成したユーザーに基づいたルールやフィルタの適用が簡単になりました。
アラートメールの本文には、アラートが送信された理由、クリティカルなメタデータ(タイトル、ブランチ名、説明)、およびすぐにやるべき行動を促すボタンが表示されます。 レビューア、ファイル、コミットなどの追加の詳細は、電子メールの下にさらに含まれています。
大部分のアラートでは、行動を促すフレーズがウェブブラウザでプルリクエストを表示、となります。ただし、特定のコメントについて通知を受けると、行動を促すフレーズがそのコメントに直接リンクされるため、コードとその前の会話を簡単に見つけられます。
時々、コードが変更された後に参照しているPRコメントが意味をなさないことがあります(要求された変更が行われたときは何度も)。
このような状況が発生した場合、更新番号のバッジが表示されます。この番号をクリックすると、最初にコメントが作成されたときのコードのアウトラインが確認できます。
PRを準備するときやコメントを書くとき、追跡したいものの短いリストがありますが、テキストの編集や複数のコメントの追加が終わることがあります。ちょっとしたタスクリストは、説明のPR作成者またはレビュー担当者または単一の統合されたコメントのいずれかとして、todoリストの進行状況を追跡するのに最適な方法です。 選択したテキストにフォーマットを適用するには、Markdownツールバーをクリックします。
タスクリストを追加したら、チェックボックスをオンにして項目を完了済みとしてマークするだけです。 これらはMarkdownの[]と[x]のようにコメント内に表現されて格納されます。 詳細については、Markdownガイダンスを参照してください。
PRコメントのlikeボタンをクリックした人がわかるようになりました。likeボタンをホバーすると、コメントに賛同している人のリストが表示されます。
pull request ID, ソースブランチ名、ターゲットブランチ名が build variablesに定義されました。
Windowsエージェントからファイル共有に成果物をより速く公開するためのオプションが追加されました。 Publish Build Artifactsタスクの引数で、Enable Copy Concurrencyを選択して、マルチスレッド・モードを有効にし、複数のファイルを同時にコピーします。 これはrobocopy / mtと同等です。 オプションで、Copy Concurrency Value(デフォルトは8)でスレッドの数を指定できます。
Preview feature
この機能を使用するには、自分または自分のアカウントで新しいリリース定義エディタを有効にします。 詳細は、New Release Definition EditorのEnable preview featuresを参照してください。
あなた自身の環境への展開がどのように進行するかというメンタルモデルの作成に苦労したでしょうか？ デプロイメントの流れを示すリリース定義のパイプラインビューを導入しています。 承認、環境、およびデプロイメントの設定をコンテキストに合わせて簡単に設定できます。
エディタのパイプラインは、リリースでの展開の進捗状況をグラフィカルに表示します。 成果物はリリースの間渡り歩き、環境に配備されます。 レイアウトとリンクされた環境毎に定義されたトリガーに設定が反映されます。
コンテキストに合わせて成果物、リリーストリガー、導入前/導入後の承認、環境のプロパティ、および導入設定が簡単に設定できます。
新しい環境を作成したときに機能を定義したテンプレートが表示されます。
新しいビルド定義エディタのすべての拡張機能がリリース定義エディタでも使用できるようになりました。 タスクを検索し、Addボタンを使用するか、ドラッグ＆ドロップを使用してタスクを追加できます。 ドラッグアンドドロップを使用してタスクの順序を変更したり、クローンを作成することができます。
Task groupは、複数のリリースおよびビルド定義で共通してタスクを共有するために作成されていますが、task groupの変更の影響を受ける定義がわからないという混乱があると聞きました。 今回の新機能により、Referencesタブが追加され、task groupを使用してビルドおよびリリース定義のリストが表示され、自信を持って変更できるようになります。
Task groupを変更すると、その変更がTask groupを使用するすべての定義に有効であるため、変更が危険だと感じることがあります。Task groupのバージョニングでは、Task groupのバージョンを作成してプレビューすることができますが、切り替えが完了するまで、最も重要な定義に安定したバージョンを提供できます。 何回かドラフト状態で繰り返し評価した後、安定したバージョンを公開することができます。公開中に変更が本質的に壊れている場合は、作成した新しいTask groupをプレビュー(新しいメジャーバージョン)として公開できます。更新された安定版として直接公開もできます。
Task groupの新しいメジャー(またはプレビュー)バージョンが使用可能になると、定義エディターは新しいバージョンがあることを通知します。 メジャーバージョンがプレビューであれば、 "try it out"というメッセージが表示されます。 Task Groupがプレビューから外れると、そのTask Groupが使用されている定義が自動的に更新され、チャンネルに順次展開されていきます。
Task Groupはプロジェクト内での再利用を可能にしましたが、プロジェクトやアカウント間でTask Groupを再作成するのは大変です。 Task Groupのインポート/エクスポートでは、リリース定義で行ったように、JSONファイルとしてエクスポートし、必要な場所にインポートできます。 また、ネストされたTask Groupも有効になっています。ネストされたTask Groupは、最初にエクスポートされるときに展開されます。
サーバサイド(エージェントレス)タスクに複数の構成定義を指定することで、並列で実行される複数の構成のフェーズで同じタスクセットを実行できるようになりました。
Releaseにおいて、Jenkinsのような一般的なCIシステムとの統合性を向上させたいと考えています。 現在、release summaryタブでは、CIビルドがVSTSからのものである場合にのみ、コードコミットを表示します。 今回の新機能では、JenkinsのCI成果物のコード情報が、リリースを実行しているエージェントによってJenkinsサーバーに到達可能な場合にも有効になります。
Marketplace Extension for Analytics で Velocity ウィジェットをサポートしました。
この強力なウィジェットを使用すると、Story Points、ワークアイテム数、または任意のカスタムフィールドでチームのベロシティをグラフ化できます。 高度なオプションを使用すると、計画と比較してチームが提供したものと、遅れて完了した作業を強調表示することができます。
チーム管理者は、チームをターゲットとする通知の配信方法を制御できるようになりました。 このオプションは、各チームメンバーに電子メール通知を送信したり、特定の電子メールアドレスに通知を送信したり、通知を送信したりしません。 この機能は、チームをレビュー担当者として追加できるプルリクエスト通知に特に便利です。 以前はチームに通知されませんでした。
チーム管理者は、チームのNotification settingsハブを使用してチームのデフォルトの配信設定を構成できます。
セキュリティ上の懸念から、拡張機能をより安全にするためにSVG制約を追加しました。
- アイコンとスクリーンショットはSVGではなくなりました。
- マニフェストで提供されるバッジは、承認されたバッジプロバイダからのものでない限り、SVGにすることはできません。
- README.mdとCHANGELOG.mdのイメージは、承認されたバッジプロバイダのものでない限り、SVGにすることはできません。
私たちはあなたがこれらの機能について何を考えているのか聞いてみたいと思います。 新しいフィードバックメニューで優先順位をつけたいと思っていることに関するアイデアがある場合は、問題を報告するか、提案を提出してください。
Stack Overflowのコミュニティであなたへのアドバイスや質問に関する回答が見つかるでしょう。
ありがとうございました
Jamie Cool