Azure Artifacts を使用すると、他のサービスとの統合が簡略化されます

この更新プログラムにより、他の一般的なパッケージ マネージャーと共に Azure Artifacts を簡単に認証できるようになりました。 実際の実装の詳細については、以下を参照してください。

機能

Azure Boards

• タスク ボードとスプリント バックログに "親作業項目" フィルターを追加する
• エラー処理エクスペリエンスの向上 - バグ/タスクの必須フィールド

Azure Pipelines

• スケール セット エージェントのプレビュー
• Azure Pipelines ホステッド プール用の Ubuntu 20.04 のプレビュー
• YAML パイプラインでの GitHub パッケージのサポート

Azure Artifacts

• 無効なアップストリーム ソースの通知
• ライセンス式と埋め込みライセンス
• 軽量な認証タスク

Azure Boards

タスク ボードとスプリント バックログに "親作業項目" フィルターを追加する

スプリント ボードとスプリント バックログの両方に新しいフィルターを追加しました。 これにより、要件レベルのバックログ項目 (左側の最初の列) を親でフィルター処理できます。 たとえば、次のスクリーンショットでは、ビューをフィルター処理して、親が "My big feature" であるユーザー ストーリーのみを表示しています。

エラー処理エクスペリエンスの向上 - バグ/タスクの必須フィールド

これまで、かんばんボードから、状態の変更によってフィールド ルールがトリガーされる列間で作業項目を移動した場合、カードには赤いエラー メッセージが表示され、作業項目を開いて根本原因を理解する必要がありました。 スプリント 170 ではエクスペリエンスが改善され、作業項目自体を開かずに赤いエラー メッセージをクリックしてエラーの詳細を表示できるようになりました。

Azure Pipelines

スケール セット エージェントのプレビュー

Microsoft がホストするエージェントの利便性とエラスティック容量と、セルフホステッド エージェントの制御と柔軟性を組み合わせ、スケール セット エージェントと呼ばれる新機能をプレビューしています。 このプレビューでは、Azure サブスクリプションで、完全に自動化された仕様に合わせてエージェントを管理できるようになりました。 次の場合は、Microsoft がホストするエージェントまたはセルフホステッド エージェントの代わりにスケール セット エージェントを使用することを検討してください。

• ネイティブの Microsoft ホステッド エージェントで提供されるメモリよりも多くのメモリ、より多くのプロセッサ、より多くのストレージ、またはより多くの I/O が必要
• 会社のファイアウォール内で多数の IP アドレスを一覧表示して、Microsoft がホストするエージェントがサーバーと通信することを許可したくない
• 大規模なニーズを満たすために Microsoft が提供できるよりも多くの Microsoft ホスト型エージェントが必要
• Microsoft がホストする並列ジョブを組織内の個々のプロジェクトまたはチームにパーティション分割する機能が必要
• 専用エージェントを 24 時間実行するのではなく、アクティブに使用されていないエージェント マシンのプロビジョニングを解除する必要がある

スケール セット エージェントを使用するには、まず Azure サブスクリプションに VM スケール セットを作成してから、そのスケール セットを指すエージェント プールを Azure Pipelines に作成します。 Azure Pipelines は、保留中のジョブの数と、常にメインするアイドル状態のマシンの数に基づいて、このプールを自動的にスケーリングします。 Azure Pipelines では、これらの仮想マシンにもエージェントがインストールされます。 詳細については、「スケール セット エージェント」を参照してください。 この機能をプレビューする際は、ドキュメント ページにフィードバックを含めてください。

Azure Pipelines ホステッド プール用の Ubuntu 20.04 のプレビュー

Ubuntu 20.04 イメージは、Azure Pipelines でホストされているプールのプレビューで使用できるようになりました。 このイメージを使用するには、vmImage: 'ubuntu-20.04' を含むように YAML ファイルを更新します。 ubuntu-20.04 が今年後半にプレビューから外れるまで、ubuntu-18.04 は ubuntu-18.04 を指し続けます。

ubuntu 20.04イメージはプレビュー段階であるため、現在、ubuntu-18.04で利用可能なすべてのツールをサポートしているわけではありません。 詳細情報

YAML パイプラインでの GitHub パッケージのサポート

最近、YAML パイプラインのリソースとして GitHub から NuGet パッケージと npm パッケージを使用するためのサポートを追加するパッケージと呼ばれる新しいリソースの種類が導入されました。 このリソースの一部として、GitHub から使用するパッケージの種類 (NuGet または npm) を指定できるようになりました。 新しいパッケージ バージョンのリリース時に、自動化されたパイプライン トリガーを有効にすることもできます。 現在、サポートは GitHub からのパッケージの使用にのみ使用できますが、今後は、NuGet、npm、AzureArtifacts などの他のパッケージ リポジトリからパッケージを使用するようにサポートを拡張する予定です。 詳細については、以下の例を参照してください。

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 package 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 resource

Azure Artifacts

無効なアップストリーム ソースの通知

フィードのアップストリーム ソースの 1 つ以上が機能していない場合、Azure Artifacts Web インターフェイスから通知されるようになりました。 アップストリーム ソースを使用すると、フィード (フィード A) を別のフィード (フィード B) にポイントし、フィード A のコンシューマーが直接接続しなくてもフィード B からパッケージにアクセスできます。 アップストリーム ソースの詳細については、Azure Artifacts のドキュメントを 参照してください。 アップストリーム ソースがソースで無効になっている場合は機能しない場合があります。たとえば、フィード B が自動的に削除された場合、顧客はフィード A を介してそこからパッケージをフェッチできません。以前は、この状況は警告なしで発生する可能性があり、依存関係が不足しているために突然ビルドが中断するなど、運用上の問題を診断するのが困難でした (つまり、上の例のフィード B からソースされたパッケージ)。 これで、フィードのアップストリーム ソースに問題がある場合、Azure Artifacts から警告が表示されます。 問題が存在する場合は、Azure Artifacts フィードの詳細ページにバナー (下の赤い矢印) が表示されます。

バナー内のリンクをクリックすると、フィードの各アップストリーム ソースの状態を示すページが開きます。 現在のフィードの各アップストリーム ソースに関する情報に加えて、[最終同期済み] 列に現在の状態が表示されます。 正常に動作しているアップストリーム ソースには、ソースの正常性が最後に検証された時点で緑色のチェックマークが表示されます。 切断されたアップストリーム ソースには、赤い X とチェックされた時間が表示されます。 検証が保留中のアップストリーム ソースには、青い情報アイコンが表示されます。

破損したアップストリーム ソースの最後の同期時刻をクリックすると、ダイアログが開き、問題の根本原因に関する詳細が共有されます (使用可能な場合)。 たとえば、次の図では、対象のアップストリーム ソースは、ターゲット フィードが削除されたため、機能していません。 ダイアログには、最近関連する変更を行ったユーザーを理解するのに役立つ監査ログへのリンクも含まれています。 アクセス許可の設定と Azure Artifacts ドキュメントへのリンクを使用して、根本原因を調査することもできます。

ライセンス式と埋め込みライセンス

Visual Studio でパッケージを参照しているときに、Azure Artifacts に格納されている NuGet パッケージのライセンス情報の詳細を確認できるようになりました。 これは、ライセンス式または埋め込みライセンスを使用して表されるライセンスに適用されます。 これで、Visual Studio パッケージの詳細ページ (下の図の赤い矢印) にライセンス情報へのリンクが表示されます。

リンクをクリックすると、ライセンスの詳細を表示できる Web ページが表示されます。 このエクスペリエンスはライセンス式と埋め込みライセンスの両方で同じであるため、Azure Artifacts に格納されているパッケージのライセンスの詳細を 1 か所で確認できます (ライセンス情報を指定し、Visual Studio でサポートされているパッケージの場合)。

軽量な認証タスク

軽量の認証タスクを使用して、Azure Pipelines の一般的なパッケージ マネージャーで認証できるようになりました。 これには、NuGet、npm、PIP、Twine、Maven が含まれます。 以前は、パッケージを発行およびダウンロードする機能など、大量の機能を提供するタスクを使用して、これらのパッケージ マネージャーに対して認証を行うことができました。 ただし、パッケージ マネージャーとやり取りするすべてのアクティビティに対してこれらのタスクを使用する必要があります。 パッケージの発行やダウンロードなどのタスクを実行するために実行する独自のスクリプトがある場合、パイプラインでそれらを使用することはできません。 これで、パイプライン YAML で独自の設計のスクリプトを使用し、これらの新しい軽量タスクで認証を実行できるようになりました。 npm を使用する例:

この図の "ci" コマンドと "publish" コマンドの使用は任意です。Azure Pipelines YAML でサポートされている任意のコマンドを使用できます。 これにより、コマンド呼び出しを完全に制御でき、パイプライン構成で共有スクリプトを簡単に使用できるようになります。 詳細については、NuGet、npm、PIP、Twine、Maven 認証タスクのドキュメントを参照してください。

次のステップ

Note

これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。

Azure DevOps に向かい、見てみましょう。

Azure DevOps に移動する

フィードバックの提供方法

これらの機能に関するご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。

Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。

よろしくお願いします。

アーロン・ハルベルク