4

バージョン管理にはgitを使用しています。私には開発、ステージング、本番環境があります。開発が終了したら、クライアントによるレビューのためにステージングに進みます。承認されると、ステージングから本番環境への変更をプッシュします。データベースに変更がない限り、これは問題なく機能します。ローカル開発でMagento接続を介してモジュールをインストールし、データベースを変更するとどうなりますか。

本番サーバーは常に変更されているので、これらの変更を本番サーバーにプッシュするにはどうすればよいですか？

編集：

私は2つのシェルスクリプトを書きました。本番データベースを開発サーバーにプルダウンし、ベースURLを開発URLに置き換え、それに応じて開発データベースを更新するもの。また、本番SQLダンプを残して、Gitリポジトリに追加します。生のダンプをソース管理に保持することが有益かどうかはよくわかりませんが、試してみるつもりです。2番目のスクリプトは、開発データベースをステージングに移動し、基本的に最初のスクリプトと同じ操作を実行します。

さて、本番環境に移行するときは、更新された本番リポジトリを本番サーバーにプルし、magentoにそれを実行させます。また、最近SQLYogの使用を開始しました。データベース比較ウィザードがあり、開発データベースと本番データベースの違いを確認し、変更を選択的にマージできます。ソース管理にも追加した移行スクリプトが常に作成されます。何か問題が発生した場合は、比較を実行して、何かが見落とされていないかどうかを確認できます。

これは皆さんにとってまともなワークフローのように聞こえますか？

4

3 に答える 3

8

これは開発者にとって一般的な状況です。コードとスキーマを変更する方がはるかに簡単で、完全に理解され、UIにあまり柔軟性がない小さなコードベースがある場合は、すべてがうまくいくことが保証されます。もちろん、これはMagentoには当てはまりません。これは、自動テストや継続的インテグレーションスキームに取り組むのが非常に難しい場合があります。とは言うものの、信頼できるいくつかの既知のテスト可能な動作があります。

概要

本番環境にマージされるローカル開発を処理する場合、ファイルシステムが更新されるときに、新しい機能または変更された機能に関連するスキーマとデータの変更も適用されることを確認する必要があります。これは実際にはMagento自体がどのように機能するかです。モジュール構成ファイルは、バージョン番号を提供し、セットアップリソースを構成できます。この情報は、スキーマとデータの変更ワークフローを開始するために使用され、その結果、バージョン情報がデータベースに追加されます。ファイルが存在する場合、データベースが適切な状態にあるとシステムが推測できるのは、ファイル指定のバージョン番号とデータベースに登録されたバージョン番号の間の一貫性です。

これは、新しい/更新されたモジュールファイルが本番環境にマージされ、必要な条件が満たされた場合（たとえば、構成キャッシュが無効であるなど）、データベースのアップグレードを実行する必要があることを意味します。あなたの（適切な）懸念は、このプロセスがリモートサーバーレベルの違い、リモートデータの違いなどに基づいて壊れることがあるということです。厳密に規制された統合テストプロセスがなければ、いくらかのオーバーヘッドがあります。

攻撃の計画：適切な戦略を選択する

この領域での重要なアクティビティは、データベースに対するモジュールの影響の領域を評価することです。これは、インストールする価値のあるモジュールであれば簡単です。次のいずれかを確認してください。

  1. system.xmlファイル_
  2. SQLまたはデータフォルダにインストール/アップグレードスクリプトが存在する
  3. カスタムセットアップリソースクラスの存在（global/resourcesxpathで構成）
  4. 適切な構成XML（モジュール構成ノードのバージョン番号とglobal/resourcesxpathの下のセットアップリソース）

1の場合、構造を確認し、データベースへの影響がcore_config_dataテーブルに限定されることを確認します。通常、管理者がGUIを介して値を保存した場合にのみ適用されます（以下の1.も適用されることに注意してください）。

2と3については、実行するように設定されているスクリプトを確認してください。これらは、次の3つの一般的な領域に分けることができます。1。構成設定-検索setConfigData()とdeleteConfigData()呼び出し2.テーブルの追加と編集（新しいテーブル、列の追加など）3.EAV関連の変更と追加。EAVセットアップリソースを探します。4。非EAVデータの変更：新しいデータのインストールまたは既存のデータの変更

感覚と直感の問題ですが、データベースへの影響のレベルを測定することで、本番データをローカル開発者に複製し、セットアップワークフローをローカルでテストし、正常に機能することを確認してから、本番環境にプッシュして再実行する必要があるかどうかを判断できます。 -チェック（常にバックアップ！）。変更が広範囲にわたる場合は、サイトをオフラインにして、アップグレードの失敗後に元に戻す必要がある場合に注文や顧客データが失われないようにするのが最善の場合があります。

于 2012-09-09T11:14:18.190 に答える
2

通常、データベースに含まれるデータをdev>prodからプッシュする必要はありません。スキーマ定義は、Magentosqlインストールスクリプトに含まれている必要があります。製品にプッシュしたい実際の新しいデータがある場合は、ケースバイケースでそれを行う必要があります。ほとんどの場合、prodで実際のケースを実行する前に、prod>devからプルダウンしてデータと構成をテストします。

于 2012-10-30T14:13:51.747 に答える
-3

ケース-1：

本番サーバーにローカルにあるのと同じデータ（DB）がある場合は、データベースとファイルを本番サーバーにコピーして、次の手順を実行します。

1）フォルダ/varの内容を削除します

2）ファイル/app/etc/local.xmlの値を変更します。そこに接続文字列データ（データベースユーザー、ホスト、名前）があります。

3）データベースをアップロードしたら、いくつかの変更を加える必要があります。

このクエリを実行します。

SELECT * FROM core_config_data WHERE path = 'web/unsecure/base_url' OR path = 'web/secure/base_url';

2行になります。このクエリを実行してこれらの行を更新します

UPDATE core_config_data SET value = 'YOUR_NEW_LIVE_URL' WHERE path LIKE 'web/%/base_url';

それで全部です。

ケース-2：

本番環境でDBデータを変更したくない場合は、megenを介してモジュールをインストールし、本番サーバーに直接接続する必要があります。また、ローカルで変更したファイルを更新することができます。

于 2012-09-08T11:34:11.913 に答える