Adobe Commerce Patching Automationツールが公開されました

Adobe Commerce on Cloud のパッチ適用が、管理画面からワンクリックでできるようになりました。Adobe が公開した「Patching Automation」（URL 上の名称は CAPS tool）です。

これまでクラウド案件のパッチ適用は、Quality Patches Tool で対象パッチを確認し、m2-hotfixes にファイルを置き、ブランチを切って Integration 環境で確認し、Staging・Production へマージする──という手作業の連続でした。手順そのものは難しくありませんが、案件数が増えるほど工数と「うっかり」のリスクが積み上がる作りでした。

本記事では、Experience League の公式ドキュメントをもとに、このツールで何ができて、どこに注意すべきかを保守運用の現場目線で整理します。

Patching Automation（CAPS）とは

Adobe Commerce on Cloud のパッチの適用と切り戻し（Revert）を自動化する、Adobe 公式の運用ツールです。
管理画面の Site-Wide Analysis Tool（SWAT）にタブとして組み込まれており、別途インストールするものではありません。

項目

内容

正式名称

Adobe Commerce Patching Automation（公式ページ上で「CAPS」の正式な展開は未記載）

対象

Adobe Commerce on Cloud（PaaS）。バッジにはオンプレも含む記載があるが、本文・手順は Cloud 前提

利用場所

管理画面 > Reports > System Insights > Site-Wide Analysis Tool > Patching Automation タブ

想定利用者

管理者、開発者、パートナー

操作

Apply（適用）と Revert（切り戻し）

パッチの置き場

m2-hotfixes フォルダ（Revert 時は自動削除）

 

ポイントは「パッチを当てる」こと自体より、その前後の検証とブランチ操作までを一連のジョブとして自動実行する点です。

仕組み：3つのフェーズ

CAPSのジョブは必ず「事前チェック → パッチ適用 → 検証」の順で進みます。
最大の特徴は、本番などの対象環境に触る前に、一時的な 検証環境を自動で作成してパッチ適用の結果を検証する、ということです。

 

  1. 事前チェック：パッチファイルの妥当性、環境の状態・リソース、既存コードとの衝突、Commerce バージョンとの互換性を確認。本番ではメンテナンスモード ON・cron 停止が条件です。
  2. パッチ適用
    1. {対象環境}-CAPS-{パッチID} ブランチを対象環境の子として作成。コードは引き継ぎますが、DB やメディアは複製されません。
    2. m2-hotfixes にパッチを配置して push、デプロイ。アプリ起動と DB・キャッシュ接続をヘルスチェック。
    3. 対象環境が作業中に変化していないか確認してからマージし、対象環境をデプロイ。
  3. 検証：マージ後に再度ヘルスチェックし、一時環境を削除。履歴はプロジェクトの Activity に残ります。

Revert も同じ 3 フェーズで、m2-hotfixes からパッチを取り除きます。ただし対象はこのツールで当てたパッチだけです。

失敗したときの挙動

パッチの適用が失敗した場合、処理のタイミングによってその後の挙動が変わります。

タイミング

挙動

対象環境への影響

マージ前に失敗

一時環境を即削除

なし

作業中に対象環境が変化

マージせず停止

なし

マージコンフリクト

自動解決せず失敗として報告

なし

マージ後のヘルスチェック失敗

ロールバックされない

壊れたまま残る可能性あり。手動対応が必要

 

最後の行がこのツールの最大の注意点です。「自動」でも、マージ後の障害は人が拾う前提です。

使い方

権限は Cloud Console のロールがそのまま使われます。
プロジェクトが表示されない場合は、アカウントオーナーか Project admin にロールを付与してもらいます。

ロール

できること

Project admin

全環境で Apply / Revert

Contributor

割り当てられた環境で Apply / Revert

Viewer

閲覧のみ

適用の流れ

  1. 管理画面で Reports > System Insights > Site-Wide Analysis Tool を開く
  2. Patching Automation タブを選ぶ
  3. プロジェクトと環境を選ぶ
  4. 適用可能なパッチと互換性ステータスを確認する
  5. パッチを選んで Apply（または Revert）
  6. 本番の場合は確認ダイアログを承認する

本番では、メンテナンスモードが OFF か cron が動いているとジョブがブロックされます。
ツールはこの 2 つを自動で切り替えないので、事前に手動で設定します。チェックを飛ばす上書きチェックボックスもありますが、通常運用では使わない前提でよいでしょう。

GitHubと連携しているプロジェクトの場合

GitHub リポジトリと連携している場合は、先に「Patching Automation GitHub App」のインストールが必要です。

  • GitHub 組織またはリポジトリの Owner / Admin 権限が必要
  • 「Only select repositories」で対象リポジトリだけを許可する
  • GitHub インテグレーションの fetch-branches が有効でないと、一時環境が作られずタイムアウトする
  • github.com 以外のカスタムドメインのリポジトリは非対応

現場で使う前に押さえておきたいこと

便利なツールですが、「押せば終わり」ではありません。保守案件で使う前に、次の 5 点は運用ルールに落としておきたいところです。

  1. 本番にいきなり当てない。一時環境には DB やメディアが複製されないため、ヘルスチェックで分かるのは「起動して DB・キャッシュにつながる」までです。チェックアウトや決済、カスタム連携の動作は、Staging で従来どおり人が確認します。
  2. 空き環境とディスク容量を確認する。ジョブごとに Integration 環境を 1 つ使います。使っていない環境が埋まっていると「Unable to activate integration environment」で止まります。
  3. 実行中は対象環境に push しない。作業中に対象ブランチが変わると「Environment is not in sync with parent」で停止します。チームや別ベンダーとのデプロイ調整が必要です。
  4. 手動で当てたパッチと混在させない。Revert できるのはこのツールで当てたものだけです。どのパッチをどの経路で当てたかを記録しておくと、障害時に迷いません。
  5. マージ後の障害に備える。検証フェーズで失敗しても自動では戻りません。メンテナンス窓を取り、切り戻し手順と担当者を決めてから実行します。

想定外のエラーは、文言をそのまま Adobe Support に伝えるよう公式にも書かれています。
Project ID と Environment ID をすぐ出せるようにしておくと、問い合わせが早くなります。

まとめ

Patching Automation は、パッチ適用の「ブランチを切る・試す・マージする」を安全側に倒した形で自動化してくれるツールです。
一方で、業務レベルの動作確認とマージ後の障害対応は、引き続き人の仕事です。

まずは Staging で使い、自社のパッチ運用フローにどう組み込むかを試してみるのがおすすめです。