php - Magento の更新を行うためのベスト プラクティスは?

Question

(メンテナンスが不十分な Magento インストールの) Magento の更新を行うためのベスト プラクティスは何ですか。

以下のようなことを考えています。

• app/code/local の完全な上書きモジュールを見てください - ファイルを古いバージョンと比較し、それらを新しい Magento バージョンに転送ポートします。
• テンプレートを比較する
• レイアウト XML ファイルを比較します (それらがカスタム テーマ フォルダーに直接コピーされ、実際の更新のみを含む単一の layout.xml が使用されていない場合)。
• 書き直されたクラスのメソッドを元のクラスのメソッドと比較する

主な問題は次のとおりです。古くてメンテナンスの行き届いていない Magento インストールでファイルを比較すると、コピーされた元のファイルがどのバージョンであったかわかりません。ファイルのコメントでMagentoの著作権を調べて、古いバージョンを特定しようとしたことがあります。

更新中の面倒を避けるために、通常は次のことを行います。

• 書き換えを避け、代わりにイベントを使用する
• 書き換えが必要な場合は、コードをコピーするのではなく、parent::method() を呼び出して、上書きされたクラスに必要な機能のみを保持するようにしてください。
• コードのコピーが必要な場合は、次のようなマーカー コメントを使用します。[Mycompany BEGIN] ... [Mycompany END]
• レイアウト ファイル全体をコピーするのではなく、更新のみを行う単一の layout.xml を使用してください。

しかし、これらの予防措置が講じられていない場合、どのように更新を行うのでしょうか?

Answer 1

他の人が指摘しているように、ここでの鍵はクリーンインストールと比較できるようにすることなので、バージョン管理の助けを借りて私が行うことは次のとおりです。

1. 現在使用している Magento のクリーン バージョンを入手し、比較できるようにすることを忘れないでください。または、magento の既存の git ミラーを使用します (詳細はhttp://blog.speedupmate.com/post/4063307705/magento-git-mirrorを参照) 。

2. 1.こちらを元にマスターレポを立ち上げて手元に

   コメントでの質問: 最終的な目標は、magento インストール ファイルに存在する git 内のすべてのファイルを含むクリーンなコアを作成することです。これは、すべてをクリーン インストールと比較できるようにするために必要です。コアの変更、コア ファイルツリー (既存、非存在、追加ファイル) の管理。.gitignore で例外を処理できます (メディア、キャッシュ、サーバー固有のスコープ local.xml .htaccess を持つすべてのフィールドを除く)。Magentoコアファイルを別の（非公開）ディレクトリに移動するのは簡単だと思います（ここで説明されているようにhttp://blog.speedupmate.com/post/9992573819/poor-mans-multisite-setup-for-magento) そして、アップグレード時に .htaccess が競合しないコード状態が得られます。また、バージョン管理、キャッシュ、および magento が生成するすべての一時ファイルにメディアを含めません。これにより、アップグレード時にすべてを無効にできるため、アップグレードのパスをクリアすることが保証されます。後でコードを比較すると、概要を把握するために必要な範囲がわかり、変更された部分を比較してアップグレードを開始するまでにかかる時間を見積もることができます。

3. 既存のサイトと git 構成を配置して (比較可能にするために) git init、コードベースで a を実行し、そこにすべてを git に追加します。これにより、git 構成が調べられ、すべてのファイルが比較可能になり (同じ改行、空白など)、ファイルが修正されます。権限が同じであること。その後、.git フォルダーをサイトから削除することができます。これは、git のみを使用してファイルを比較可能にするためです。

   コメントでの質問: ここでのポイントは、すべての行末を UNIX スタイルに変換し、空白を無視するなど、git を機能させることです。理論的にはパーミッションも無視できますが、それは役に立ちません (書式設定がここでは少しずれているため、\ は改行を表します)。コマンド間

   git config core.autocrlf input \ git config core.eol lf \ git config apply.whitespace nowarn

   これらの構成を実行しgit init て追加し、すべてを git に追加すると、コミット段階で git がすべてのウィンドウの行末とすべてのがらくたを統一された同等のスタイルに置き換えます。Zend コーディング標準では UNIX スタイルの行末が推奨されていますが、Zend ライブラリが独自の標準に従っていないファイルも表示されます。ここでの重要な点は、実行する必要がある差分の負荷を最小限に抑えるために、ファイルを比較できるようにする必要があるということです。git がすべての不良インストール ファイルをフォーマットした後、.git フォルダーを削除します。Git は、このステップの「比較可能なプロセスの作成」を自動化するためにのみ使用され、他には何も使用されません。

4. 1.のマスターリポジトリに基づいてテストリポジトリをチェックアウトし、現在使用しているバージョンのブランチをチェックアウトし、「testsomething」または必要な名前を付けます

5. そのチェックアウト フォルダーからすべてを削除し、.git だけを残して空にしますが、バージョン管理はまだそこに存在します。すべてが削除されたような状態になります。これは、悪いサイトで削除された可能性のあるファイルを知っていることに基づいて、ここで重要です。

   コメントでの質問: 私は通常、git config (ローカルまたはグローバル スコープが利用可能) に空白を無視して追加し、git にそれを処理させます。チームで作業するときは、Zend の標準に基づいていることに常に同意しています。タブ用の 4 つのスペース、UNIX スタイルの行末、および 3. で言及されている git 構成変数。ビルド スクリプトが関係する場合は、コミット フックを使用してコードの書式設定と検証を行います。

6. すべてのファイルを空のディレクトリに移動し（比較可能にした後、既存のサイトから.gitディレクトリを削除したことに注意してください）、失敗したmagentoインストール（現在は比較可能です）からgit status > changes.txt. このファイルには、現在使用しているクリーンな Magento コードに対して、「失敗したインストール」にあるすべての違い、新しいファイル、削除、名前変更などのファイルが一覧表示されます。

   コメントに基づいて説明する：私は通常そうしますgit status --porcelain

7. バージョン管理に不要な local.xml var/* またはすべてのファイル/ディレクトリ、および .DS_Store、.Thumbs.db、および git から作成された IDE プロジェクト ファイルを破棄するのに役立つ .gitignore ファイルを配置します。すべてのメディアとキャッシュされたファイル、およびバージョン管理の各サーバーで異なるファイルは必要ありません。

そこから、そのリストを注意深く概観し、そのリストに基づいて次のことを行う必要があります。

• すべてのコアの変更を app/code/local/ に移動し、変更されたファイルを元の状態にチェックアウトします (コピーしたファイルを保持し、コアの変更を破棄しますgit checkout filename)
• 変更されたすべてのコア テンプレートとレイアウト ファイルを自分のテーマ フォルダーに移動し、変更されたファイルを元の状態にチェックアウトします。
• .htaccess の変更を元に戻すか移行するか、保持するか破棄する必要があるかを決定します

今、あなたはまだ体調が悪いですが、あなたは今：

• クリーンコアベース
• 別のブランチのバージョン管理されたマスター ツリーに基づく

これで、Magento のマージ可能なバージョンを含むマスター ブランチに基づいて、バージョン管理され、比較可能になり、別のブランチになるという利点が得られます。それでは、アップグレードを試してみましょう。これが 100% 成功するための重要なポイントです。

1. 最初のステップは、app/code/local/Mage/ に分離し、テーマを分離したすべての「がらくた」を無効にすることです。コアが明確で、テーマを無効にできる場合、アップグレード プロセスを妨げるカスタム コードはありません。それでは、無効にしてください：

   • すべてのローカル拡張機能とカスタム コミュニティ拡張機能を app/etc/modules/ から一時フォルダーに移動して、app/etc/inactive/ にします。
   • カスタム テーマを無効にして、base/default/ をオンにします。
   • これは、同等の状態にあるという利点です。あなたは何が違うのかを知っていて、それを無効にしてそれに基づいて物事を診断することができます

2. リポジトリのマスター ツリーにすべてのメジャー バージョンがタグ付けまたは個別に分岐されている場合、バージョンを高くするのはコマンドだけです: git merge "magento-vhateverthenextversionis"

   • この「git status > changes.txt」を実行した後、バージョン間で変更されたすべてのファイルのリストが表示されます
   • ブラウザでサイトを実行するとアップグレードが実行されます。デフォルトのテーマを使用していて、カスタマイズが有効になっていないため、魅力的に機能します
   • バージョンごとにアップグレード バージョンを繰り返し、テスト ブランチでタグ付けしてコードの状態を保存するか、既存のテスト ブランチに基づいてバージョンごとに新しいブランチを作成します。このようにして、その間にアップグレードしたすべての magento バージョンのクリーンな状態を保存しました。
   • 繰り返しになりますが、ここでの追加のボーナスは、バージョン管理を使用すると、新しいバージョンが破棄するファイルも削除され、簡単に削除できることです。

3. 2. を目的の magento バージョンから最新のバージョンに反復した場合は、継承した「s*it」を食べて、次のことを実行します。

   • 持っているすべての拡張機能を分析し、アップグレードできるかどうかを確認します。アップグレードして有効にできる場合は、デフォルトのテーマで動作するかどうかを確認してください
   • app/code/local/Mage の各コアの書き換えを、app/code/core/Mage の新しい形式の元のバージョンと比較します。winmerge.org のような差分ツールや変更 (任意の OS とツール) を 1 つずつ使用するか、フォルダー全体を差分することができます。
   • 同じことがテンプレートと上書きされたテンプレートまたはレイアウトにも当てはまります。元のテンプレートと比較し、変更を新しい基本テンプレートにマージして、古い DOM を削除します
   • テーマの変更と拡張機能を 1 つずつ有効にしてデバッグする

4. ここまで来たら、めちゃくちゃな作業をしたことになります。しかし、バージョン管理されたクリーンなマジェントコア、マージされてオーバービューされた個別の上書き、および無効にできる個別のテーマのすべてのものがあります。

5. 面白いのは、magento の次のアップグレードが利用可能になった場合、口笛を吹いてマスター ツリーに匹敵するものとして追加し、変更をマージして、何が変更されたかを把握し、何を概観してテストするかについて明確な範囲を持つことができることです。

Answer 2

まず、あなたの質問の内容は、ベスト プラクティス (少なくとも私がそうであると考えているもの) を明確に理解していることを示していることに注意してください。

origin の複数のバージョンの可能性について: ソフトウェア アップグレードの目標は、新しいクラスとメソッドを適切に配置することです。つまり、（あなたが述べたように）実装方法に関係なく、カスタマイズを移植することを意味します。

残念ながら、あなたの状況に最適な方法は、慎重に差分をとること以外に、回帰テスト(生成された出力を複数のビューでチェックすること) です。

つまり、クリーン インストールから始めて、まだ必要と思われるカスタム機能とテーマを積極的に取り入れます。これは最も効率的なアプローチとは思えないかもしれませんが、明らかなオーバーヘッドを上回ると私が信じている利点を次に示します。

1. すべてのカスタム動作を驚くことなく制御できます
2. シングルオリジンの健全なコードベースが保証されます
3. クライアントにとってある時点で、あなたはコードの所有者になり、カスタマイズを再統合するためのホワイトリスト/肯定的なアプローチは、あなたの所有権が期待どおりであることを確認するための最良の方法のようです.

Answer 3

最初に行うことは、サイトを開発環境にコピーすることです。必要なときにいつでも復元できるように、そのバックアップを作成します。また、この時点でライブ サイトをコード ロックダウンにします。どうしても必要な場合を除き、コードを変更する必要はありません (変更がある場合は、新しい開発環境に複製する必要があります)。

Web サイトの安全なコピーを使用してプレイできるようになったので、楽しみが始まります。

私が最初に行うことは、実行している Magento のストック バージョンのコピーをプルダウンすることです。/app/code/core で、ストック バージョンと現在持っているものとの差分を作成します。これはあなたの違いが何であるかを教えてくれます。コアを元に戻しながら、現在持っているすべての機能を維持しようとします。

この時点で、Magento がきれいにインストールされていることを願っています。これをライブサーバーに戻すことを検討することもできますが、これまでに多くのことをしなければならなかったので、実行可能なオプションではない可能性があると感じています.

ここで、必要に応じてこの時点に戻ることができるように、開発サイトの個別のバックアップを作成します。

ここで、開発サイトでアップグレードを試みます。すべてがうまくいき、アップグレードに問題がないことを願っています。そうでない場合は、必要な修正を行い、そこから続行します。

この時点で、アップグレードしても安定したコード ベースが必要です。再びライブでバックアップし (念のため)、新しいコードをプッシュして、すべてがうまくいくことを願っています。