Last Update: 8/28/2017
Visual Studio Team Services(VSTS)のSprint 122アップデートでは、作業項目の動作を自動化するためのカスタマイズ可能な作業項目ルールの一般提供を発表しています。 これは、継承されたシンプルな開発プロセスを活用するための重要な機能です。 以下のCustomizable work item rulesご覧ください。
重要な機能からいくつか紹介します。
- Forks - アカウントで広く貢献できるようになります。
- Work Items hub - パーソナライズされたピボットを使用して、重要な作業項目を見つけて操作します。
- File minimap, Bracket matching,Toggle white space - コードの概要を簡単に見て簡単に編集できます。
- CI builds for Bitbucket repos - あなたがBitbucketを使用していれば使えるようになります。
- New Release Definition Editor - リッチなリリース定義編集プレビュー機能がオンになり、一般提供されました。
- Streamlined user management - プレビュー機能がオンになり、一般提供されました。
Note
これらの機能は今後三週間かけて順次展開されます。
Preview feature
この機能はあなたのプロファイルおよび、アカウントでpreview featureからNew Work Items Hubを有効にしてください。
The Work Itemsハブはチームプロジェクト内部のあなたの5つの作業に焦点を当てています。
- Assigned to me - プロジェクトであなたに割り当てられているすべての作業項目を、最後に更新された順に表示します。 作業項目を開くか、更新するためには、そのタイトルをクリックします。
- Following - あなたがフォローしているすべての作業項目。
- Mentioned - 過去30日間、あなたが言及したすべての作業項目。
- My activity - あなたが最近閲覧した、または更新したすべての作業項目。
- Recently created - プロジェクトで最近作成されたすべての作業項目。
ハブからワンクリックするだけで作業項目の作成ができます。
作業項目は、キーワードを入力するか、作業項目タイプ、割り当て先、状態、タグなどの異なるフィールドを使用してフィルタリングできます。 これらのフィルタは記憶されており、ピボットごとに真に個人的なビューを作成できます。
新しいWork Itemハブを開発する際に、Query Editorを使用して各ピボットを再作成できるようにしたいと考えました。 以前は、あなたがフォローしているアイテムとあなたに割り当てられたアイテムのクエリをサポートしていましたが、今回のスプリントでは、@RecentMentionsと@MyRecentActivityの2つの新しいマクロを作成しました。 これらを使用すると、過去30日間にクエリを作成し、ここで言及した作業項目を取得したり、最新のアクティビティを返すクエリを作成したりすることができます。 これらのマクロをどのように使用できるかを覗いてみましょう。
詳細はdocumentation for the Work Items hubをみてください。
特定の作業項目フィールドの値を自動的に設定する場合でも、特定の状態でそれらのフィールドの動作を定義する場合でも、プロジェクト管理者はルールを使用して作業項目フィールドの動作を自動化し、チームの負担を軽減できます。 ここでは、ルールを使用して構成できる主要なシナリオの例をいくつか紹介します。
- 作業項目の状態がActiveに変わったら、Remaining Workを必須フィールドにします
- 作業項目がProposed(提案)され、Original Estimate(見積もり)が変更されたら、元のOriginal Estimateの値をRemaining Workフィールドにコピーします
- 独自の日付/時刻フィールドタイプを持つカスタムステートを追加すると、ルールを使用して、状態遷移時にこれらのフィールドの値を自動的に設定できます
- 作業項目の状態が変わったら、custom by/dateフィールドでカスタムの値を設定します
簡単なステップでルールを始めましょう。
- 作業項目のコンテキストメニューからCustomizeを選択します
- 既存の継承されたプロセスを作成または選択する
- ルールを追加するワークアイテムタイプを選択し、Rulesをクリックして、New ruleをクリックします
詳細については、documentation for custom rulesを参照してください。
My work itemsページの下に新たにMentionピボットが追加されました。 このピボットの内部では、過去30日間に言及された作業項目が確認できます。 この新しいビューでは、あなたの入力が必要な項目に迅速に対応し、あなたに関連する会話を最新の状態で閲覧できます。
これは同じピボットをモバイル環境でみた場合のスクリーンショットで、モバイルとデスクトップ両方に一貫性があります。
カスタムフィールドとタグの条件を使用して通知を定義できるようになりました。状態が変化する時だけでなく、特定の値が満たされたときに通知が行われます。 これは、UserVoice(6059328と2436843を参照)での皆さんの要望の多かった提案であり、作業項目に対してより堅牢な通知の設定を可能にします。
新しいフィーチャーのアイデアはいつでも湧き出してきます、新しいフィーチャーを直接Delivery Plansに簡単に追加できるようになりました。 ホバー上のNew itemボタンをクリックして名前を入力し、Enterキーを押すだけです。 新しいフィーチャの領域のパスとイテレーションパスを予想して、作成します。
Preview feature
この機能はあなたのアカウントでpreview featureからGit Forksを有効にしてください
このアップデートで、アカウント内で変更をフォークしてプッシュできるようになりました。 これはフォークを使った私たちの新しい開発方式への第一歩です。 次のステップは、リポジトリを別のVSTSアカウントにフォークできるようにすることです。
forkとは、すべてのファイル、コミット、および(オプションで)ブランチを含むリポジトリの完全なサーバー側のコピーです。 forkは、元のコードベースから実験的、リスクが高い、または機密の変更を分離するために最適な方法です。 これらの変更を共有する準備ができたら、pull requestを使用して変更を元のリポジトリに簡単にプッシュします。
forkを使用すると、広範囲の人々がリポジトリに直接コミットすることなくリポジトリに貢献することを許可することもできます。 代わりに、彼らはリポジトリの独自のフォークに自分の仕事をコミットします。 これにより、pull requsetの変更を中央レポジトリに受け入れる前に、それらの変更を確認する機会が与えられます。
forkは、その上流の(元の)リポジトリのすべての内容を起点にしています。forkを作成するときに、すべてのブランチを含めるか、またはデフォルトブランチのみに制限するかを選択できます。 アクセス許可、ポリシー、またはビルド定義は適用されません。 新しいforkは、元のリポジトリをクローンした後、新しい空のリポジトリにプッシュしたように動作します。 forkが作成された後、新しいファイル、フォルダ、ブランチは、PRによってオリジナルにプッシュするまで、リポジトリ間で共有されません。
forkからupstream、またはupstreamからforkのいずれかの方向にPRを作成できます。 最も一般的な方向はforkからupstreamです。宛先リポジトリのアクセス権、ポリシー、ビルド、および作業項目は、PRに適用されます。
詳細はdocumentation for forks を読んでください.
表示または編集する際に、ファイルのミニマップを表示して、コードの概要を簡単に確認することができます。 ミニマップをオンにするには、Command Palette(F1または右クリック)を開き、Toggle Minimapを選択します。
ファイルを編集したり、表示したりするときに、中括弧の位置をそろえるためのガイドラインが追加されました。
ファイルを表示または編集するときに空白の表示/非表示を切り替えることができるようになりました。 差分をとるときに空白を切り替える機能はまだ開発中です。 空白を表示するには、Command Palette(F1キーまたは右クリック)を開いてToggle White Spaceを選択します。これにより、スペースとタブを区別することができます。
プッシュ通知は、明確かつ簡潔かつ実行可能に最適化された新しい電子メールテンプレートに更新されました。件名でプッシュ電子メールを明確に区別し、ブランチ、レポ、および著者を特定し、プッシュに含まれるコミットの数を要約するのに役立ちます。 これらの変更により、これらの電子メール通知を管理するのに役立つルールとフィルタを簡単に作成することもできます。
電子メールの本文は、他の電子メールと一貫した内容になっており、電子メールが送信された理由、操作を開始した人、通知が発生した理由を強調しています。 アラートをプッシュするのに特化して、レポ、ブランチ、ファイル、およびコミットの詳細がすべて含まれており、受信者に変更の範囲について通知するために役立ちます。 特定のプッシュによりアラートが生成された場合、View Pushを実行すれば、アラートが生成された原因の取るべき行動が表示されます。
Pull requestを完了した時点で作業項目を完了する機能に、デフォルトの動作を制御するための新しいリポジトリ設定が追加されました。 Remember user preferences for completing work items with pull requests(訳注:pull requestで作業項目を完了するためのユーザー設定)は、デフォルトで有効になっており、レポジトリの将来のPRを完了するときのユーザー設定を維持します。 新しい設定が無効となっている場合、マージ後にリンクされた作業項目を完了するオプションは、リポジトリ内のすべてのPRに対してデフォルトで無効になります。 ユーザーは、PRを完了するときにリンクされた作業項目の遷移を選択することができますが、毎回オプトインする必要があります。
git force pushを実行し、ローカルrefの参照元ではない場合でもリモートrefを更新できます。これにより、他の人のコミットが消失し、根本的な原因を特定するのが非常に難しくなる可能性があります。 新しいプッシュビューでは、コミットの欠落に関連する問題のトラブルシューティングを支援するために、force pushを目立たせています。
force pushタグをクリックすると、消失するコミットが確認できます。
新しいリポジトリと新しいプロジェクトの場合、管理者はデフォルトでgit force push権限を与えないようになっています。これは、ブランチの変更を忘れたときなど、意図しないforce pushを防ぐのに役立ちます (Bypass Policyは、同じ理由で既にこの方法で動作しています)。force pushを実行する必要がある管理者は、force pushを許可するために、ブランチ、レポ、またはAll Repositoriesレベルでアクセス権を更新できます。
BitbucketリポジトリからCIビルドを実行することが可能になりました。 開始するには、Bitbucketに接続するサービスエンドポイントを設定します。 次に、ビルド定義のTaskタブでBitbucketソースを選択します。
その後、TriggersタブでCIを有効にしてください。
この機能は、VSTSアカウントのビルドとクラウドホストのBitbucketリポジトリでのみ機能します。
ビルド定義を一時停止または無効にすることができます。 ビルド定義を変更するとき、完了するまで新しいビルドのキューイングを避けたい場合は、ビルド定義を無効にするだけです。 同様に、ビルドエージェントマシンをアップグレードする予定がある場合は、ビルド定義を一時停止することもできます。これにより、VSTSは新しいビルド要求を引き続き受け入れますが、定義を再開するまで実行しません。
ビルド定義タスクにパラメータを入力する場合、エラーが発生することがあります。 タスクのパラメータ入力検証では、タスク作成者は適切な値が指定されるようにすることができます。 検証条件式は、タスク条件に使用される一般的な式構文に従い、URL、IPV4、電子メール、番号範囲、sha1、長さ、または一致など、タスク条件でサポートされている一般的な機能以外にもサポートされている関数を使用できます。
詳細はvsts-tasks repo pageを読んでください。
Preview feature
この機能はあなたのプロファイルおよび、アカウントでpreview featureからNew Release Definition Editorを有効にしてください。
先月、新しいリリース定義エディタのプレビューを発表しました。使用していただいた皆様、ありがとうございました！ このリリースでは、デフォルトですべての人に新しいリリース定義エディタを有効にしました。 管理者は、アカウントプロファイルメニューのPreview features optionから無効にできます。
リリース定義エディタでカスタムテンプレートの削除ができるようになりました。
新しいリリース定義エディタでは、さまざまな権限を処理するコンテキストメッセージを取り扱えます。
ドラッグ＆ドロップジェスチャーを使用すると、類似のフェーズ内またはフェーズ間で簡単にフェーズやタスクを並べ替えることができます。 さらに、Ctrl を押しながらドラッグ/ドロップを使用してタスクを複製することもできます。
リリーステンプレートを使用すると、リリースプロセスを定義するベースラインが作成できます。 以前はアカウントに新しいものをアップロードすることができましたが、現在、作成者は自分の拡張機能にリリーステンプレートを含めることができます。 GitHubリポジトリのサンプルを見てください。
条件付きビルドタスクと同様に、特定の条件が満たされている場合にのみタスクまたはフェーズを実行できるようになりました。 これは、ロールバックシナリオのモデリングに役立ちます。
組み込みの条件がニーズを満たしていない場合や、タスクやフェーズが実行されるタイミングをより細かく制御する必要がある場合は、カスタム条件を指定できます。 条件をネストすることにより、関数の集合としても使えます。 エージェントは、最も内側の関数を評価し、外側に向かって働きます。 最終結果は、実行するタスクを決定するブール値です。
リリースの承認管理が簡単になりました。 並行して展開する複数の環境で同じ承認者を持つパイプラインの場合、承認者はそれぞれの承認ごとに個別に行動する必要があります。 この機能により、複数の保留中の承認を同時に完了することもできます。
サービスエンドポイントを使用すると、外部またはリモートのサービスに接続して、ビルドまたはデプロイメントのタスクを実行できます。 エンドポイントはプロジェクトスコープで構成され、複数のビルド定義とリリース定義間で共有されます。 サービスエンドポイントの所有者は、エンドポイントを使用してビルドとデプロイメントの統合ビューを取得できるようになり、監査とガバナンスの向上に役立ちます。
スクリーンショットやログファイルなどのファイルをテスト実行またはテスト結果に追加情報として添付することができます。この機能はMicrosoft Test Manager(MTM)クライアントからのみ使用でき、VSTS / TFSのTestハブとMTMクライアント間のコンテキストを切り替える必要がありました。
ビルド/リリース管理のVisual Studioテストタスクでは、効率的な実行のためにテストをグループ化(バッチ処理)する方法を制御するためのオプションが用意されています。 テストは2つの方法でグループ化できます。
- 実行しているテストとエージェントの数に基づいて、指定されたサイズ毎に一括してテストをグループ化します。
- 過去の実行時間を考慮したテストの過去の実行時間に基づいて、各バッチの実行時間がほぼ同じになるような一括で実行するテストの組み合わせを作成します。 クイックランニングテストはバッチ処理され、ランニングテストは別のバッチに属します。 このオプションをマルチエージェントフェーズ設定と組み合わせて、合計テスト時間を最小限に抑えることができます。
クラウドロードテストエージェントでJMeter 3.2エンジンを使えるようになりました。ロードテストはHTTPサンプラーのレバレッジを強化します。
Preview feature
この機能はあなたのプロファイルおよび、アカウントでpreview featureからStreamlined User Managementを有効にしてください。
効果的なユーザー管理により、管理者は適切なリソースを確保し、プロジェクトに適切にアクセスできるようになります。 私たちは、サポートへの問い合わせや、お客様からしばしばVSTSでこのプロセスを簡素化する機能が必要だと聞いています。 このスプリントは、これらの問題に対処するためのエクスペリエンスを一般公開しました。 詳細については、documentation for the User hubを参照してください。 次のような変更点があります。
管理者は、適切な拡張機能、アクセスレベル、およびグループメンバーシップを同時に持つアカウントにユーザーを追加できるようになりました。 また、新しい招待状を使って最大50人のユーザーを一度に招待できます。
Manage usersページに、アカウント内のユーザーを一目で識別するための詳細情報が表示されるようになりました。 ユーザー一覧を表示する表には、各ユーザーがアクセスできる拡張機能を列挙するExtensionsという新しい列が含まれています。
さらに、特定のユーザーがアクセス権を持つアクセスレベル、拡張機能、およびグループメンバーシップを表示および変更するには、選択したユーザーごとに用意されたコンテキストメニュー(ユーザーがアクセスできるすべての情報を理解し、ワンストップで調整できる)を使用します。
各管理者に、チームを簡単に稼働させるために必要なツールが用意されていることを理解していただきたいと思っています。 この取り組みの一環として、改善されたプロジェクト招待ダイアログをリリースします。 この新しいダイアログにより、プロジェクト管理者は、メンバーになるべきチームにユーザーを簡単に追加できます。 プロジェクト管理者またはチーム管理者の場合は、プロジェクトのホームページまたはTeam MemberウィジェットのAddボタンをクリックしてこのダイアログにアクセスできます。
Graph REST APIリソースを使用すると、開発者はVSTSのユーザー、グループ、およびグループメンバーシップを管理するアプリケーションを作成できます。 このAPIセットでは、MSAまたはAADユーザーをVSTSに追加する方法、VSTSグループを作成する方法、VSTSグループにメンバーを追加/削除する方法など、主要なユーザー管理シナリオについて説明します。 APIの詳細については、ドキュメントとサンプルをご覧ください。
私たちは、VSTS内のユーザー間のより良いつながりを促進したいと考えています。 この取り組みの一環として、ユーザープロファイルカードを更新しています。これにより、VSTSアカウント内の他のユーザーと対話したり、他のユーザーについてもっと知ることができます。 デフォルトのメールとIMクライアントとの統合により、プロファイルカードから直接電子メールを送信してチャットを開始することができます。 プロファイルカードは、連絡先カードのアイコン、プロフィール画像、またはコメント内のユーザーの名前をクリックして、作業項目、プルリクエスト、およびセキュリティ設定内でアクティブにすることができます。
Azure Active Directory(AAD)ユーザーは、Reports toでの階層とダイレクトレポートのユーザーレポートを見ることができます。
以前は、RESTのドキュメントは、REST APIにアクセスするための手段としてPATにのみ焦点を当てていました。 拡張と統合のドキュメントを更新して、アプリケーションのシナリオに応じて最適な認証方法のガイダンスを用意しました。 ネイティブのクライアントアプリケーション、インタラクティブなWebアプリケーションを開発している場合でもPowershellを使用してAPIを呼び出す場合でも、VSTSでの認証に最適な方法についての明確なサンプルがあります。 詳細についてはドキュメントを参照してください。
私たちはあなたがこれらの機能についてどう考えているのか知りたいと思っています。 新しいフィードバックメニューで優先順位をつけたいと思っていることに関するアイデアがある場合は、問題を報告するか、提案を提出してください。
Stack Overflowコミュニティで疑問の回答とアドバイスが得られるでしょう。
ありがとうございました。
Aaron Bjork