web-dev-qa-db-ja.com

Magentoデプロイメントのベストプラクティス

高度にカスタマイズされたMagentoサイトの展開プロセスを設定することを検討しており、他の人がこれをどのように行うのか疑問に思っていました。

開発、UAT、および製品環境をセットアップします。すべてのMagentoファイルはソース管理（SVN）にあります。この段階では、DBを変更するための要件が​​わからないため、3つのデータベースを手動で保守します。

具体的には、

  • Magentoのアップグレードをどのように適用しますか？ （各環境で個別に、または開発でロールアウトするか、アップグレードをあきらめるだけですか？）
  • 各環境でファイル/フォルダーがそのままにしておくもの（例：magento/app/etc/local.xml）
  • 開発者を特定のファイル/フォルダーの編集に制限していますか？
  • テーマデザイナーを特定のファイル/フォルダーの編集に制限していますか？
  • データベースの変更をどのように管理しますか？

テーマデザイナーファイル/フォルダー

デザイナーは、次のフォルダーの編集に制限できます-

app/design/frontend/your_interface/your_theme/layout/
app/design/frontend/your_interface/your_theme/template/
app/design/frontend/your_interface/your_theme/locale/
skin/frontend/your_interface/your_theme/

拡張開発者ファイル/フォルダー

拡張機能の開発者は、次のフォルダ/ファイルを編集できます-

/app/code/local
/app/etc/modules/<Namespace>_<Module>.xml

データベース環境管理

ストアのベースURLはデータベースに保存されているため、環境間でデータベースをコピーすることはできません。オプションが含まれます-

deploymentmagento
33
Spongeboy

SVNではなくgitを使用することをお勧めします。分岐とマージが簡単になるということは、これらすべてのポイントがよりスムーズに進むことを意味します。

アップグレードの適用：開発でこれを行います。ブランチを作成し（これはgitが本当に優れているところです）、パッチファイルを適用するか、さらに良いことに、新しいMagentoバージョンを解凍して、古いデータベースをポイントします。拡張機能はまだありません。新しいMagentoインストールで管理者を開きます。マイナーバージョン間のアップグレードはおそらく問題にはなりません。すべての新しいものをインストールした後、おそらくインデックスを再作成する必要があります。これが安定したらコミットを実行し、拡張機能とテーマを徐々にブランチに取り込み、コードを調整し、各ステップが安定したことが証明された後にコミットを実行します。

環境に依存するファイル：。htaccessおよびapp/etc /local.xml。 local.dev.xml、htaccess-dev local.staging.xml、htaccess-staging local.production.xml、htaccess-productionのそれぞれに個別のバージョンを作成します

...次に、環境ごとにそれらへのソフトリンクを作成します。

ln -s htaccess-dev .htaccess
cd app/etc/
ln -s local.dev.xml local.xml

等々。

特定の開発者へのアクセスを制限する：私はこれを行いません。ただし、リリースマネージャーが何が入り、何が入らないかを決定できるようにするデプロイ戦略をgitで開発できます。

データベースの変更の管理：これが最も難しい部分です。本番環境のmysqldumpを使用するだけで、環境ごとに既製の「env-setup.sql」ファイルがいくつかあります。このようなもの（IDは異なる場合があります）：

UPDATE core_config_data SET value='http://magento.dev/' WHERE config_id IN (3,4);

私は通常、支払いゲートウェイをテスト環境に変更したり、送信メールを変更したりするいくつかの指示を追加します。これらのほとんどは、core_config_dataにあります。

モジュールは通常、データベースに独自の変更を加えるため、適切に作成されたモジュールを適用すると、通常はそれ自体が処理されることに注意してください。いずれの場合も、テストされていない変更を製品に適用しないでください。常にローカル環境とステージング環境で「リハーサル」を行ってください。

環境開発が行われた場所からcms_ *テーブルのみをダンプおよびロードすることにより、データベースからCMS（ページおよび静的ブロック）データを取得できます。

幸運を！

14
Greg Robbins

Magentoの開発中は、他のWebアプリと同じベストプラクティスを使用します。また、コアファイルに変更を加えることも宗教的に避けています（magento wikiの多くのドキュメントでは、コアファイルの変更を求められています）。

9
Rick J

多くの試行錯誤の末、私たちは私たちにぴったりのワークフローを思いつきました。

http://www.dhmedia.com.au/blog/perfect-magento-workflow-using-git

データベース管理、ソース管理下のすべてのコード（Gitを使用）、デプロイメント、ステージングおよび開発サイト、複数の開発者、複数の環境などが含まれます。

これが誰かを助けることを願っています！

3
jmlnik

DB操作（ドイツ語）を回避できます： http://blog.tudock.de/startseite/beitrag/2010/09/17/deployment-prozess-eines-magento-shops.html

3
Felix