33

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

開発、UAT、および本番環境をセットアップします。すべての Magento ファイルはソース管理 (SVN) にあります。この段階では、DB を変更するための要件が​​見当たらないため、3 つのデータベースは手動で維持されます。

具体的には、

  • Magento のアップグレードはどのように適用しますか? (各環境で個別に、または dev でロールアウトするか、それとも単にアップグレードをあきらめますか?)
  • 各環境に残すファイル/フォルダー (例: 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 はデータベースに格納されるため、環境間でデータベースを単純にコピーすることはできません。オプションには以下が含まれます-

4

5 に答える 5

14

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

アップグレードの適用: dev でこれを行います。ブランチを作成し (ここが 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_* テーブルだけをダンプしてロードすることで、データベースから取得できます。

幸運を！

于 2011-06-09T20:49:47.820 に答える
9

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

于 2009-09-04T11:27:11.210 に答える
7

私はgitを使用して、すべてのMagentoプロジェクトとデプロイメントを管理しています。特にgithubで管理しているMagentoミラーを使用する場合は、新しいバージョンをマージする方がはるかに簡単です。（GitHub Magentoミラー）

ベースURLがDBのどこに保存されているかについての具体的な質問については、次のことを試してください。

SELECT * FROM core_config_data WHERE path = "web/secure/base_url" OR path = "web/unsecure/base_url";
于 2009-09-09T07:11:28.307 に答える
3

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

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

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

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

于 2011-07-07T08:36:06.517 に答える
3

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

于 2010-09-20T08:52:47.170 に答える