Adobe Commerce Patching Automation ワークフローの概要
このトピックでは、Adobe Commerce Patching Automationを使用したパッチ操作の仕組みの概要を説明します。
用語
-
操作 - サービスによって実行された主なアクション：
- 適用
- 元に戻す
-
フェーズ - ワークフローの3つのフェーズ：
- 事前チェック
- パッチ
- 検証
-
環境 - パッチが適用されるAdobe Commerce Cloud環境。
業務運営
Patching Automationでは、Adobe Commerce Cloud環境でパッチを管理するために、次の2つのメイン 操作をサポートしています。
-
操作を適用 – 安全で検証済みのプロセスを通じて、コードベースにパッチ変更を追加します。 パッチは、
m2-hotfixesフォルダーにパッチファイルを配置することで適用されます。 -
操作を元に戻す -
m2-hotfixesフォルダーからパッチ ファイルを削除して、以前に適用したパッチをコードベースから削除します。
フェーズ
Patching Automation ワークフローでは、パッチが安全かつ確実に適用されるように、常にこの順序で実行される3つの フェーズ を使用します。
- 予備チェック - パッチの互換性と環境の準備状況を検証します。
- パッチ適用 – 統合環境でパッチを適用または元に戻します。
- 検証 - パッチアプリケーションを検証し、ヘルスチェックを実行します。
フェーズの詳細
フェーズ 1：事前チェック
事前チェック フェーズでは、パッチを環境に安全に適用できることを検証します。
何が起こるか：
-
実稼動環境のセーフガード （実稼動環境のみ）:
- ストアがメンテナンスモードになっているかどうかを確認します
- cron ジョブが無効になっていることを確認します
- 条件が満たされない場合、パッチ適用をブロック
- 条件が満たされた場合、確認ダイアログを表示します
-
パッチ検証 - パッチファイルが有効で互換性があることを確認します
-
環境評価 – 環境の準備状況とリソースを確認します
-
競合の検出 – 既存のコードとの潜在的な競合を特定します
-
依存関係チェック - Adobe Commerce バージョンの互換性を検証します
フェーズ 2：パッチ適用
パッチ適用フェーズでは、一時的な統合環境でパッチを適用または元に戻します。 この段階で、サービスは一時的な統合環境を作成して、パッチを安全に適用し、正常にデプロイされることを確認し、実際の環境に変更を加える前にヘルスチェックに合格することを確認します。
このアプローチでは、次のことが可能になります。
- 安全性 – 統合環境が正常にデプロイされ、ヘルスチェックに合格するまで、ターゲット環境は変更されません
- ロールバック機能 – 問題が検出された場合
- 分離 – 各パッチ操作について
ステージ 2a：統合環境の作成
分岐の作成 - Patching Automationは、{target-environment}-CAPS-{patch-id}という名前の一時的な統合環境ブランチを作成します
環境セットアップ – 統合環境はターゲット環境の子として作成されます
コード同期 – 統合環境は、ターゲット環境（同じコードベース）の正確なコード状態を継承します
データの複製なし – 統合環境は、ターゲット環境のデータ（データベース、メディア、またはその他の保存されたコンテンツ）のコピーを受け取りません。コードベースのみがパッチの適用と検証に使用されます
リソース要件 - Cloud プロジェクトの合計ストレージ容量が契約で定義されています。 （アカウントページまたはmagento-cloud subscription:infoで確認してください）。 各環境のディスク割り当ては、.magento.app.yaml/.magento/services.yamlのdisk プロパティを介して個別に設定されます。 詳しくは、 ディスク領域の管理を参照してください。 ストレージの制限によりパッチ操作が失敗した場合は、統合環境のディスク使用率（magento-cloud db:size / magento-cloud mount:size）を、設定された割り当てに照らし合わせて確認します。
ステージ 2b：統合環境でのパッチアプリケーション
安全なテスト - パッチは、ターゲット環境に直接ではなく、統合環境に適用されます
ファイル管理 - パッチファイルはm2-hotfixes フォルダーに配置されます
Git操作 – 変更がコミットされ、統合環境ブランチにプッシュされます
環境のアクティブ化 - パッチを適用したコードをデプロイするために統合環境がアクティブ化されます
ヘルスチェック - アクティブ化が完了すると、Patching Automationは結合に進む前に次のことを確認します。統合環境が正常にデプロイされ、正常であること、アプリケーションが開始され、そのデータベースとキャッシュ接続に到達できることが確認されます。
ステージ 2c：ターゲット環境にマージ・バック
同期チェック – 結合する前に、統合環境がアクティブであり、ターゲット環境と同期しており、正常であることをサービスが確認します。 パッチ適用中にターゲットが変更された場合、操作はマージではなく、ここで停止します
環境チェックアウト - サービスはターゲット環境をローカルでチェックアウトします
結合操作 – 統合環境ブランチがターゲット環境に結合されます
競合の処理 – 結合の競合が発生した場合、操作は失敗し、エラーとして報告されます。自動的には解決されません
デプロイメント – 結合された変更がターゲット環境にデプロイされます
検証 - サービスは、結合が成功し、環境が同期していることを確認します
統合環境ライフサイクル
統合環境には、パッチ適用段階で特定のライフサイクルがあります。
- 作成 - パッチ適用段階の開始時に作成
- アクティブ期間 - パッチの適用中およびテスト中もアクティブのままです
- クリーンアップ – 結合前のパッチ適用段階で操作が失敗した場合、すぐに削除されます。 それ以外の場合は、検証フェーズで削除され、統合後、検証が合格するかどうかに関係なく削除されます
フェーズ 3：検証
検証フェーズでは、パッチが適用されたアプリケーションが正常に開始され、ヘルスチェックに合格することを確認します。
何が起こるか：
- アプリケーションの正常性チェック - アプリケーションが正常に開始および実行され、そのデータベースとキャッシュ接続に到達できることを確認します
- クリーンアップ – 一時的な統合環境を削除し、ジョブの状態を更新して完了を反映します。 環境のアクティビティは、プロジェクトのアクティビティフィードに表示されたままになります。
成功指標
操作の適用：
- 「ジョブが正常に完了しました」 – 問題なくパッチが適用されました
- 「パッチが適用されました」 – パッチは既に存在します（操作は必要ありません）
- パッチファイルが
m2-hotfixesフォルダーに正常に配置されました - すべての検証チェックが合格する
- アプリケーションのヘルスチェックに成功しました
操作を元に戻す：
- 「ジョブが正常に完了しました」 – パッチが問題なく元に戻されました
- 「パッチが元に戻されました」 – パッチは既に元に戻されました（操作は必要ありません）
- パッチファイルが
m2-hotfixesフォルダーから正常に削除されました - すべての検証チェックが合格する
- アプリケーションのヘルスチェックに成功しました
本番環境のセーフガード
実稼動環境でパッチを適用または元に戻すと、他の環境よりもリスクが大きいため、Patching Automationには実稼動環境に固有の2つのセーフガードが含まれています。
開始する前の確認
本番環境で適用または復元操作を開始する前に、ダイアログで操作を確認するように求められます。 この確認ステップは、本番環境で誤ってジョブを開始するのを防ぎます。
推奨される前提条件
Adobeでは、実稼動環境にパッチを適用する前に、メンテナンスモードを有効にし、cron ジョブを無効にすることをお勧めします。 デフォルトでは、Patching Automationは両方の条件が満たされていることを確認し、いずれかの条件が満たされない場合は通知で操作をブロックします。 メンテナンスモードを使用しない場合やcron ジョブを有効にした場合のリスクを理解している場合は、UIの「上書き」チェックボックスを選択して、このチェックをスキップします。
- メンテナンスモード – 有効にすることをお勧めします
- Cron ジョブ – 無効にすることをお勧めします