Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
translate to Japanese to VSTS release notes from https://www.visualstudio.com/ja-jp/articles/news/2016/nov-23-team-services

PRのフォロー、タスクビジョニング、ブランチのコミット検索 - 11/23

注意事項:この投稿で記載されている更新は今後一週間にわたって順次更新されます。

このスプリントで展開される多くの新機能を紹介します。

ブランチでのコミット検索

コミット時にSearch in branchesボタンをクリックすると、特定のブランチもしくはタグをコミットから検索できるようになりました。

commit search

コミット履歴からファイルやフォルダを検索

ファイルタブと同様に、ユーザーはリポジトリ内のファイルまたはフォルダを検索し、ファイルまたはフォルダのコミットの履歴を表示できるようになりました。 Gitリポジトリの場合、Historyタブのパスコントロールボックスに移動して、探したいファイルまたはフォルダ名を入力すれば、履歴検索が動作します。

commit history

プルリクエストのフォロー

プルリクエストをフォローすると、電子メールによる変更の通知が行われるようになりました。 Followオプションは、コンテキストメニューで使用できます。

Follow PR

プルリクエストのマージを再試行

ターゲットブランチが更新された場合に、プルリクエストのマージを再試行するための別のオプションが追加されました。 このRestart mergeオプションは、ターゲットブランチへの最近の変更によって競合が発生していないか、PRビルドが壊れていないことを確認する場合、便利です。

プルリクエストが拒否された場合、プルリクエストの完了をブロック

コードレビューポリシーが設定されているブランチ匂いて、1人以上のレビュワーによって拒否された場合、PRを完了できないことに気づくでしょう。 多くのユーザーがこの動作を期待しているので、デフォルト動作を変更しました。 元の動作が必要なチームの場合、ブランチポリシー設定ページに新しいオプションがあります。

code review policy

プルリクエストの詳細でMarkdownを使用可能に

Markdownを使ってプルリクエストの説明をよりリッチにしてください。 あなたがとても大好きなMarkdownがプルリクエストのコメント詳細で利用可能になりました。

ビルドトリリース定義でのタスクバージョニング

一般的なリクエストに基づき、ビルドまたはリリースで実行するタスクのメジャーバージョンを制御できます。 この変更により、エージェントとタスクのバージョンへの自動更新によって予期しないエラーが発生することはありません。 タスクのメジャーバージョンは、定義のBuildタブ、またはリリース定義のEnvironmentsタブで指定します。

マイナーバージョン(1.2から1.3など)がリリースされると、ビルド内で自動的に変更されます。 しかし、新しいメジャーバージョン(2.0など)がリリースされた場合、定義を編集して手動で新しいメジャーバージョンに変更するまで、ビルドはバージョン1.3にロックされたままになります。ビルド定義におけるフラグで、新しいメジャーバージョンの存在を警告します。

** 1. *(preview)**などの名前のバージョンを選択した場合、このバージョンはまだ開発中であり、既知の問題がある可能性があることに注意してください。

Tip:ビルド定義では、タスクの新しいメジャーバージョンをテストするためのいくつかのオプションがあります:

  • バージョンを変更して問題が発生した場合は、historyタブからその変更を元に戻すことができます。
  • ビルド定義を複製し、新しいメジャータスクバージョンで複製したビルド定義をテストします。

Hosted Linuxプールのプレビュー

新しいHosted Linux poolのプレビューを提供を始めたので、プライベートエージェントを設定することなく、Linuxマシンでビルドおよびリリースできます。

ホストされているLinuxプールのエージェントは、vsts-agent-docker containerがUbuntu Linuxホスト上で実行されます。 このコンテナには、標準Java、Node、Docker、および.NET Coreのすべてのツールが含まれています。コンテナを起動すると、ホストVMのDockerソケットと/opt/vsts/workの作業フォルダがマップされます。これを使うと、スクリプトまたはVisual Studio MarketplaceにあるDocker extensionを使用して、ビルドプロセスまたはリリースプロセスの一部でDockerコンテナを作成または展開することができます。

Hosted Linuxプールを使うには:

  • ビルド定義で、Generalタブに移動し、Default agent queueメニューを開き、Hosted Linuxを選択します。
  • リリース定義でEnvironmentsタブに移動し、Run on agentタスクを選択し、Deployment queueメニューを開き、Hosted Linuxを選択します。

まだオプションが表示されない場合、少し時間をください。 今後数週間で、このオプションをアカウントに展開していきます。

DockerアプリケーションのビルドとAzureへの展開を簡単に

Dockerアプリの継続的な統合とデプロイメント(CI / CD)をより身近にします:

  • Azure Container ServiceとAzure Container RegistryをサポートするようにDocker extensionを更新しました。
  • 独自のDockerホストを設定しなくてもいいように、Hosted Linux poolのプレビューを開始します。
  • Visual Studio 2017 RCをリリースし、新しい継続的展開ツールをASP.NET Core Previewアプリ用にインストールします。 これらのツールを使用して、Team ServicesでCI/CDプロセスを迅速に構成することができます。 Dockerのサポートが有効になっているASP.NETコアプロジェクトを設定すると、GitプッシュごとにAzure Container Serviceに対して自動ビルドおよびデプロイメントを実行します。

新しいBuildとRelease Managementのライセンスモデル

次の2週間で、BuildとRelease Managementは、現在のエージェントベースのライセンスモデルから並列パイプラインベースのライセンスモデルに移行します。 各パイプラインでは、1つのビルドを実行したり、一度に1つのリリースを展開したりできます。 同時に実行できる並行ビルドの最大数と、同時に展開できるリリースは、所有しているパイプラインの数によってのみ制限されます。

Team Servicesアカウントでは以下の無料の使用権が含まれます:

  • One free Hosted Pipeline:この無料のホステッドパイプラインを使用すると、1か月あたり4時間(240分)、ビルドまたはデプロイメントごとに最大30分の時間がかかります。同時ビルドまたはリリースに同時にビルド時間が必要な場合は、buy another hosted pipelineを4時間という制限に縛られず、ビルドまたはデプロイメントあたりの最大継続時間を最大6時間に制限します。より多くの同時ビルドまたはリリースが必要になる場合は、hosted pipelinesで購入してください。
  • One free Private Pipeline:Team Foundation Server 2017で一度に1つのリリースを無制限に実行するか、または1つのビルドを実行するか、Microsoftから入手するエージェントソフトウェアを使って、Team Servicesで一度に1つのリリースを展開します。プライベートエージェントは現在無料で無制限です。TFSでは、各Visual Studio Enterpriseサブスクライバも、使用できるプライベートパイプラインを提供します。 より多くのプライベートパイプラインを購入することも可能です。

より詳細は Concurrent build and release pipelines in Team Services 及び、 Concurrent release pipelines in TFSをみてください.

以前Azureポータルでプライベートエージェントを購入していた場合、自動的にプライベートパイプラインにロールバックされます。 同様に、購入したホストエージェントはすべて、ホストされたパイプラインになります。 新しいライセンスモデルでは、任意の数のプライベートエージェントをアカウントに登録できます。 実際に、新しいモデルでは、同じ価格で、以前のモデルよりも多くの選択肢を提供します。

NuGet + 認証プロバイダーバンドルの更新

NuGet + 認証プロバイダーをバンドルしたNuGet 3.5をリリースしました。NuGet 3.5には多くのperformance improvements and bug fixesが含まれているため、更新を推奨します。

テスト成果物を削除

すでに、テスト成果物およびテスト成果物にリンクされている作業項目を除いて、すでに作業項目を削除することができています。 今回のアップデートにより、ユーザーはTestハブとWorkハブのいずれでも、作業項目フォームのコンテキストメニューのPermanently deleteオプションを使ってテスト成果物(テスト計画、テストスイート、テストケース、共有パラメータ、共有ステップ)を永久に削除することができます。。

delete test artifacts menu

テスト成果物の削除は、選択した成果物を削除するだけでなく、子テストスイート、すべての構成とテスト担当者のテスト、テスト結果の履歴、およびその階層に属する他の関連する履歴などのすべての子アイテムも削除します。 確認ダイアログボックスでは、ユーザーは削除操作の影響を表示して情報に基づいた決定を下すことができます。

delete test artifacts confirm

Build と Releaseでインラインのサービス接続

この機能を使用すると、Servicesタブに移動せずに、ビルド/リリース定義でサービス接続を作成することができます。 これはDocker、Jenkins、VMWare、SCVMMなど、宣言的に定義されたすべての拡張機能に対して自動的に有効になります。

他のチームプロジェクトにビルド成果物をリンクする

これまでのリリース定義では、同一プロジェクトからの成果物ソースのみをリンクすることができました。 今回から別のプロジェクトのビルド成果物をリンクすることができます。 成果物をリンクしている間、プロジェクトドロップダウンでアカウント内のすべてのプロジェクトが一覧表示されます。

build artifacts

いつも通り、もしもUsersVoiceにあるアイディアの優先順位を変えたい場合、ぜひ投票してください。

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

Erin Dormier

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment