今回のアップデートでは、Azure Artifactsを他の一般的なパッケージマネージャーと組み合わせた場合でも簡単に認証できるようになりました。実際の実装についての詳細は以下をご覧ください。
- タスクボードとスプリントバックログをフィルタリングする"Parent Work Item"フィルターを追加しました
- Bug/Taskフィールド移動ルールの必須化に伴うエラーハンドリングエクスペリエンスを改善しました
- スケールセットエージェントのプレビュー提供開始しました
- Azure Pipelines hostedプールでUbuntu 20.04をプレビュー提供開始しました
- YAMLパイプラインでGitHubパッケージをサポートします
Sprint BoardとSprint Backlogの両方に新しいフィルターを追加しました。今回の強化で、要件レベルのバックログ項目（左側の最初の列）について親でフィルタリングできるようになりました。たとえば、下のスクリーンショットでは、親が「My big feature」であるユーザーストーリーのみを表示するようにフィルタリングしています。
歴史的に、カンバンボードでは、作業項目をある列から別の列に移動させる状態の変更がフィールドルールのトリガーとなった場合、カードには赤いエラーメッセージが表示され、根本的な原因を理解するために作業項目を開く必要がありました。Sprint170では、作業項目自体を開かなくても、赤いエラーメッセージをクリックするだけでエラーの詳細の確認ができるように、エクスペリエンスの改善をおこないました。
私たちは、スケールセットエージェントと呼ばれる新機能をプレビューで公開しています。これは、Microsoft-hostedエージェントの利便性と弾力性のある容量と、self-hostedエージェントの制御性と柔軟性を組み合わせたものです。このプレビューでは、Azureサブスクリプションでエージェントを完全に自動化された仕様で管理できるようになりました。以下のような場合には、Microsoft-hostedまたは、self-hostedのエージェントではなく、スケールセットエージェントの使用を検討するとよいでしょう。
- Microsoft-Hostedネイティブエージェントで提供しているものよりも、より多くのメモリ、より多くのプロセッサ、より多くのストレージ、またはより多くのI/Oが必要な場合。
- Microsoft-Hostedエージェントがあなたの管理サーバーと通信するために、企業のファイアウォール内で多数のIPアドレスをホワイトリストに登録したくない場合。
- お客様の大規模なニーズに対応するためには、当社が提供できる数以上のMicrosoft-hostedエージェントが必要な場合。
- Microsoft-Hostedエージェントの並列ジョブを、組織内の個々のプロジェクトやチームにパーティショニングする機能が必要な場合。
- 専用のエージェントを24時間稼働させたいのではなく、アクティブに利用されていないエージェントマシンのプロビジョニングを解除したい場合。
スケール セット エージェントを使用するには、まずAzureサブスクリプションでVM Scale Setを作成し、Azure PipelinesでそのScale Setを指すエージェントプールを作成します。Azure Pipelinesは、保留中のジョブの数と、常に維持したいアイドルマシンの数に基づいて、このプールを自動的にスケールします。また、Azure Pipelinesは、これらの仮想マシンにエージェントをインストールします。詳細については、scale set agentを参照してください。この機能をプレビューする際には、ドキュメント ページにフィードバックを記載してください。
Ubuntu 20.04イメージをAzure Pipelinesホスティングプールのプレビューで利用できるようになりました。このイメージを使用するには、YAMLファイルにvmImage:'ubuntu-20.04'を含むように変更してください。ubuntu-20.04が今年後半にプレビュー版として公開されるまで、ubuntu-latestイメージのラベルはubuntu-18.04を指し続けますのでご注意ください。
ubuntu 20.04のイメージはプレビュー版なので、現在のところubuntu-18.04で利用できるすべてのツールをサポートしていないことに注意してください。詳細はこちらを参照してください。
先日、packagesという新しいリソースタイプを導入し、YAMLパイプラインのリソースとしてGitHubからNuGetやnpmのパッケージを参照する機能をサポートしました。このリソースの一部として、GitHubから参照したいパッケージタイプ（NuGetやnpm）を指定できるようになりました。また、新しいパッケージバージョンのリリース時にパイプラインの自動トリガーを有効にすることもできます。現在はGitHubからパッケージが参照できるだけですが、今後はサポートを拡張して、NuGet、npm、Azure Artifactsなどの他のパッケージリポジトリのパッケージも参照できるようにする予定です。詳細は以下の例を参照してください。
resources:
packages:
- package: myPackageAlias # alias for the package resource
type: Npm # type of the package NuGet/npm
connection: GitHubConn # Github service connection of type PAT
name: nugetTest/nodeapp # <Repository>/<Name of the package>
version: 1.0.9 # Version of the packge to consume; Optional; Defaults to latest
trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers注意: 現在のGitHubパッケージはPATベースの認証しかサポートしていません。つまり、パッケージリソース内のGitHubサービス接続はPATタイプでなければなりません。この制限が解除されれば、他のタイプの認証もサポートする予定です。
デフォルトでは、パッケージはジョブ内で自動的にダウンロードされないため、以下に倣ってgetPackageマクロを使ってリソース定義してリソース内で定義したパッケージを参照するようにしてください。以下の例を参照してください。
- job: job1
pool: default
steps:
- getPackage: myPackageAlias # Alias of the package resourceAzure ArtifactsのWebインターフェイスは、フィードのアップストリームソースのうちひとつ以上が機能していない場合、通知するようになりました。アップストリームソースを使用すると、フィード (フィードA) を別のフィード (フィードB) で指し示すことができ、フィードAを参照しているユーザーがフィードに直接接続することなく、フィードBからパッケージへアクセスできるようになります。アップストリームソースの詳細については、Azure Artifactsのドキュメントを参照してください。アップストリームソースがソースで無効化されている場合、機能しない可能性があります。たとえば、Feed Bが告知なく削除された場合、参照しているユーザーはFeed Aを介してパッケージをフェッチできなくなります。過去には、このような状況は警告なしに起こる可能性があったため、依存関係が見つからず突然ビルドが中断されるといった、診断が困難な運用上の問題につながる可能性がありました（たとえば、上記の例ではFeed Bからソースを取得したパッケージがなくなった場合です）。今回の更新でAzure Artifactsは、フィードのアップストリームソースに問題がある場合に警告を表示します。問題が存在する場合、Azure Artifactsフィードの詳細ページにバナー（下の赤い矢印）が表示されます。
バナー内のリンクをクリックすると、自分のフィードの各上流ソースのステータスを表示するページが開きます。現在のフィードの各上流ソースの情報に加えて、「Last synced」列の下に現在の状態が表示されます。正常に動作しているアップストリームソースには、ソースの健全性が最後に確認された時間が緑色のチェックマークで表示されます。壊れているアップストリームソースには、チェックされた時間とともに赤い×が表示されます。検証が保留されているアップストリームソースには、青い情報アイコンが表示されます。
壊れたアップストリームソースの最後の同期時間をクリックすると、ダイアログが開き、問題の根本的な原因についての詳細が表示されます（表示されている場合）。たとえば、下の図では、対象のフィードが削除されたため、問題のアップストリームソースが機能していません。ダイアログには監査ログへのリンクも含まれており、誰が最近関連する変更を行ったかを理解するために役立ちます。パーミッション設定やAzure Artifactsのドキュメントへのリンクも、根本原因の調査に役立ちます。
Azure Artifactsに保存されているNuGetパッケージのライセンス情報の詳細を、Visual Studioでパッケージを閲覧しながら確認できるようになりました。これは、ライセンス参照や埋め込みライセンスを使用して表示されているライセンスに適用されます。Visual Studioのパッケージ詳細ページにライセンス情報へのリンクが表示されるようになりました（下の画像の赤い矢印）。
リンクをクリックすると、ライセンスの詳細を確認できるWebページに移動します。このエクスペリエンスは、ライセンス参照でも組み込みライセンスでも同じなので、Azure Artifactsに保存されているパッケージのライセンス詳細を一括して確認できます（ライセンス情報を指定してVisual Studioでサポートされているパッケージの場合）。
Azure Pipelinesの人気のあるパッケージマネージャーで、ライトウェイト認証タスクを使用して認証できるようになりました。これにはNuGet、npm、PIP、Twine、Mavenが含まれます。以前は、パッケージを公開したり、ダウンロードしたりする機能を含む多くの機能を提供するタスクを使用して、これらのパッケージマネージャーで認証していました。しかし、パッケージマネージャーと通信するすべてのアクティビティにこれらのタスクを使用する必要がありました。パッケージの公開やダウンロードなどのタスクを実行するために独自のスクリプトを用意していた場合、パイプラインでそれらのスクリプトを使用することはできませんでした。今では、パイプラインYAMLの中で独自に設計したスクリプトを使用して、これらの新しいライトウェイトタスクで認証が実行できます。npmを使った例。
この図での"ci"と"publish"コマンドの使用は任意であり、Azure Pipelines YAMLでサポートされている任意のコマンドを使用できます。これにより、コマンドの呼び出しを完全に制御できるようになり、パイプライン構成で共有スクリプトを簡単に使用できるようになります。詳細については、NuGet、npm、PIP、Twine、Maven認証タスクのドキュメントを参照してください。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
Aaron Hallberg