Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
ranslate to Japanese to Azure DevOps release notes from https://docs.microsoft.com/en-us/azure/devops/release-notes/2019/sprint-150-update

Azure DevOpsでの組織ごとの請求の管理が可能に - Sprint 150 Update

Azure DevOpsのSprint 150 Updateに、ポータル内で組織の請求を管理する機能が追加されました。

新しいbillingタブから、請求に使用するAzureサブスクリプションを選択し、ユーザーを追加するタイミングで支払います。請求を管理するために、もうVisual Studio MarketplaceまたはAzureポータルへアクセスする必要はありません。

詳細については、以下の機能リストをご覧ください。

Features

General:

Azure Boards:

Azure Repos:

Azure Pipelines:

Reporting:

Wiki:

Administration:

General

ダークテーマの一般公開

昨年10月、私たちは新しいナビゲーションの一部としてダークテーマの公開プレビューをリリースしました。数ヶ月のプレビュー、フィードバックを吸い上げ、そしてエクスペリエンスを調整し、私たちはダークテーマの一般公開を発表できることに興奮しています。

Azure Boards

Azure Active Directoryグループベースで動作するクエリ

Azure Active Directoryの採用の増加とセキュリティ管理にグループを使用しているお客様の普及に伴い、チームはAzure Boardsでそれらのグループを活用する方法をさらに模索しています。現在、In GroupまたはNot In Groupの演算子を使用して特定のユーザーによって割り当てられた、または変更された作業項目を照会するだけでなく、Azure Active Directoryグループの直接使用もできます。

詳しくは、Query Operationの資料を参照してください。

Query for Work based

バッジを使って、チームのボードを共有する

多くの場合、リポジトリのREADMEは、プロジェクトチームがソリューションへの貢献方法と使用方法についての情報を提供する場所です。今回の更新においてAzure Pipelinesのビルドまたは展開のステータスを持つことができるように、Azure Boardsのチームのボード用のバッジをREADMEに追加できます。バッジは、In Progressの列のみ、またはすべての列を表示するように設定できます。また、プロジェクトがオープンソースの場合は、一般公開もできます。

Share your team's boards using badge

READMEがMarkdownに基づいている場合は、ステータスバッジ設定ページからサンプルのMarkdownをコピーしてファイルに貼り付けるだけです。

Badge in a Readme on GitHub

週、月、年の開始の日に関連した作業項目クエリ

チームは、次回予定されている内容やスプリントの繰り返しに基づいて作業に集中することがよくありますが、先月または第1四半期に発生したすべての作業について報告するためにカレンダーというレンズを通して作業を振り返るのは興味深い方法です。今回の更新で、新しい**@StartOf**マクロで週、月、または年の始まりの日といった、日付ベースのクエリを実行できるようになります。

  • @StartOfYear
  • @StartOfMonth
  • @StartOfWeek
  • @StartOfDay

これらの各マクロは、異なる日付単位でデータのシフトを可能にする新しい修飾文字列も受け入れます。たとえば、State Change Date> = @StartOfYearおよびState Change Date <= @StartOfYear(“ + 3M”)を照会することで、今年の第1四半期に完了したすべての作業項目を検索するクエリを作成できます。詳しくは、query macroの資料を参照してください。

Query for work relative to the start of the day, week, month, or year

クエリ結果をCSVへエクスポート

クエリ結果をWebからCSV形式のファイルへ直接エクスポートできるようになりました。

Export query for results

Azure Repos

新しいpull request完了時のマージタイプ

pull requestからターゲットブランチへの変更をマージするため、より多くのオプションを提供します。開発者コミュニティでもっとも要求されている2つの機能、Fast-Forwardd mergingSemi-Linear merging("Rebase and Merge")のサポートを追加しました。

Complete Pull Requestダイアログでこれらの新しいオプションが利用可能になります。

New merge types for completing pull requests

新しくなったポリシー管理ページでは、管理者はブランチまたはブランチのフォルダーに対して許可されるマージ戦略の選択ができます。

Limit merge types

注意事項

既存のポリシーはまだ維持されています。たとえば、ブランチに現在"squash merge only"のポリシーが設定されている場合、新しいマージ戦略を使用するためには現在のポリシーを編集する必要があります。

pull requestの完了時にリベースできない状況があります。

  • ターゲットブランチのポリシーでリベース戦略の使用が禁止されている場合、“Override branch policies”権限が必要になります。
  • pull requestのソースブランチにポリシーがある場合、リベースできません。リベースは、ポリシー承認プロセスを経ずにソースブランチを変更します。
  • マージ競合を解決するためにMerge Conflict Extensionを使用した場合、3wayマージ(訳注参考:Why is a 3-way merge advantageous over a 2-way merge?)に適用された競合解決は、一度に1つずつpull request内のすべてのコミットをリベースすると、成功することはめったにありません(または有効でさえある)。

これらすべての場合において、ブランチをローカルでリベースしてサーバーにプッシュするか、pull requestを完了するときに変更をスカッシュマージするかを選択できます。

Azure Pipelines

Kubernetes manifestタスク

マニフェストファイルを使用してKubernetesクラスターへデプロイするプロセスを簡素化するために、リリースパイプラインに新しいタスクを追加しました。このタスクは、スクリプトでのkubectlバイナリの使用と比較して、以下の利点を提供します。

  • Artifact substitution - デプロイアクションは、入力として、それらのタグまたはダイジェストと共に指定できるコンテナイメージのリストを受け取ります。これは、正しいバージョンのイメージが確実にクラスターのノードによってプルできるように、クラスターへ適用する前に、テンプレートではないバージョンのマニフェストファイルに置き換えられます。

  • Manifest stability - 安定性チェックを組み込むために、タスクステータスの成功/失敗を確認するため、デプロイされたKubernetesオブジェクトのロールアウトステータスがチェックされます。

  • Traceability annotations - Kubernetesオブジェクトをデプロイした組織(訳注:Azure DevOpsのorganizationのこと)、プロジェクト、パイプライン、および実行に関するトレーサビリティ情報をKubernetesオブジェクトに重ね合わせるため、アノテーションが追加されます。

  • Bake manifest - タスクのベイク(訳注:bakeというのは複数の異なったものを1つにするという意味です)処理により、Helm chartをKubernetesマニフェストファイルにベイク処理して、クラスターへ適用できるようになります。

  • Deployment strategy - 展開アクションでカナリア戦略(補足:CI/CD for microservices architectures)を選択すると、タスクのプロモート/リジェクトアクションを使用して、バージョンを決定する前に -baselineおよび***-canary**を付けて、割合を保持、ManualInterventionタスク、必要な割合のワークロードを比較できるように作成します。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)
    containers: |
      nginx: 1.7.9

Docker タスクの更新

パイプラインのオーサリングを簡単にするため、Dockerタスクをアップグレードしました。buildAndPushコマンドを使用して、特定のコンテナリポジトリ用に複数のタグを構築し、それを単一の手順で複数のコンテナレジストリにプッシュできます。タスクはDockerレジストリサービス接続を使用してコンテナレジストリにログインできます。このタスクを使用してビルドされたイメージには、ソースリポジトリ、コミット、およびビルドの起源に関するトレーサビリティメタデータがラベルとして追加されます。

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Kubectlツールインストーラー

特定のバージョンのKubectlバイナリをエージェントにインストールできる新しいタスクを追加しました。Kubectlのバージョン仕様入力に有効な値としては、Latestおよび、'v1.14.0'のようなsemverのバージョン文字列を受け入れます。

kubectl tool installer

DockerレジストリーでのAzure containerレジストリーへのサービス接続

今回の更新で、プロジェクトの設定ページからDockerレジストリサービス接続が作成できるようになりました。接続を作成するには、Azure Active Directory(AAD)IDに関連付けられているいずれかのサブスクリプションでAzureコンテナーレジストリを選択します。Docker@2KubernetesManifest@0などのコンテナレジストリへのサービス接続を必要とするすべてのタスクは、サービス接続から作成した接続をサポートします。

Add a Docker service container

hosted Ubuntuプールでcgroupsをサポート

Linuxでは、メモリ使用率が高くなりすぎると、カーネルは残りのプロセスを保護するためにいくつかのプロセスを終了させます。Azure Pipelinesエージェントプロセスが強制終了の対象として選択された場合、パイプラインの実行は失敗し、エージェントとの通信が失われたというエラーメッセージが表示されます。Microsoft-hosted Ubuntuプールでは、カスタムcgroup内でステップを実行することによって、エージェントが終了される可能性を低減しています。利用可能なメモリを超えてもパイプラインは失敗する可能性がありますが、エージェントプロセスは存続するため、失敗を正しく報告する可能性が高くなります。プライベートのLinuxエージェントを実行している場合は、使用する設定が公開されているので、同様の設定が可能です。

一回だけ実行するエージェント

Azure Container Instancesなどのインフラストラクチャを使用してエラスティックプライベートエージェントを実行している多くの場合、受付の際、各エージェントに1つのジョブのみを許可します。これまでは、エージェントを終了させる(失敗を報告する原因となる可能性がある)か、シャットダウン前にエージェントが別のジョブを受け取る可能性があるというリスクを受け入れる必要があるため、簡単な判断ではありませんでした。今回の更新で、エージェント設定に***--once**フラグを追加しました。このようにエージェントを設定すると、エージェントは1つのジョブしか受け入れずにシャットダウンします。

Visual StudioテストタスクでのVisual Studio 2019(VS2019)のサポート

パイプラインでVisual StudioのテストタスクにVS2019のサポートを追加しました。 VS2019用のテストプラットフォームを使用してテストを実行するには、テストプラットフォームバージョンドロップダウンからLatestまたはVisual Studio 2019オプションを選択します。

Support for Visual Studio 2019 (VS2019) in Visual Studio Test task

Agent poolユーザーインターフェースの更新

プロジェクト設定のエージェントプール管理ページが新しいユーザーインターフェースで更新されました。今回の更新により、プール内で実行されているすべてのジョブを簡単に見えます。さらに、ジョブが実行されていない理由も簡単にわかります。

Agent pool user interface update

YAMLファイル編集時のTaskアシスタント

パイプライン用のYAMLファイルをより簡単に編集できるようにという、多くのフィードバックを受けています。前回のアップデートでは、インテリセンスサポートを追加しました。今回の更新でYAMLエディターにタスクアシスタントを追加します。YAMLファイルに新しいタスクを追加するための古典的なエディターと同じ、おなじみのエクスペリエンスが期待できます。この新しいアシスタントは、ピックリストやサービス接続などの一般的なタスク入力タイプのほとんどをサポートしています。新しいタスクアシスタントを使用するには、YAMLベースのパイプラインでEditを選択してからTask assistantを選択します。

Task assistant for editing YAML files

Hostedパイプラインイメージの更新

OS X Mojave(10.4)にmacOS Poolをアップデートしたことを発表できることを楽しみにしています。これにはXcode 10.2のサポートも含まれます。デザイナーベースのパイプラインがHosted macOSプールを使用している場合、パイプラインは自動的にMojaveにアップグレードされます。OS X High Sierra(10.3)を使い続けたい場合は、ビルドを実行するプールをHosted macOS High Sierraに変更してください。

YAMLを使用している場合、使用できる新しいイメージラベルは次のとおりです。

  • 常に10.4の最新バージョンのmacOSを常に指すイメージラベル
vmImage: 'macOS-latest'
  • あなたのパイプラインが確実にMojaveに対して実行されるようにしたい場合、このイメージのラベル明示的に指定することで、Mac OS 10.4が対象となります。
vmImage: 'macOS-10.14'
  • パイプラインが確実にHigh Sierraに対して実行されるようにしたい場合、このイメージのラベルを明示的に指定することで、Mac OS 10.3がターゲットとなります。
vmImage: 'macOS-10.13'

Hosted Azureパイプライン用のWindows Server 2019イメージも更新しました。最新のリリースはここにあります。今回の更新では、VS2019プレビュー、Docker、PowerShellコア、Node.js、npmなどの新しいバージョンが含まれています。

Hosted macOS VMイメージに含まれているものの詳細、およびイメージで利用可能なツールについては、GitHubのImage Generationレポをご覧ください。

ServiceNow統合の強化

昨年12月、ServiceNow Change Managementとリリースパイプラインの統合を発表しました。各チームが自分の選んだサービスを使用し、効果的なエンドツーエンドの配信を可能にする、チーム間コラボレーションのための重要な機能です。今回の更新で、すべてのタイプの変更(通常、標準、緊急)をサポートするように統合を強化しました。さらに、組織内で行われているITSMプロセスに従い、既存のテンプレートを使用して新しい変更要求を作成するために使用されるゲートを指定できるようになりました。最後に、既存の変更依頼に基づいたリリース時、ServiceNowをゲートとすることもできます。これにより、ITチームが推奨するプロセスを変更する必要なく、CDを採用できます。

ServiceNow change management

Azure PowerShell Azモジュールのサポート

Azure PowerShellには、コマンドラインからAzureリソースを管理するために使用できる一連のコマンドレットが用意されています。去年の12月に、Azure PowerShell Azモジュールが利用可能になり、今ではAzureリソースを管理するためのモジュールです。

これまでは、ホストエージェントでAzure PowerShell Azモジュールのサポートを提供していませんでした。新しいAzure PowerShellタスクバージョン4.*をビルドパイプラインおよび、リリースパイプライン内で使用するため、すべてのプラットフォームで新しいAzモジュールのサポートが追加されました。Azure PowerShellタスクバージョン3.* は、引き続きAzureRMモジュールをサポートします。ただし、最新のAzureのサービスと機能を維持するには、できるだけ早くAzure PowerShellタスクバージョン4.*に切り替えることをお勧めします。

Azモジュールには、既存のスクリプトを使用しながら新しい構文を使用できるようにするための互換モードがあります。Azモジュールとの互換性を有効にするには、Enable-AzureRmAliasコマンドを使用します。エイリアスを使用すると、Azモジュールで古いコマンドレット名を使用できます。Azure RMモジュールからAzure PowerShell Azモジュールへの移行の詳細については、こちらを参照してください。

注意事項

プライベートエージェントを使用している場合、エージェントマシンにAzモジュールをインストールする必要があります。

Azure PowerShell Azモジュールの詳細については、こちらのドキュメントを参照してください。

リソース承認の強化

保護されたリソース(サービス接続、変数グループ、エージェントプール、安全なファイルなど)をYAMLファイルで参照するとき、セキュリティを提供する必要がありました。同時に、本番以外のシナリオでこれらのタイプのリソースを使用するパイプラインを簡単に設定および使用できるようにしたいと考えていました。以前は、リソースに「すべてのパイプラインでの使用が許可されている」というマークを付ける設定を追加しました。

今回の更新では、リソースにそのようなマークを付けていなくても、リソース承認の問題を解決しやすくなりました。新しいエクスペリエンスでは、リソース承認エラーのためにビルドが失敗したとき、パイプラインでそれらのリソースの使用を明示的に承認するためのオプションが表示されてから続行します。リソース使用を承認する権限を持つチームメンバーは、失敗したビルドからこのアクションを完了できます。

Pipeline summary with authorization error

ビルドパイプライン結果保持ポリシーの単純化

YAMLビルドを含むすべてのビルドパイプラインの保存モデルを単純化しました。各パイプラインのビルド結果を保持する日数と、各ビルドの成果物を保持する日数を制御するためのプロジェクトレベルの新しい設定があります。クラシックパイプラインエディターを使用してビルドパイプラインを作成した場合、古い保持設定は引き続き使用されますが、新しいパイプラインは新しい設定を使用します。project settingspipeline settingsで保持日数を管理できます。

リリースでPipelinesの成果物を自動的に取得する

以前は、リリースにリンクされたビルドパイプラインが、Publish Pipeline Artifactタスクを使用して成果物を公開していた場合、成果物はリリース時自動的に取得されませんでした。よって、成果物をダウンロードするには、リリースパイプラインにDownload Pipeline Artifactタスクを明示的に追加する必要がありました。

今回の更新で、ビルドパイプラインによって公開されたパイプラインアーティファクトは自動的にダウンロードされ、リリースで利用可能になります。リリースパイプラインのフェーズプロパティから、パイプラインアーティファクトのダウンロードをカスタマイズもできます。

Coberturaコードカバレッジレポートの更新

以前は、パイプラインでテストを実行し、コードカバレッジの結果をAzure DevOpsに発行するとき、XMLサマリーとHTMLレポートファイルの両方を指定する必要がありました。また、HTMLレポートのスタイルは、コードカバレッジタブに表示される前の段階で削除されました。任意のHTMLファイルをアップロードされる可能性があるため、このスタイルの削除はセキュリティの観点から必要でした。

今回のアップデートで、Coberturaのカバレッジレポートに対するこれらの制限に対処しました。コードカバレッジレポートを発行するときに、HTMLファイルを指定する必要がなくなりました。レポートは自動的に生成され、code coverageタブに適切なスタイルで表示されます。この機能は、オープンソースのツールReportGeneratorを使用しています。

Code Coverage

Reporting

ビルド失敗と、期間レポート

パイプラインのスループットと安定性を継続的に向上させるための指標と洞察を得ることが重要です。パイプライン分析を提供するための最初のステップとして、パイプラインに関する測定基準と洞察を得るための2つのレポートを追加しました。

  1. 失敗レポートには、ビルド合格率と失敗傾向が表示されます。さらに、どのタスクが最大失敗数に寄与しているかについての洞察を提供するために、タスク失敗の傾向も示します。

Build failure and duraion reports

  1. 期間レポートには、パイプライン実行ごとの傾向も表示されます。

Pipeline duration report trends

Analyticsの一般公開

次のAnalytics機能が追加費用なしでAzure DevOpsに含まれるという素晴らしいニュースをお知らせいたします。

  1. Analyticsウィジェットは、ダッシュボードにデータを表示し、作業の進行状況を監視するのに役立つ設定可能なモジュールです。 含まれているウィジェットは次のとおりです。

Burndown and Burnup charts

Cycle Time and Lead Time

  • 累積フロー図(CFD)は、作業項目のさまざまな状態が変わっていく状況を追跡します。

Cumulative Flow Diagram

  • ベロシティは、チームが複数のスプリントにわたって価値を提供していく方法を追跡します。

Velocity

  • テスト結果の傾向をテストして、単一または複数のパイプラインでテストの傾向を監視し、テストの失敗と期間のパターンを検出します。

Test Results Trend

  1. 製品には、パイプラインの信頼性の向上とテスト債務の削減を支援するために、パイプラインのもっとも失敗したテストに関する洞察を得るためのtop failing tests reportが含まれています。

Test failure report

また、Azure DevOps Servicesのすべてのお客様向けに、Power BI integration through analytics viewsの提供、およびODataエンドポイントへの直接アクセスのプレビューを引き続き提供します。

マーケットプレイスのAnalytics拡張機能を使用している場合は、以前と同じようにAnalyticsを引き続き使用できます。追加の手順に従う必要はありません。つまり、ホスティング顧客(訳注:Azure DevOps Serverのこと)向けのAnalyticsマーケットプレイス拡張を廃止する予定です。

Azure DevOps Analytics製品は今後のレポート作成であり、今後もAnalyticsが推進する新機能に投資します。以下のリンクでAnalyticsの詳細情報を公開しています。

Wiki

Wikiページの更新通知

今までは、Wikiページのコンテンツがいつ変更されたかを知る方法がありませんでした。今回の更新で、ページの編集、削除、名前の変更があったとき、Wikiページ更新のタイミングで電子メール通知を受け取ることができます。Wikiに加えられた変更を追跡するには、WikiページからFollowボタンを選択します。

Wiki page

この機能は、この提案チケットに基づいて優先順位が付けられています。詳しくはこちらのドキュメントをご覧ください。

Administration

Azure DevOpsから組織の請求を管理する

Azure DevOpsポータルから組織の請求を管理できるようになりましたことをお知らせいたします。管理者は、Azureポータル経由で請求を設定する必要がなくなりました。請求設定を管理するには、Orginization Settingに移動してBillingを選択します。

以下はBillingタブから管理できる設定の一覧です。

  1. 請求に使用するAzureサブスクリプションを選択できます。

Organization settings billing

  1. 組織が請求に使用するAzureサブスクリプションを変更するとき、別のサブスクリプションが選択できるようになりました。以前は、請求を削除してから、支払った各リソース(基本ユーザー、パッケージ管理ユーザー、MS Hostedパイプラインなど)に対して同じレベルを慎重に購入する必要がありました。このプロセスは面倒で、間違いを起こしやすいものでした。 別のサブスクリプションを選択してsaveをクリックすることで、組織が請求に使用するAzureサブスクリプションを変更できるようになりました。

Billing Azure Subscription ID

  1. 課金設定を管理するためにVisual Studio Marketplaceへ移動しなくてもよくなりました。Basic、Test Manager、Package Management(Azure Artifacts)の各ユーザーに追加料金を支払う機能が追加されました。あなたの組織が新しいBillingタブから支払っているユーザーの数を増減できます。

Billing pay for additional users

Next steps

注意事項

ここで議論されている機能は今後二~三週にわたって順次展開されます。

これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。

Go to Azure DevOps Services

Feedback

これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。

Make a suggestion

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

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

Jeremy Epling

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