Azure DevOpsのSprint 150 Updateに、ポータル内で組織の請求を管理する機能が追加されました。
新しいbillingタブから、請求に使用するAzureサブスクリプションを選択し、ユーザーを追加するタイミングで支払います。請求を管理するために、もうVisual Studio MarketplaceまたはAzureポータルへアクセスする必要はありません。
詳細については、以下の機能リストをご覧ください。
General:
Azure Boards:
Azure Repos:
Azure Pipelines:
- Kubernetes manifestタスク
- Dockerタスクの更新
- Kubectlツールインストーラー
- DockerレジストリーでのAzure containerレジストリーへのサービス接続
- hosted Ubuntuプールでcgroupsをサポート
- 一回だけ実行するエージェント
- Visual StudioテストタスクでのVisual Studio 2019(VS2019)のサポート
- Agent pool ユーザーインターフェースの更新
- YAMLファイル編集時のTaskアシスタント
- Hostedパイプラインイメージの更新
- ServiceNow統合の強化
- Azure PowerShell Azモジュールのサポート
- リソース承認の強化
- ビルドパイプライン結果保持ポリシーの単純化
- リリースでPipelinesの成果物を自動的に取得する
- Coberturaコードカバレッジレポートの更新
Reporting:
Wiki:
Administration:
昨年10月、私たちは新しいナビゲーションの一部としてダークテーマの公開プレビューをリリースしました。数ヶ月のプレビュー、フィードバックを吸い上げ、そしてエクスペリエンスを調整し、私たちはダークテーマの一般公開を発表できることに興奮しています。
Azure Active Directoryの採用の増加とセキュリティ管理にグループを使用しているお客様の普及に伴い、チームはAzure Boardsでそれらのグループを活用する方法をさらに模索しています。現在、In GroupまたはNot In Groupの演算子を使用して特定のユーザーによって割り当てられた、または変更された作業項目を照会するだけでなく、Azure Active Directoryグループの直接使用もできます。
詳しくは、Query Operationの資料を参照してください。
多くの場合、リポジトリのREADMEは、プロジェクトチームがソリューションへの貢献方法と使用方法についての情報を提供する場所です。今回の更新においてAzure Pipelinesのビルドまたは展開のステータスを持つことができるように、Azure Boardsのチームのボード用のバッジをREADMEに追加できます。バッジは、In Progressの列のみ、またはすべての列を表示するように設定できます。また、プロジェクトがオープンソースの場合は、一般公開もできます。
READMEがMarkdownに基づいている場合は、ステータスバッジ設定ページからサンプルのMarkdownをコピーしてファイルに貼り付けるだけです。
チームは、次回予定されている内容やスプリントの繰り返しに基づいて作業に集中することがよくありますが、先月または第1四半期に発生したすべての作業について報告するためにカレンダーというレンズを通して作業を振り返るのは興味深い方法です。今回の更新で、新しい**@StartOf**マクロで週、月、または年の始まりの日といった、日付ベースのクエリを実行できるようになります。
- @StartOfYear
- @StartOfMonth
- @StartOfWeek
- @StartOfDay
これらの各マクロは、異なる日付単位でデータのシフトを可能にする新しい修飾文字列も受け入れます。たとえば、State Change Date> = @StartOfYearおよびState Change Date <= @StartOfYear(“ + 3M”)を照会することで、今年の第1四半期に完了したすべての作業項目を検索するクエリを作成できます。詳しくは、query macroの資料を参照してください。
クエリ結果をWebからCSV形式のファイルへ直接エクスポートできるようになりました。
pull requestからターゲットブランチへの変更をマージするため、より多くのオプションを提供します。開発者コミュニティでもっとも要求されている2つの機能、Fast-Forwardd mergingとSemi-Linear merging("Rebase and Merge")のサポートを追加しました。
Complete Pull Requestダイアログでこれらの新しいオプションが利用可能になります。
新しくなったポリシー管理ページでは、管理者はブランチまたはブランチのフォルダーに対して許可されるマージ戦略の選択ができます。
注意事項
既存のポリシーはまだ維持されています。たとえば、ブランチに現在"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を完了するときに変更をスカッシュマージするかを選択できます。
マニフェストファイルを使用して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タスクをアップグレードしました。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のバージョン仕様入力に有効な値としては、Latestおよび、'v1.14.0'のようなsemverのバージョン文字列を受け入れます。
今回の更新で、プロジェクトの設定ページからDockerレジストリサービス接続が作成できるようになりました。接続を作成するには、Azure Active Directory(AAD)IDに関連付けられているいずれかのサブスクリプションでAzureコンテナーレジストリを選択します。Docker@2やKubernetesManifest@0などのコンテナレジストリへのサービス接続を必要とするすべてのタスクは、サービス接続から作成した接続をサポートします。
Linuxでは、メモリ使用率が高くなりすぎると、カーネルは残りのプロセスを保護するためにいくつかのプロセスを終了させます。Azure Pipelinesエージェントプロセスが強制終了の対象として選択された場合、パイプラインの実行は失敗し、エージェントとの通信が失われたというエラーメッセージが表示されます。Microsoft-hosted Ubuntuプールでは、カスタムcgroup内でステップを実行することによって、エージェントが終了される可能性を低減しています。利用可能なメモリを超えてもパイプラインは失敗する可能性がありますが、エージェントプロセスは存続するため、失敗を正しく報告する可能性が高くなります。プライベートのLinuxエージェントを実行している場合は、使用する設定が公開されているので、同様の設定が可能です。
Azure Container Instancesなどのインフラストラクチャを使用してエラスティックプライベートエージェントを実行している多くの場合、受付の際、各エージェントに1つのジョブのみを許可します。これまでは、エージェントを終了させる(失敗を報告する原因となる可能性がある)か、シャットダウン前にエージェントが別のジョブを受け取る可能性があるというリスクを受け入れる必要があるため、簡単な判断ではありませんでした。今回の更新で、エージェント設定に***--once**フラグを追加しました。このようにエージェントを設定すると、エージェントは1つのジョブしか受け入れずにシャットダウンします。
パイプラインでVisual StudioのテストタスクにVS2019のサポートを追加しました。 VS2019用のテストプラットフォームを使用してテストを実行するには、テストプラットフォームバージョンドロップダウンからLatestまたはVisual Studio 2019オプションを選択します。
プロジェクト設定のエージェントプール管理ページが新しいユーザーインターフェースで更新されました。今回の更新により、プール内で実行されているすべてのジョブを簡単に見えます。さらに、ジョブが実行されていない理由も簡単にわかります。
パイプライン用のYAMLファイルをより簡単に編集できるようにという、多くのフィードバックを受けています。前回のアップデートでは、インテリセンスサポートを追加しました。今回の更新でYAMLエディターにタスクアシスタントを追加します。YAMLファイルに新しいタスクを追加するための古典的なエディターと同じ、おなじみのエクスペリエンスが期待できます。この新しいアシスタントは、ピックリストやサービス接続などの一般的なタスク入力タイプのほとんどをサポートしています。新しいタスクアシスタントを使用するには、YAMLベースのパイプラインでEditを選択してからTask assistantを選択します。
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レポをご覧ください。
昨年12月、ServiceNow Change Managementとリリースパイプラインの統合を発表しました。各チームが自分の選んだサービスを使用し、効果的なエンドツーエンドの配信を可能にする、チーム間コラボレーションのための重要な機能です。今回の更新で、すべてのタイプの変更(通常、標準、緊急)をサポートするように統合を強化しました。さらに、組織内で行われているITSMプロセスに従い、既存のテンプレートを使用して新しい変更要求を作成するために使用されるゲートを指定できるようになりました。最後に、既存の変更依頼に基づいたリリース時、ServiceNowをゲートとすることもできます。これにより、ITチームが推奨するプロセスを変更する必要なく、CDを採用できます。
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ファイルで参照するとき、セキュリティを提供する必要がありました。同時に、本番以外のシナリオでこれらのタイプのリソースを使用するパイプラインを簡単に設定および使用できるようにしたいと考えていました。以前は、リソースに「すべてのパイプラインでの使用が許可されている」というマークを付ける設定を追加しました。
今回の更新では、リソースにそのようなマークを付けていなくても、リソース承認の問題を解決しやすくなりました。新しいエクスペリエンスでは、リソース承認エラーのためにビルドが失敗したとき、パイプラインでそれらのリソースの使用を明示的に承認するためのオプションが表示されてから続行します。リソース使用を承認する権限を持つチームメンバーは、失敗したビルドからこのアクションを完了できます。
YAMLビルドを含むすべてのビルドパイプラインの保存モデルを単純化しました。各パイプラインのビルド結果を保持する日数と、各ビルドの成果物を保持する日数を制御するためのプロジェクトレベルの新しい設定があります。クラシックパイプラインエディターを使用してビルドパイプラインを作成した場合、古い保持設定は引き続き使用されますが、新しいパイプラインは新しい設定を使用します。project settingsのpipeline settingsで保持日数を管理できます。
以前は、リリースにリンクされたビルドパイプラインが、Publish Pipeline Artifactタスクを使用して成果物を公開していた場合、成果物はリリース時自動的に取得されませんでした。よって、成果物をダウンロードするには、リリースパイプラインにDownload Pipeline Artifactタスクを明示的に追加する必要がありました。
今回の更新で、ビルドパイプラインによって公開されたパイプラインアーティファクトは自動的にダウンロードされ、リリースで利用可能になります。リリースパイプラインのフェーズプロパティから、パイプラインアーティファクトのダウンロードをカスタマイズもできます。
以前は、パイプラインでテストを実行し、コードカバレッジの結果をAzure DevOpsに発行するとき、XMLサマリーとHTMLレポートファイルの両方を指定する必要がありました。また、HTMLレポートのスタイルは、コードカバレッジタブに表示される前の段階で削除されました。任意のHTMLファイルをアップロードされる可能性があるため、このスタイルの削除はセキュリティの観点から必要でした。
今回のアップデートで、Coberturaのカバレッジレポートに対するこれらの制限に対処しました。コードカバレッジレポートを発行するときに、HTMLファイルを指定する必要がなくなりました。レポートは自動的に生成され、code coverageタブに適切なスタイルで表示されます。この機能は、オープンソースのツールReportGeneratorを使用しています。
パイプラインのスループットと安定性を継続的に向上させるための指標と洞察を得ることが重要です。パイプライン分析を提供するための最初のステップとして、パイプラインに関する測定基準と洞察を得るための2つのレポートを追加しました。
- 失敗レポートには、ビルド合格率と失敗傾向が表示されます。さらに、どのタスクが最大失敗数に寄与しているかについての洞察を提供するために、タスク失敗の傾向も示します。
- 期間レポートには、パイプライン実行ごとの傾向も表示されます。
次のAnalytics機能が追加費用なしでAzure DevOpsに含まれるという素晴らしいニュースをお知らせいたします。
- Analyticsウィジェットは、ダッシュボードにデータを表示し、作業の進行状況を監視するのに役立つ設定可能なモジュールです。 含まれているウィジェットは次のとおりです。
- バーンダウンチャートとバーンアップチャートは、一定期間の一連のスコープ作業の進行状況を監視します。
- チームの開発サイクルにおける作業の流れを視覚化するためのサイクルタイムとリードタイム
- 累積フロー図(CFD)は、作業項目のさまざまな状態が変わっていく状況を追跡します。
- ベロシティは、チームが複数のスプリントにわたって価値を提供していく方法を追跡します。
- テスト結果の傾向をテストして、単一または複数のパイプラインでテストの傾向を監視し、テストの失敗と期間のパターンを検出します。
- 製品には、パイプラインの信頼性の向上とテスト債務の削減を支援するために、パイプラインのもっとも失敗したテストに関する洞察を得るためのtop failing tests reportが含まれています。
また、Azure DevOps Servicesのすべてのお客様向けに、Power BI integration through analytics viewsの提供、およびODataエンドポイントへの直接アクセスのプレビューを引き続き提供します。
マーケットプレイスのAnalytics拡張機能を使用している場合は、以前と同じようにAnalyticsを引き続き使用できます。追加の手順に従う必要はありません。つまり、ホスティング顧客(訳注:Azure DevOps Serverのこと)向けのAnalyticsマーケットプレイス拡張を廃止する予定です。
Azure DevOps Analytics製品は今後のレポート作成であり、今後もAnalyticsが推進する新機能に投資します。以下のリンクでAnalyticsの詳細情報を公開しています。
- Analytics overview documentation
- Analytics widgets
- Top failing test report
- Power BI integration
- OData endpoint
- Azure DevOps Analytics
今までは、Wikiページのコンテンツがいつ変更されたかを知る方法がありませんでした。今回の更新で、ページの編集、削除、名前の変更があったとき、Wikiページ更新のタイミングで電子メール通知を受け取ることができます。Wikiに加えられた変更を追跡するには、WikiページからFollowボタンを選択します。
この機能は、この提案チケットに基づいて優先順位が付けられています。詳しくはこちらのドキュメントをご覧ください。
Azure DevOpsポータルから組織の請求を管理できるようになりましたことをお知らせいたします。管理者は、Azureポータル経由で請求を設定する必要がなくなりました。請求設定を管理するには、Orginization Settingに移動してBillingを選択します。
以下はBillingタブから管理できる設定の一覧です。
- 請求に使用するAzureサブスクリプションを選択できます。
- 組織が請求に使用するAzureサブスクリプションを変更するとき、別のサブスクリプションが選択できるようになりました。以前は、請求を削除してから、支払った各リソース(基本ユーザー、パッケージ管理ユーザー、MS Hostedパイプラインなど)に対して同じレベルを慎重に購入する必要がありました。このプロセスは面倒で、間違いを起こしやすいものでした。 別のサブスクリプションを選択してsaveをクリックすることで、組織が請求に使用するAzureサブスクリプションを変更できるようになりました。
- 課金設定を管理するためにVisual Studio Marketplaceへ移動しなくてもよくなりました。Basic、Test Manager、Package Management(Azure Artifacts)の各ユーザーに追加料金を支払う機能が追加されました。あなたの組織が新しいBillingタブから支払っているユーザーの数を増減できます。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Jeremy Epling