セキュリティとワークフローの効率の向上

このスプリントは、セキュリティの強化とワークフローの効率の合理化に重点を置いたさまざまな改善をもたらします。 これらの機能強化の中で、Azure Pipelines のサービス接続作成エクスペリエンスです。 これにより、チームは、ワークロード ID フェデレーションを使用して、既存のマネージド ID を使用してサービス接続を設定できます。 また、構成が簡略化され、特権を超える ID のリスクも軽減されます。

さらに、Azure Repos では、人魚構文を持つマークダウン ファイルがファイル プレビューと pull request で図としてレンダリングされ、ドキュメントのより明確なビジュアルが提供されることをお知らせします。

最後に、GitHub Advanced Security では、プル要求注釈が依存関係とコード スキャンのためのインライン通知を提供するようになりました。これにより、コード レビュー中にチームが潜在的な問題を検出して対処するプロセスが簡略化されます。

詳細については、リリース ノートを参照してください。

全般

• コード ブロックをクリップボードにコピーする
• Microsoft Entra プロファイル情報 (プレビュー)

GitHub Advanced Security for Azure DevOps

• 依存関係とコード スキャン用のプル要求注釈
• 依存関係スキャンのための新しい pip 検出戦略

Azure Boards:

• 作業項目フォームでのタグ管理の強化
• 作業項目のコメントでの画像のサポートが改善されました
• GitHub pull request insights

Azure Repos

• プル要求のターゲット ブランチを構成する
• マークダウン ファイル プレビューでの人魚図のサポート

Azure Pipelines

• Azure Pipelines でホストされるエージェント上の Ubuntu 24.04
• Azure 統合テストでワークロード ID フェデレーションを使用する
• マネージド ID のサポートが強化された新しい Azure サービス接続作成エクスペリエンス
• 親ステージが失敗したときに子ステージを実行する

Azure Artifacts

• パブリック フィードと Cargo を使用した Azure Artifacts への認証

Wiki

• HTML ベースのコンテンツの Wiki への貼り付けを改善する

全般

コード ブロックをクリップボードにコピーする

developer コミュニティでのフィードバックに応じて、レンダリングされたマークダウン内のすべてのコード ブロックに対して [クリップボードにコピー] ボタンが導入されました。 この拡張機能は、Wiki ページ、Repos のマークダウン ファイル プレビュー、pull request ディスカッションと説明、作業項目のディスカッションで利用できます。

Microsoft Entra プロファイル情報 (プレビュー)

Microsoft Entra プロファイル情報が Azure DevOps に統合され、個別のプロファイル更新が不要になります。 プレビューを試すには、 Preview 機能で Microsoft Entra プロファイル情報を有効にします。

有効にすると、 profile 設定 は読み取り専用になり、Microsoft Entra から自動的に設定されます。 以前の設定に戻すか、フィードバックを提供するには、プレビューをオフにしてコメントを共有します。

GitHub Advanced Security for Azure DevOps

依存関係とコード スキャン用のプル要求注釈

高度なセキュリティ ロードマップの一環として、 pull-request 注釈 を使用できるようになりました。 ビルド検証ポリシーに関連付けられているパイプラインを使用するすべてのプル要求に対してインライン注釈を受け取ります。これには、依存関係やコード スキャン タスクが含まれます。

関連するブランチのビルド検証ポリシーを作成する以外に、追加のオプトインは必要ありません。

注釈の Show more details をクリックすると、該当するアラートのアラート詳細ビューが表示されます。

詳細については、 最新のブログ記事を参照してください。

依存関係スキャンのための新しい pip 検出戦略

依存関係スキャンでは、 pip インストール レポート 機能に基づいて、Python: PipReport の新しい検出戦略が使用されるようになりました。 この更新プログラムは、実際の pip install 実行で取得される正確なバージョンを判断するために環境指定子を尊重することで、精度を向上させます。 既定では、検出器はpypi.orgを使用して依存関係グラフを構築します。 必要に応じて、パイプライン環境変数を設定PIP_INDEX_URL、代わりに依存関係グラフを構築できます。 フィードへのアクセスに認証の問題がある場合は、フィードにアクセスできるように、 PipAuthenticate@1 パイプライン タスクを設定する必要があります。

検出戦略の詳細については、 Pip 検出 ドキュメントを参照してください。

Azure Boards

作業項目フォームでのタグ管理の強化

Azure Boards でのタグ管理が強化され、より合理化されたエクスペリエンスが提供されました。 削除されたタグは作業項目フォームの推奨リストに表示されなくなり、アクティブなタグのみが表示されます。

作業項目のコメントでの画像のサポートが改善されました

作業項目のコメントに画像を貼り付けるサポートが改善されました。 Microsoft Teams、メール、Word 文書などのソースから作業項目のディスカッション セクションに画像を直接貼り付けることができるようになりました

GitHub pull request insights

GitHub pull requests と Azure Boards の統合が強化されました。 開いている状態と終了した状態を表示するだけでなく、pull request が下書きモードかどうか、レビューが必要かどうか、およびチェックの状態を確認できるようになりました。 プル要求を開く必要なく、すべて。

この機能を有効にするには、GitHub の Boards アプリに移動して、チェックへの読み取りと書き込みアクセスに対して要求された更新されたアクセス許可を受け入れるようにします。

Azure Repos

プル要求のターゲット ブランチを構成する

特に新しいプル要求を作成する場合、リポジトリ内の複数のブランチを管理するのは困難な場合があります。 新しいプル要求のターゲット ブランチの構成機能を使用すると、優先するターゲット ブランチの一覧を指定できるようになり、pull request の提案がより正確で関連性が高くなります。 これにより、ワークフローを合理化し、間違ったブランチをターゲットにする可能性を減らすことができます。 この機能を使用するには、リポジトリの既定のブランチに.azuredevops/pull_request_targets.yml ファイルを作成します。 この YAML ファイルには、候補の分岐に一致するブランチ名またはプレフィックスを持つ pull_request_targets というタイトルのリストが含まれている必要があります。 次に例を示します。

pull_request_targets:
  - main
  - release/*
  - feature/*

この構成では、メイン ブランチが優先されますが、 release/ または feature/ で始まるブランチも、必要に応じて考慮されます。 構成は、次のシナリオで適用されます。

• Pull Request Suggestions: ブランチを Azure DevOps にプッシュした後、Repos ページでは、ターゲット ブランチを動的に選択して、そのブランチからのプル要求の作成を提案する場合があります。
• Pull Request URL: sourceRef パラメーターを使用して pull request 作成ページに直接移動するが、targetRef パラメーターを省略すると、Azure DevOps はこの動的な選択に基づいてターゲット ブランチを選択します。

チップ コミットの最初の親の履歴の一貫性を確保するために、プル要求ポリシーによって保護されたブランチのみを含めうことをお勧めします。

マークダウン ファイル プレビューでの人魚図のサポート

人魚構文を含む Markdown ファイルが、リポジトリ ファイル ブラウザーと pull request のファイル プレビュー内の図としてレンダリングされるようになりました。 これは、リポジトリに豊富なドキュメントを追加するのに役立ちます。

Azure Pipelines

Azure Pipelines でホストされるエージェント上の Ubuntu 24.04

Ubuntu 24.04 イメージは、Azure Pipelines でホストされているエージェントで使用できるようになりました。 このイメージを使用するには、 vmImage:'ubuntu-24.04'を含むように YAML ファイルを更新します。

- job: ubuntu2404
  pool:
    vmImage: 'ubuntu-24.04'
  steps:
  - bash: |
      echo Hello from Ubuntu 24.04
      lsb_release -d

Note

ubuntu-latestイメージ ラベルは、今年後半まで ubuntu-22.04 を指し続けます。

インストールされているソフトウェアについては、 Ubuntu 24.04 イメージの readme を参照してください。

Azure 統合テストでワークロード ID フェデレーションを使用する

6 月には、Azure ID ライブラリ for.NET、C++、Go、Java、JavaScript、Python ワークロード ID フェデレーションのサポートが追加されました。 これにより、 AzureCLI@2 タスクと AzurePowerShell@5 タスクから実行されるコードが、 AzurePipelinesCredential クラスで Microsoft Entra で認証 (たとえば、Azure にアクセスする) 機能が追加されました。

多くのお客様は、他のタスクから呼び出された統合テストで Azure ID ライブラリを使用しています。 DotNetCoreCLI@2、Maven@4、VSTest@3タスクに対するAzurePipelinesCredentialのサポートが追加されました。

connectedService プロパティは、ワークロード ID フェデレーションで構成された Azure サービス接続に設定できます。 AzurePipelinesCredentialでは、SYSTEM_ACCESSTOKENを設定する必要があります。

- task: DotNetCoreCLI@2
  inputs:
    command: 'run'
    connectedService: <Azure service connection configured with workload identity federation>
  env:
    SYSTEM_ACCESSTOKEN: $(System.AccessToken)

AzurePipelinesCredentialの詳細については、このブログの投稿を参照してください。

マネージド ID のサポートが強化された新しい Azure サービス接続作成エクスペリエンス

新しい Azure サービス接続の作成エクスペリエンスにより、柔軟性が向上し、既定値がセキュリティで保護されます。 また、Microsoft Entra ID オブジェクトを作成するユーザーが別のポータルを移動するときに、手動で解釈を深めることができるように、用語を Microsoft Entra ID と一致させます。

新しい Azure Resource Manager サービス接続を作成するときに、ID を構成するためのさまざまなオプションが、前に使用した個別の最上位レベル項目を置き換える単一の統合ダイアログで使用できるようになりました。

ID の種類 には、Azure サービス接続でサポートされているすべての認証スキームが一覧表示されます。

アプリの登録では、Credentialを個別に選択して、ID フェデレーションまたはシークレットをworkload できます。

Azure サービス接続マネージド ID のサポート

既存のマネージド ID を選択し、それを使用して、ワークロード ID フェデレーションを使用するサービス接続を構成できるようになりました。 まず、ユーザー割り当てマネージド ID を作成。

次に、Azure サービス接続を作成し、 管理 ID ID の種類を選択します。 これにより、マネージド ID のフェデレーション ID 資格情報が構成されます。

エージェント (プール) に割り当てられたマネージド ID を使用するオプションの名前が 管理 ID (エージェント割り当て) に変更されました。 特権を超えるマネージド ID を共有しないようにするには、エージェント プールに割り当てられたマネージド ID ではなく、ワークロード ID フェデレーションでマネージド ID を使用することをお勧めします。

また、Microsoft Entra ID でアプリ登録が できない場合にアプリ登録を作成できないユーザーには、マネージド ID も推奨されるオプションです。

ワークロード ID フェデレーションでマネージド ID を使用するには、まず、マネージド ID を保持するサブスクリプションとリソース グループを選択します。 これは、パイプライン ジョブでサービス接続がアクセスするサブスクリプションとは異なる場合があります。 ワークロード ID フェデレーション用に構成されているマネージド ID を選択します。 ユーザーがフェデレーション ID 資格情報を作成するには、マネージド ID に対する Managed Identity Contributor ロールまたは同等のアクセス許可が必要です。

引き続き、サービス接続のデプロイ スコープとして使用されるサブスクリプションを選択します。

[サービス管理リファレンス] フィールド

一部の組織では、ITSM データベースからの関連コンテキスト情報をアプリ登録の Service Management Reference に設定する必要があります。 これを行う必要がある場合、ユーザーはサービス接続の作成時にこの参照を指定できます。

詳細

新しい Azure サービス接続の作成エクスペリエンスは、翌月にロールアウトされます。 詳細については、以下を参照してください:

• Azure サービス接続のドキュメント
• ワークロード ID フェデレーション
• トラブルシューティング

親ステージが失敗したときに子ステージを実行する

Azure Pipelines を使用してデプロイを続行しやすくしました。 これは、たとえば、Pipelines を使用して複数の Azure リージョンにアプリケーションの新しいバージョンをデプロイする場合に便利です。

たとえば、5 つの連続する Azure リージョンにデプロイする必要があるとします。 パイプラインにリージョンごとにステージがあり、各ステージに AzureResourceManagerTemplateDeployment タスクを実行するジョブがあり、テレメトリをログに記録するとします。 後者は持っているのは良いですが、重要ではありません。 テレメトリのログ記録に問題があるとします。 これでステージが失敗し、デプロイが停止します。

このスプリント以降では、ステージが失敗したときに、その子ステージの実行を再開できます。

Azure Artifacts

パブリック フィードと Cargo を使用した Azure Artifacts への認証

Cargo クライアントの制限により、認証はすべてまたは何も行われませんでした。 プライベート フィードの場合は認証が送信されますが、匿名ユーザーを許可する必要がある パブリック フィードでは、使用可能であったり必要であったりしても、認証は送信されません。

これで、認証されたユーザーは、プライベート フィードと同様に、パブリック Azure Artifacts フィードに接続できます。 自分またはパイプライン エージェントに アップストリーム ソースからパッケージを保存するためのアクセス許可がある場合フィードを介して crates.io からパッケージにアクセスできます。 この変更により、フィード管理者の手でフィードに戻すことができるパッケージを制御できます。 アップストリーム ソースからフィードにパッケージが取り込まれると、匿名ユーザーはそれらにアクセスできるようになります。

認証を確保するには、レジストリ URL のフィード名に ~force-auth を追加します。 詳細については、パブリック ドキュメントを参照してください。

Wiki

HTML ベースのコンテンツの Wiki への貼り付けを改善する

HTML ベースのコンテンツを Wiki に簡単に貼り付けできるようになりました。 リンク、リスト、テーブル、画像、Excel シート、Microsoft Teams メッセージ、電子メール、Azure Data Explorer クエリなどの HTML 要素が自動的に Markdown 構文に変換され、編集がスムーズになりました。

次のステップ

Note

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

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

Azure DevOps に移動する

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

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

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

よろしくお願いします。

Dan Hellem