Azure Pipelines Linuxエージェントの展開方法と4.x移行の注意点

Azure Pipelines Linuxエージェントを使っている組織で、いま最初に確認すべきことは 4.x agent softwareへの対応状況、Linux OSのサポート範囲、認証方式、ファイアウォール許可リスト、実行ユーザーの権限 です。特にSelf-hosted Linux agentsを運用している場合、単にエージェントを入れ替えるだけでは不十分です。OSが.NET 8ベースの4.xエージェントに対応しているか、ビルドに必要なツールがCapabilitiesとして認識されているか、サービス実行時の環境変数が正しく反映されているかまで確認する必要があります。(Microsoft Learn)

この記事では、Microsoft AzureのAzure Pipelinesにおける「Deploy an Azure Pipelines agent on Linux」の公式情報をもとに、Linux向けセルフホステッドエージェントの変更点、影響範囲、管理者・開発者が確認すべき移行と展開の注意点を実務目線で整理します。

Azure Pipelines Linuxエージェントで何が変わるのか

今回のポイントは、Azure PipelinesのLinuxセルフホステッドエージェントで 4.x agent softwareが中心になる ことです。公式ドキュメントでは、Azure DevOps ServicesまたはAzure DevOps Serverを利用している場合は4.x agent softwareを使うべきだと明記されています。4.xエージェントは.NET 8ベースで、従来の3.xエージェントは.NET 6ベースです。(Microsoft Learn)

Azure Pipelinesのエージェントは、ビルド、テスト、デプロイのジョブを実行する実体です。LinuxエージェントではJavaやAndroidアプリなどもビルド・デプロイできますが、前提OS、Git、ネットワーク、認証、実行ユーザーの設計を誤ると、パイプラインが突然失敗したり、エージェントの自動更新で止まったりする可能性があります。(Microsoft Learn)

まず、変更の全体像を押さえましょう。

確認項目	変更・確認すべき内容	実務上の影響
エージェントバージョン	Azure DevOps Services / Azure DevOps Serverでは4.x利用が推奨	古い3.x前提の運用は見直しが必要
実行基盤	4.xは.NET 8ベース	OSが.NET 8対応範囲に入っているか確認が必要
Linux OS	Ubuntu 20.04/22.04/24.04、RHEL 8/9などが4.xの対象	Ubuntu 18.04やRHEL 7などは移行計画が必要
認証	PAT、Device code flow、Service principalなどを選択	登録用認証と日常実行権限を分ける設計が重要
ネットワーク	*.dev.azure.comやdownload.agent.dev.azure.comなどの許可が必要	プロキシ・FW環境では事前検証が必須
運用	systemdサービス、Capabilities、環境変数、診断ログを確認	ツール追加後の再起動忘れでジョブが割り当たらないことがある

影響を受けるのはSelf-hosted Linux agentsを使っている環境

影響が大きいのは、Azure Pipelinesで Self-hosted Linux agents を運用している環境です。Microsoft-hosted agentで要件を満たせる場合、Linuxエージェントを自前でセットアップする必要はありません。公式ドキュメントでも、Azure DevOps Servicesを使っていてMicrosoft-hosted agentで十分なら、セルフホステッドLinuxエージェントの構成は不要とされています。(Microsoft Learn)

一方で、次のようなケースではセルフホステッドエージェントの利用価値があります。

利用シーン	Self-hosted Linux agentsが向いている理由
社内ネットワーク内のシステムへデプロイする	閉域網、VPN、プライベートDNSなどに対応しやすい
独自ツールや古いSDKが必要	必要なCLI、JDK、Android SDK、npm、社内ツールを事前導入できる
ビルドキャッシュを保持したい	毎回クリーンな環境ではなく、依存関係や成果物キャッシュを活用できる
ライセンス付きツールを使う	特定端末・特定ユーザーに紐づく商用ツールを利用しやすい
高性能マシンを使いたい	CPU、メモリ、ストレージ、GPUなどを自社要件に合わせられる

ただし、セルフホステッドエージェントは「自由度が高い」代わりに「責任範囲も広い」構成です。OS更新、エージェント更新、権限管理、シークレット保護、ネットワーク許可、ツールのバージョン管理は利用者側で設計・運用する必要があります。

4.xエージェント移行で最初に見るべきLinux OS

4.x agent softwareは.NET 8ベースです。そのため、OSが.NET 8対応範囲に入っていない場合、単純にエージェントだけを更新しても安定稼働しません。Microsoftの公式情報では、4.xエージェントのLinux対応例として、x64ではDebian 12、Fedora 39/40、RHEL 8/9、Ubuntu 20.04/22.04/24.04、Azure Linux 2.0、Oracle Linux 8/9などが挙げられています。ARM64ではDebian 11/12、Ubuntu 20.04/22.04/24.04などが対象です。(Microsoft Learn)

運用中のLinuxエージェントでは、まず次のコマンドでOSを確認します。

cat /etc/os-release
uname -m

確認すべき観点は、単に「Linuxだから動くか」ではありません。ディストリビューション、バージョン、CPUアーキテクチャ、パッケージリポジトリ、プロキシ設定まで含めて判断します。

現在の環境例	判断
Ubuntu 24.04 / 22.04 / 20.04	4.xエージェント移行の候補になりやすい
RHEL 8 / 9	4.xエージェント移行の候補になりやすい
Debian 12	x64環境では4.x対象として確認しやすい
Ubuntu 18.04 / 16.04	4.x前提では移行計画が必要
RHEL 7	4.x前提では移行計画が必要
Oracle Linux 7	4.x前提では移行計画が必要
Alpine 3.13	4.xではなく、より新しいAlpineへの移行を検討

3.xエージェントではUbuntu 18.04やRHEL 7なども対象に含まれていましたが、4.xでは対象範囲が変わります。公式情報でも、3.xではサポートされていた一部OSが.NET 8ベースの4.xでは使えないと整理されています。(Microsoft Learn)

実務では、エージェントの移行を「エージェントバイナリの更新作業」と捉えるのではなく、OS更改プロジェクトの一部 として扱うべきです。古いOSで動いているビルド環境は、ビルドツールやランタイムも古い可能性が高いため、パイプライン定義、SDK、Dockerfile、社内リポジトリの依存関係も合わせて確認します。

3.xエージェントを使い続ける場合の注意点

Azure DevOps Server 2022やAzure DevOps Server 2020では、3.xエージェントに関する情報も残っています。ただし、Azure DevOps Servicesでは3.x agent softwareはサポート外とされ、4.xへのアップグレードが推奨されています。(Microsoft Learn)

ここで誤解しやすいのは、「いま動いているから問題ない」と考えてしまうことです。パイプライン側のタスクやAzure DevOps側の機能更新により、新しいエージェントバージョンが必要になることがあります。古いエージェントでは、将来のタスク実行やセキュリティ対応で制約が出る可能性があります。(Microsoft Learn)

特に次の条件に当てはまる場合は、早めに棚卸ししてください。

• Ubuntu 18.04、Ubuntu 16.04、RHEL 7などでエージェントを動かしている
• Azure DevOps Servicesを使っているが、古い3.xエージェントが残っている
• Azure DevOps Serverの更新計画があり、将来的に4.x対応が必要になる
• エージェントの自動更新を止める運用をしている
• ビルド失敗時にエージェントバージョンを確認する手順がない

古いOSを延命するより、新しいOS上に新エージェントを構築し、既存パイプラインを段階的に移すほうが安全です。既存エージェントを直接置き換える前に、新しいAgent poolを用意し、対象パイプラインを限定して検証すると失敗を減らせます。

Linuxエージェント展開前に確認すべき前提条件

Azure Pipelines Linuxエージェントの展開では、Git 2.9.0以上が必要です。エージェント自体は必要な.NETを同梱するため、4.xエージェントを使うために事前に.NET 8を別途インストールする必要はありません。ただし、Subversionリポジトリを使う場合はSubversionクライアント、TFVCを使う場合は追加要件を確認する必要があります。(Microsoft Learn)

Linux上で前提条件を確認する例は次のとおりです。

git --version
which git

依存関係の確認には、エージェントディレクトリ内の次のスクリプトを使えます。

./bin/installdependencies.sh

ただし、このスクリプトは一部の依存関係をサードパーティサイトから取得する場合があります。公式ドキュメントでは、packages.efficios.comのような外部サイトにアクセスできるか、aptやzypperなどのパッケージマネージャーに必要なリポジトリが接続されているかを確認するよう案内されています。(Microsoft Learn)

社内プロキシや閉域ネットワークでよくある失敗は、エージェント本体のダウンロードはできても、依存パッケージの取得で失敗するパターンです。展開前に、OSリポジトリ、Microsoft関連ドメイン、サードパーティ依存先、社内プロキシの認証方式をまとめて確認してください。

管理者が最優先で設計すべき権限と実行ユーザー

Self-hosted Linux agentsで最も重要なのは、権限設計です。公式情報では、エージェントを構成するユーザーにはプール管理権限が必要ですが、日常的にエージェントを実行するユーザーにはその権限は不要とされています。また、エージェント配下のフォルダーには復号や流出の対象になり得るシークレットが含まれるため、アクセス可能なユーザーを最小化する必要があります。(Microsoft Learn)

実務では、次のように役割を分けると安全です。

役割	例	権限の考え方
登録担当ユーザー	Azure DevOps管理者、Agent pool管理者	エージェント登録時だけ使う
実行ユーザー	azpagentなどの専用Linuxユーザー	パイプライン実行に必要な最小権限だけ付与
OS管理者	インフラ管理者	ログ調査、サービス管理、パッケージ更新に限定
パイプライン編集者	開発チーム	YAML変更権限が実行コードに直結することを理解させる

Azure Pipelinesエージェントは、外部から取得したコードやパイプライン定義に基づいて処理を実行します。つまり、エージェントマシンはリモートコード実行の対象になり得ます。公式ドキュメントでも、エージェント実行ユーザー、エージェントマシン、YAMLを保存するリポジトリ、Agent poolへのアクセス権を最小権限で設計する重要性が説明されています。(Microsoft Learn)

避けるべき典型例は、次のような構成です。

避けたい構成	なぜ危険か
rootユーザーでエージェントを常時実行する	パイプライン経由の処理が過剰なOS権限を持つ
登録用PATを長期間サーバーに残す	漏えい時の影響が大きい
エージェントディレクトリを多数のユーザーが読める	ログ、成果物、設定ファイルから情報が漏れる可能性がある
YAML編集権限を広く与える	パイプライン定義の変更が実行コードの変更に近い意味を持つ

Linuxエージェントを作るときは、専用ユーザーを作成し、そのユーザーでエージェントを展開・実行する構成を基本にします。

sudo useradd -m -s /bin/bash azpagent
sudo su - azpagent
mkdir ~/myagent
cd ~/myagent

Azure Pipelines Linuxエージェントの基本的な展開手順

公式手順では、Azure DevOpsのAgent poolsからLinux向けエージェントを取得し、任意のディレクトリに展開して./config.shを実行します。Azure PipelinesのサーバーURLは通常、https://dev.azure.com/{your-organization}形式です。 (Microsoft Learn)

基本的な流れは次のとおりです。

手順	作業内容	確認ポイント
1	Azure DevOpsにサインイン	組織またはコレクションを間違えない
2	Organization settingsまたはCollection settingsを開く	Azure DevOps ServicesとServerで導線が異なる
3	Agent poolsを選択	利用するプールを事前に決める
4	AgentsタブからNew agentを選択	Linux、x64/ARMなどを選ぶ
5	エージェントをダウンロード	OSとアーキテクチャを確認
6	Linuxマシン上で展開	専用ディレクトリを使う
7	./config.shを実行	URL、認証、Pool、Agent名を設定
8	./run.shまたはsystemdで起動	本番運用ではサービス化を検討

手動構成のイメージは次のようになります。

mkdir ~/myagent
cd ~/myagent

# ダウンロードしたtar.gzを配置して展開
tar zxvf vsts-agent-linux-x64-*.tar.gz

# エージェントを構成
./config.sh

初回は手動で構成し、動作と入力項目を把握してから自動化するのが安全です。多数のエージェントを展開する場合は、無人構成を使ってスクリプト化できます。(Microsoft Learn)

認証方式はPATだけで決めない

エージェント登録時の認証方式には、Personal access token、Device code flow、Service principalなどがあります。Azure DevOps ServicesではPAT、Service Principal、Device code flowが利用できます。一方、Azure DevOps ServerやTFSでは利用できる方式が異なり、Service PrincipalやDevice code flowは現在サポート対象外とされています。(Microsoft Learn)

認証方式	主な用途	注意点
PAT	手軽に登録したい場合	Agent Poolsのread/manageなど必要最小スコープにする
Service Principal	自動化・非対話登録に向く	Azure DevOps Services向け。Serverでは対象外
Device code flow	対話的にMicrosoft Entra IDで登録したい場合	Azure DevOps Services向け
Alternate / Basic	Azure DevOps ServerやTFSで使う場合	HTTPS構成など前提条件を確認

重要なのは、登録時の認証情報と、パイプライン実行時のアクセス権を混同しないことです。公式情報でも、これらの認証方式はエージェント登録時に使われるものとされています。登録後のエージェント通信やパイプライン内のAzure DevOpsリソースアクセスは、別の設計として考える必要があります。(Microsoft Learn)

PATを使う場合は、次の点を必ず確認してください。

確認項目	推奨される対応
スコープ	Agent Poolsのread/manageなど必要最小限にする
有効期限	長すぎる期限を避け、ローテーション計画を持つ
保存場所	シェル履歴、手順書、共有チャットに残さない
利用者	個人アカウント依存を避け、運用ルールを定める
削除	登録後に不要な認証情報が残っていないか確認する

systemdサービスとして動かすときの注意点

本番運用では、エージェントを対話的に./run.shで起動するより、systemdサービスとして動かす構成が一般的です。公式ドキュメントでは、Ubuntu 16 LTS以降、Red Hat 7.1以降でsystemdサービスとして実行できるとされています。サービス管理には、構成後に生成される./svc.shを利用します。(Microsoft Learn)

基本コマンドは次のとおりです。

cd ~/myagent

sudo ./svc.sh install azpagent
sudo ./svc.sh start
sudo ./svc.sh status
sudo ./svc.sh stop

アンインストールする場合は、停止してから実行します。

sudo ./svc.sh stop
sudo ./svc.sh uninstall

ここで重要なのは、サービスとして実行する場合、エージェントサービスをrootユーザーで実行できない点です。公式ドキュメントでも、サービス実行時にrootユーザーとして動かせないことが明記されています。(Microsoft Learn)

また、SELinux環境ではsvc.shまわりで問題が報告されており、SELinuxは公式にサポートされる構成ではないとされています。RHEL系でSELinuxを有効にしている場合は、検証環境でサービス起動、ログ出力、作業ディレクトリへのアクセス、ビルドツールの実行を必ず確認してください。(Microsoft Learn)

環境変数とCapabilitiesの確認を忘れない

Azure Pipelinesでは、エージェントが持つCapabilitiesに基づいてジョブが割り当てられます。公式情報では、エージェントのCapabilitiesはプールに公開され、ビルドやリリースが実行可能なエージェントへ割り当てられると説明されています。たとえばnpmタスクを使う場合、npmがインストールされたエージェントが必要です。(Microsoft Learn)

よくある失敗は、Linuxマシンにツールをインストールしたのに、Azure Pipelines側でCapabilitiesに反映されないケースです。公式ドキュメントでは、新しいソフトウェアをインストールした後、Capabilitiesとして表示させるにはエージェントの再起動が必要とされています。(Microsoft Learn)

サービスとして構成した場合、PATH、LANG、JAVA_HOME、ANT_HOMEなどの環境変数は構成時のスナップショットとして扱われます。後からソフトウェアを追加した場合は、次のように環境変数を更新してからサービスを再起動します。(Microsoft Learn)

cd ~/myagent
./env.sh
sudo ./svc.sh stop
sudo ./svc.sh start

確認すべき項目は次のとおりです。

項目	確認方法	失敗例
Agent.Version	Agent poolsのCapabilitiesタブ	古いエージェントが残っている
PATH	.pathやサービス環境	CLIをインストールしたがジョブから見えない
JAVA_HOME	.envやジョブログ	Javaビルドがサービス実行時だけ失敗
npm / Maven / Gradle	Capabilitiesやジョブ実行	開発端末では動くがエージェントでは失敗
シークレット系変数	VSO_AGENT_IGNOREの活用	不要な環境変数がCapabilitiesに出る

環境変数をCapabilitiesとして公開したくない場合は、VSO_AGENT_IGNOREに除外したい変数名をカンマ区切りで指定できます。(Microsoft Learn)

ファイアウォールとプロキシで確認すべきURL

企業ネットワーク内でSelf-hosted Linux agentsを使う場合、ネットワーク許可リストは必ず確認してください。公式情報では、Azure ReposやAzure DevOps関連サービスと通信するため、https://*.dev.azure.com、https://dev.azure.com、https://login.microsoftonline.com、https://management.core.windows.net、https://download.agent.dev.azure.comなどのURLが挙げられています。 (Microsoft Learn)

特に重要なのは、エージェントソフトウェアのダウンロード先です。Edgio CDN for Azure DevOpsの廃止に伴い、エージェントダウンロード用にhttps://*.dev.azure.comを許可する必要があり、ワイルドカードを許可できない場合はhttps://download.agent.dev.azure.comを許可するよう案内されています。 (Microsoft Learn)

プロキシ環境では、次のような切り分けが必要です。

確認対象	具体例	注意点
エージェント登録	Azure DevOps組織への接続	認証画面には到達しても登録で失敗することがある
エージェント更新	download.agent.dev.azure.com	エージェントの自動更新や手動更新に影響
Azure Repos	dev.azure.com、*.dev.azure.com	checkoutで失敗する場合がある
Microsoft Entra ID	login.microsoftonline.com	Device code flowなどの認証に影響
Azure Artifacts	*.blob.core.windows.net、*.vsassets.ioなど	パッケージ復元で失敗する場合がある
TFVC	vstsagenttools.blob.core.windows.net	TEE plugin取得で必要になる場合がある

注意したいのは、エージェントがAzure Pipelinesへ接続できても、ビルド中のツールが別のURLへアクセスできないとジョブは失敗する点です。公式ドキュメントでも、プロキシバイパスの設定はエージェント接続を対象にしたものであり、ビルドパイプラインやスクリプト内の各ツールは別途プロキシ対応が必要とされています。(Microsoft Learn)

無人構成で複数エージェントを展開する

複数台のLinuxエージェントを展開する場合は、./config.shを対話的に実行するより、無人構成を使うほうが再現性を高められます。公式ドキュメントでは、--unattendedと必要な回答を指定することで、人の入力なしにエージェントをセットアップできると説明されています。(Microsoft Learn)

代表的なオプションは次のとおりです。

オプション	用途
--unattended	対話入力なしで構成する
--url <url>	Azure DevOps組織またはServerのURLを指定
--auth <type>	patなどの認証方式を指定
--token <token>	PATを使う場合のトークン
--pool <pool>	参加するAgent pool
--agent <agent>	エージェント名
--replace	既存エージェントを置き換える
--work <workDirectory>	作業ディレクトリを指定

例としては、次のような構成です。

./config.sh \
  --unattended \
  --url https://dev.azure.com/example-org \
  --auth pat \
  --token "$AZP_TOKEN" \
  --pool "Linux-SelfHosted" \
  --agent "linux-agent-01" \
  --work "_work"

任意のコマンドラインパラメーターは、名前を大文字にしてVSTS_AGENT_INPUT_を付けた環境変数としても指定できます。たとえば--passwordの代わりにVSTS_AGENT_INPUT_PASSWORDを使う形式です。(Microsoft Learn)

無人構成では、トークンの扱いが最も重要です。CI/CDのセットアップスクリプトにPATを直書きしないでください。安全なシークレット管理、短い有効期限、使用後のローテーションを前提にします。

既存エージェントの置き換えで失敗しやすいポイント

既存のAzure Pipelines Linuxエージェントを置き換える場合、同じ名前で新しいエージェントを構成すると、既存エージェントを置き換えるか確認されます。公式情報では、置き換える場合は古いエージェントを削除しないと、数分後に競合が発生し、どちらか一方が停止するとされています。(Microsoft Learn)

安全な置き換え手順は次のとおりです。

手順	作業
1	既存エージェントのAgent pool、Agent名、Capabilitiesを記録する
2	新しいLinuxホストに4.x対応OSを用意する
3	新しいエージェントを別名で登録し、テスト用パイプラインを流す
4	必要なツール、環境変数、ネットワーク接続を確認する
5	本番パイプラインの要求CapabilitiesやPool指定を切り替える
6	旧エージェントを停止、サービス削除、./config.sh removeで登録解除する

削除時の基本コマンドは次のとおりです。

cd ~/myagent

sudo ./svc.sh stop
sudo ./svc.sh uninstall
./config.sh remove

既存エージェントをいきなり上書きするより、別名で新規構築して並行稼働させるほうが安全です。特に、開発チームが複数のYAMLで同じAgent poolを共有している場合、1台のエージェント停止が複数プロジェクトのビルド停止につながることがあります。

診断ログとトラブルシューティングの見方

エージェントに問題がある場合は、構成後に次のコマンドで診断を実行できます。

./run.sh --diagnostics

公式ドキュメントでは、./run.sh --diagnosticsで診断スイートを実行でき、セルフホステッドエージェントのネットワーク問題ではAgent.Diagnosticをtrueに設定することで追加ログを収集できるとされています。(Microsoft Learn)

よくあるトラブルと確認ポイントは次のとおりです。

症状	主な原因	確認する場所
エージェント登録に失敗する	権限不足、PATスコープ不足、URL誤り	Agent pool権限、認証方式、組織URL
エージェントがOfflineになる	サービス停止、ネットワーク遮断、プロキシ不備	sudo ./svc.sh status、systemdログ
ジョブが割り当たらない	Capabilities不足、Pool指定誤り	Agent poolのCapabilities
CLIが見つからない	サービス環境のPATH未更新	.env、.path、./env.sh
エージェント更新に失敗する	OS非対応、ダウンロードURL遮断	OSバージョン、FW許可リスト
ログが途中で止まる	メモリ圧迫、エージェントプロセス停止	cgroups、OOMログ、メモリ使用量

高メモリ負荷でエージェント自体が停止すると、パイプラインログやステータスをサーバーへ返せなくなります。公式ドキュメントでは、このリスクを下げる方法として、cgroupsと低いoom_score_adjを使い、Linuxがエージェントプロセスより先にジョブプロセスからメモリを回収する構成が紹介されています。(Microsoft Learn)

開発者が確認すべきパイプライン側の修正点

管理者がOSやエージェントを整備しても、開発者側のYAMLが古い前提のままだと失敗します。Linuxエージェント移行時は、開発者も次の項目を確認してください。

確認項目	具体例
Pool指定	pool: name: Linux-SelfHostedが新しいPoolを指しているか
demands	古いCapabilities名や不要な要求が残っていないか
ツールバージョン	Node.js、Java、.NET SDK、Android SDKなどが期待値か
ファイルパス	Windows前提のパス区切りや大文字小文字の違いがないか
権限	実行ユーザーが成果物出力先やデプロイ先にアクセスできるか
キャッシュ	旧エージェント依存のローカルキャッシュに頼っていないか

たとえば、ビルドにnpmを使うなら、Linuxホストにnpmをインストールするだけでは不十分です。エージェントを再起動し、Capabilitiesにnpmや関連PATHが反映されているか確認します。公式情報でも、npmタスクを含むビルドはnpmがインストールされたエージェントがプール内にないと実行できない例が示されています。(Microsoft Learn)

移行・展開前の実務チェックリスト

Azure Pipelines Linuxエージェントの4.x移行や新規展開では、次の順番で確認すると手戻りを減らせます。

フェーズ	チェック項目	完了基準
棚卸し	既存エージェントのOS、Agent.Version、Pool、Capabilitiesを確認	古いOSと3.xエージェントを把握できている
移行判断	Microsoft-hostedで足りるか、Self-hostedが必要か判断	自前運用が必要な理由が明確
OS準備	4.x対応Linuxを用意	ディストリビューションとアーキテクチャが対応範囲
権限設計	登録ユーザーと実行ユーザーを分離	専用ユーザーで実行できる
ネットワーク	必要URLとプロキシを確認	登録、更新、checkout、パッケージ取得が通る
ツール導入	Git、JDK、npm、SDKなどを導入	パイプラインで使うコマンドが実行可能
エージェント登録	./config.shまたは無人構成で登録	Agent pool上でOnline表示
サービス化	systemdで起動	再起動後も自動復旧できる
Capabilities確認	Agent.Versionやツールが表示される	YAMLのdemandsと一致
テスト実行	代表パイプラインを実行	checkout、build、test、deployが成功
旧環境整理	旧エージェントを停止・削除	名前競合や不要なPATが残っていない

まとめ：Azure Pipelines LinuxエージェントはOS・権限・ネットワークまで含めて見直す

Azure Pipelines Linuxエージェントの更新で重要なのは、4.x agent softwareへの移行だけではありません。4.xは.NET 8ベースであるため、Linux OSのサポート範囲、エージェントの自動更新、実行ユーザーの最小権限、Capabilities、ファイアウォール、プロキシ、systemdサービスの環境変数まで含めて確認する必要があります。(Microsoft Learn)

管理者は、まず既存Self-hosted Linux agentsのOSとAgent.Versionを棚卸ししてください。古いUbuntu、RHEL、Oracle Linux、Alpineで動いている場合は、新しいOS上に4.x対応エージェントを新規構築し、段階的に切り替えるのが安全です。開発者は、YAMLのPool指定、demands、利用ツール、パス、実行権限を確認し、新エージェントで代表的なパイプラインをテストしてください。

次に取るべき行動は明確です。Azure DevOpsのAgent poolsで既存LinuxエージェントのAgent.VersionとCapabilitiesを確認し、OSが4.x対応範囲に入っているかをチェックします。そのうえで、対応外OSのエージェントから優先的に移行計画を作成してください。