Translate to Japanese to VSTS release notes from https://docs.microsoft.com/ja-jp/vsts/release-notes/2017/dec-11-vsts

2017-dec-11-team-services-jajp.md

不安定なテストの識別、拡張機能のインストールエクスペリエンスの強化 - VSTS Sprint 127アップデート

Visual Studio Team Services(VSTS)のSprint 127でのアップデートには、テスト結果と実行の管理に役立つ新しい機能と、エコシステムの価値をさらに高めるための新しいMarketplaceエクスペリエンスがあります。テストとマーケットプレイスの改善についての詳細を紹介します。

そのほかの新機能ハイライト。

• 既存のビルド定義からYAMLテンプレートを生成できるようになりました - ビルド定義エディタでビルドから対応するYAMLビルドロジックを生成します。
• マルチフェーズビルドが強化されました - より良いビルドのために、さまざまなエージェント、並列テスト、および条件付き実行のサポート。
• リポジトリ内で何も変更されていなければ、スケジュールされたビルドをスキップします - リソースを節約し、余分なビルドのノイズを避けます。
• クラウドソリューションプロバイダー(CSP)の購入が一般的に利用可能になりました - CSPプログラムを使用して、より深く関与できるようにできます。

注意事項

これらの紹介している機能は今週中(12/17まで)に順次展開されます。

Code

buildとreleaseでGitレポジトリにpushされたコードを追跡

Pushページで、マージコミットのビルドとリリースの状態が表示できます。Pushの横にあるstatusをクリックすると、pushされたコードで実行された特定のビルドまたはリリースが表示され、成功を確認したり、ビルド失敗の原因の調査ができます。

Blameで履歴を閲覧できるようになった

Blameビューは、コード行を変更する最後の人物を特定するのに適しています。しかしながら、以前に誰がコード行に変更を加えたのかを知る必要があることがあります。 そんな時、最新の改善で追加されたView blame prior to this commitを使ってください。名前が示すとおり、この機能を使用すると、特定の行を変更したバージョンより前のバージョンのファイルにさかのぼって戻し、そのバージョンを修正した人の情報が表示されます。選択したコード行を変更したファイルの各バージョンを見て、時間をかけてさかのぼり続けられます。

SSH URLが変更されます

重要な変更
VSTSでSSHを使用している場合は、このセクションを注意深くお読みください。 最近になっていない場合は、SSH URLを更新する必要があります。

より効率的なルーティングのためにAzure Traffic Managerを使用するようにSSHの実装を進めています。我々が実施したテストでは、この新しいアプローチにより、離れたVSTSインスタンスにアクセスする場合、多くのGit操作で最大5倍のパフォーマンス改善が得られることがわかりました。Azure Traffic Managerを使用して、近くのVSTSインスタンスに接続のルーティングを行い、高速なAzureバックボーンを使用して離れたデータセンターに接続することで、高速化を実現しています。しばらく前にAzure Traffic Managerをサポートする新しいSSH URLのサポートを追加しました。このSprintでは、古いURLのサポートを削除しています。そのため、SSHで接続している場合、gitのremoteホストを更新する必要があります。詳細については、SSH URLの更新に関するドキュメントを読んでください。

Build and Release

既存のビルド定義からYAMLテンプレートを生成する

先月のConnect(); 2017で、YAMLビルドのパブリックプレビューを発表しました。YAMLビルドは、グラフィカルビルド定義エディタではなく、コードでチェックインされたYAMLファイルでビルドプロセスを設定します。我々はWeb UIのビルド定義をYAMLファイルへの返還を簡単にする機能を用意しました。ビルドのビルド定義エディタで、左側のProcessタブを選択し、右側のペインでView YAMLリンクをクリックします。テキストをクリップボードにコピーし、その内容のファイルをレポジトリにチェックインします。次に、新しいビルドYAMLベースのビルド定義作り、チェックインされたYAMLファイルを参照します。

これは、YAMLを素早く学ぶ良い方法としても使用できます。アプリケーションに適したテンプレートを使って新しいビルド定義を作成し、今使っているビルド定義と新しいYAML構造とのマッピングを理解するために生成されたYAMLファイルを比較します。

複数フェーズビルドの強化

注意事項
この機能を使うには、あなたのアカウントでBuild with multiple queuesプレビュー機能を有効にする必要があります。

数週間前に、ビルド定義で複数のフェーズをサポートする機能を追加しました。フェーズを使用してビルドステップを編成したり、各フェーズごとに異なる要求(訳注:Demandsで指定する値です)を使用してさまざまなエージェントをターゲット設定することができました。今回のアップデートでは、フェーズを構築するためのいくつかの機能を追加しました。

• フェーズごとに異なるエージェントキューを指定します。つまり、次のようなことができます。
  • macOSエージェントでビルドの1つのフェーズを実行し、Windowsエージェントで別のフェーズを実行します。これがいかに有益であるかのクールな例を見るには、Connect(); 2017の CI/CD DevOps Pipeline for mobile apps and servicesというビデオを見てください。
  • ビルド・エージェント・プールでビルド・ステップを実行し、テスト・エージェント・プールでテスト・ステップを実行します。
• テストを並行して実行することでテストをより速く実行します。並列性が"Multi-agent"で構成され、"VSTest"タスクを含むフェーズでは、設定されたエージェント数の範囲で自動的にテスト実行が並列化されます。
• スクリプトが各フェーズでOAuthトークンにアクセスすることを許可または拒否する。たとえば、ビルドフェーズで実行されているスクリプトがVSTS over REST APIと通信できるようになり、同じビルド定義でテストフェーズで実行されているスクリプトではブロックされるようになります。
• 特定の条件の下でのみフェーズを実行します。たとえば、前のフェーズが成功した場合にのみ、またはmasterブランチにコードを作成する場合にのみ、フェーズを実行するようにフェーズを設定できます。

詳細はPhases in Build and Release Managementを見てください。

ビルド結果ページで空のセクションを隠す

VSTS拡張機能は、ビルドレポートに有用な情報を追加するために、ビルドレポートに独自のセクションの追加ができます。これまでは、VSTSアカウントに拡張機能がインストールされると、ビルドレポートセクションに特定のビルド定義が実際にセクションを作成するビルドタスクを使用するかどうかに関係なく、表示されていました。このスプリントで、ビルド拡張機能の作成者がビルドタスクで、ビルドレポートセクションに結果を追加するか指定できるようになる機能を展開しました。レポート結果があるタスクを1つ以上使用するビルド定義に対してのみセクションが表示されます。

拡張機能でのsupportsTasksプロパティの使い方はsample extensionを見てください。

もしレポジトリに変更がなければ、スケジュールビルドをスキップする

UserVoiceでの一般的なリクエストから、コード内で何も変更がない場合にスケジュールされたビルドが実行されないように指定できるようになりました。この動作は、スケジュールのオプションを使用して制御できます。既定では、(同じスケジュールからの)最後のスケジュールされたビルドが合格し、それ以上の変更がリポジトリにチェックインされていない場合、新しいビルド実行をスケジュールしません。

UIテスト実行時Hosted VS2017エージェントにソフトウェアをインストールする

もし、Hosted VS2017キューを使う場合、インタラクティブモードのタスクで「管理者として実行」をビルド定義で設定できます。これは、ホストプールでソフトウェアのUIテストの実行及びインストールに管理者権限が使えることを意味します。

ASP.NET Core 2.0エージェント

ビルドエージェント 2.125以降ではASP.NET Core 2.0で動いていました。よって、以前はUbuntu, Red Hat/CentOSでしか実行できませんでした。現在のリリースでは、Oracle Linux 7, Fedora, DebianほかのLinuxディストリビューションで実行できるようになりました。詳細はLinux System Prerequisitesを読んでください。

Package Manegementの成果物のRelease Trigger

Release ManagementのPackage management成果物をトリガを設定すると、パッケージの新しいバージョンが公開されたときに新しいリリースが自動的に作成されます。 詳細は、リリース管理のトリガのドキュメントを参照してください。

既定の成果物バージョン

バージョン管理システムの成果物をリリース定義にリンクするときに、いくつかのデフォルトのバージョンオプションがあります。特定のコミット/変更セットを設定することも、デフォルトのブランチから選択するように最新のバージョンを設定することもできます。通常、最新のバージョンを取得するように設定しますが、すべての将来的な展開において、ゴールデンアーティファクトバージョンを指定する必要がある環境では、これは特に便利です。

ブランチを指定したリリーストリガーの強化

ビルド定義で指定されているデフォルトのブランチに基づいてリリース・トリガー・フィルターを構成できるようになりました。これは、デフォルトのビルドブランチがすべてのスプリントを変更し、すべてのリリース定義にわたってリリーストリガフィルタを更新する必要がある場合に特に役立ちます。ビルド定義のデフォルトブランチを変更するだけで、すべてのリリース定義でこのブランチが自動的に使用されます。たとえば、チームがスプリント毎に生成されるペイロードのリリースブランチを作成している場合、新しいスプリントにおいて、新しいリリースブランチを指すようにビルド定義を更新すると、リリースは自動的にビルド定義側のブランチに追従します。

Test

巨大なテスト結果をフィルタリングする

時間が経つとテストアセットが発生し、大規模なアプリケーションでは容易に数千ものテストに膨れ上がります。多数のテストを含むこれらの大規模なアプリケーションでは、テストの失敗、関連する根本的な原因または問題の所有権を特定することで、すべてのテスト結果を管理することが難しい場合があります。このような状況を改善するために、テスト結果ビューに2つの新しいフィルタ、コンテナ(DLL)と所有者(コンテナ所有者)、Build and ReleaseにTestタブを追加しました。これにより、テスト結果の関連する部分のみに対して、簡単にフィルタリングすることができます。

さらに、既存の結果フィルタに、複数の結果をフィルタリングする機能を提供します。ユーザーが自分自身でコミットした変更のテストの結果を確認したいときは、コンテナ(DLL名)または所有者(DLL所有者)、またはその両方をフィルタリングして、関連する結果が得られます。また、今後テスト名に基づいてフィルタを追加する予定です。

不安定なテストを識別する

時にテストは不安定です - 1回の実行で失敗し、変更なしで別のテストに合格します。フレークテスト(Flaky test)は、イライラすることがあり、テストの有効性に自信を失い、失敗を無視したり、バグを突き抜けたりします。このアップデートでは、フレークテストの問題に取り組むための最初のソリューションを導入しました。**Visual Studio Test&&タスクを構成して、失敗したテストを再実行できるようになりました。試験結果は、どの試験が最初に不合格であったかを示し、再試験に合格したことを示します。 データ駆動型テストと注文型テストの再実行のサポートは今後追加される予定です。

Visual Studio Testタスクは、失敗したテストを再実行する試行の最大回数と、広範囲にわたる失敗の場合に備えて、テストの再実行を行わない失敗のしきい値のパーセンテージ(すべてのテストの20％未満が失敗した場合のみテストを再実行するなど)を制御するように構成できます。

Build and ReleaseのTestタブでは、テスト結果を「再実行時に合格」としてテスト出力物でフィルタリングして、実行中に動作が信頼できないテストを特定できます。これは現在、再実行時に渡された各テストの最後の試行を表示します。 "Summary"ビューは、"Total tests"の下で"Passed on rerun(n / m)"を表示するようにも変更されています。ここでnは再実行時に渡されたテストの数、mは合格とした合計テストです。すべての試行の階層的なビューは、次のいくつかのスプリントで提供予定です。

Marketplace

Marketplaceエクスペリエンスの強化

Visual Studio Marketplaceの拡張機能の説明ページでタブを有効にして、必要な情報を簡単に見つけられるようにしました。価格設定、Q＆A、または評価＆レビュー情報へのアクセスをより簡単にしました。 ページを下にスクロールしても、これらのタブは常に表示されるため、ビュー内の一回の操作で実行できます。

マーケットプレイスからVSTSエクステンションとVisual Studioサブスクリプションを取得(または購入)する方法を改訂しました。

• インストール/購入ウィザードでは、ログイン、VSTSアカウントの選択など、進行状況に応じて利用可能な操作が調整されるようになりました。これにより、エクステンションの取得がより簡単で直感的になります。
  

• 支払済の金額とその請求内容を変更するために必要なすべての関連情報は、情報提供された購入を行うためにフロー内に表示されます。
  

• 進捗バーには取得の進行状況が表示され、複数のステップをナビゲートできます。

• アカウント管理者に依頼して、VSTSユーザーまたはパイプラインを購入するリクエストを送信することで、購入が許可されていないユーザーにも簡単に利用できるようになりました。
  

• アカウント管理者は、既存のAzureサブスクリプションに必要な権限がない場合、VSTSアカウントに関連付けられているAzureサブスクリプションを変更できるようになりました。

パブリッシャー管理ポータルの刷新

パブリッシャー管理ポータルはマーケットプレイスベースで更新されており、さまざまなディレクトリ/テナント間でログインしているすべてのパブリッシャーを簡単に表示できます。関連する役割(所有者、コントリビューターなど)も表示されます。メンバーを管理し、サイト運営者の詳細にアクセスすることで、サイト運営者の管理を支援ができます。

パブリッシャーの操作時のエクスペリエンスを向上させるための第一歩として、パブリッシャーはパブリッシャーが作成されたディレクトリー/テナントを選択できるようになりました。

マーケットプレイスでのすべての拡張機能にウィルススキャン

マーケットプレイスでは、すべての公開拡張の追加ゲートを実施しました。ウイルススキャンです。スキャンが成功した場合のみ、拡張機能がMarketplaceにリストされ、消費者が使用できるようになります。これは、既存の拡張機能と新しい拡張機能、およびそれらのすべての拡張機能にまたがります。拡張機能の検証が完了した後、電子メールでパブリッシャーに通知されます。

拡張機能パブリッシャー向けのTFX CLI変更

TFX CLIは、拡張検証でウイルススキャンを含むように改訂されました。拡張機能の検証時間は、拡張機能パッケージのサイズに大きく依存し、最大20分かかります。新しいパラメータ**--nowait-validationがpublishコマンドに追加され、パブリッシャまたは自動パイプラインがCLIツールの完了を待つ必要がなくなります。拡張機能は、検証が成功した後にのみ、Marketplaceに公開され、利用可能になります。公開者には、拡張機能検証の完了後に電子メールで通知される、または拡張機能のshow**コマンドを使用して検証のステータスを知ることができます。

Administration

Cloud Solution Provider支払いが一般提供

Visual Studio MarketplaceからCloud Solution Provider(CSP)プログラムを使用しての購入が、現在CSPがサポートされているすべてのオファー/マーケットでご利用いただけます。これらの市場のCSPパートナーは、Visual Studio Subscriptions、Visual Studio Team Servicesユーザー、Visual Studio Marketplaceからのファーストパーティ拡張機能(Test Manager、Hosted Pipelines、Package Managementなど)を購入できるようになりました。Visual Studio Marketplaceは今、すべてのファーストパーティ拡張機能の購入に対するAzure CSPサブスクリプションを認識して受け入れます。また、CSPは、サブスクリプション管理ポータル、AzureポータルのVSTSアカウントの設定、既存のVSTSアカウントのAzure CSPサブスクリプションへのリンクなど、顧客から購入したVisual Studioサブスクリプションを管理することもできます。

Feedback

これらの機能についてどう思っているかお聞きしたいと思います。フィードバックメニューを使用して、優先順位を付けたいと思っていることに関するアイデアがある場合は、問題を報告するか、提案をしてください。

アドバイスや回答が必要な質問がある場合、Stack Overflowコミュニティで聞いてください。

ありがとうございました。

Ravi Shanker