Magentoストアのセットアップは、自己インストール可能な拡張機能の開発だけでなく、最終編集属性、カテゴリ、製品、価格ルールCMSページなどの作成など、多くの「手動入力」操作も必要です。システム構成の変更。
Magentoストアを開発環境からステージング環境および実稼働環境に展開する際の最善の戦略を概説してください。
私の戦略の1つは、上記のエンティティをプログラムで作成する「デプロイモジュール」を作成することですが、それは非常に時間のかかるタスクであり、時には少しやり過ぎのように思えます。
最近、管理タスクを再現するためにSelenium IDEを使用し始めましたが、すべてのテストスイートのセットアップに必要な時間は、上記のものからそれほど遠くありません。
たぶん最適なソリューションは、Magentoシステムのスナップショットを作成できるモジュールを使用して、展開するものを選択できるようにすることです。
そう：
- 展開の戦略は何ですか？
- Magentoシステムのスナップショットを作成して、展開するものを選択できるモジュールはありますか？
- そのようなモジュールが存在せず、そのようなモジュールが合理的なソリューションである場合、開発に貢献することに興味がある人はいますか？
ありがとうございました！
これは、別のタグまたはタグカテゴリの必要性を示している場合があります。あなたは一度きりの店ですか、またはサービスプロバイダーとして一般的な提案を探していますか？後者の場合、「クライアントがエンティティデータに対してどの程度の制御を望んでいるかに依存する」と答える必要があります。
—
ベンチマーク
私の視点は、開発チームに属する開発者の一人です。カテゴリ構造など、機能するためにいくつかのデータを必要とするセクションを開発しているとします。Adminで構造を作成し、コードを実行してコードをプッシュします。最善の戦略は、必要なカテゴリ構造を作成するコードを記述してプッシュすることでもあるのかと思っています。自分のカテゴリ構造や設定が、独自のプッシュを行った他の開発者のカテゴリ構造や設定と競合する場合はどうなりますか？競合を処理するにはどうすればよいですか？それが私のポイントです。
—
アレッサンドロロンキ
@AlessandroRonchiこれは論争点であり、決して起こらないはずの衝突です。カテゴリ構造は軽微に変更されるものではないため、ある開発者は、他の開発者に気付かれずに、構造に大きな変更を加えるべきではありません。これが発生した場合、開発者間のコミュニケーションに対処する必要があります。通常、サイトのカテゴリ構造は初日から固定する必要があり、再度変更する必要はなく、追加するだけです。変更する必要がある場合は、最初に正しくスコープしませんでした。
—
ProxiBlue
残念ながら、@ dedmeetは、私が知っている世界では、日々状況が変化しています。顧客は心を変え、開発者は心を変え、黒い白鳥が発生します。変更に備えなければなりません。とにかく、初日からカテゴリ構造を変更する必要がない場合でも、それは全体のほんの一部であり、全体は物事を成し遂げるために変更される「進行中の」プロジェクトです。
—
アレッサンドロロンキ
確かに、私たちは絶えず変化する環境で仕事をしていますが、カテゴリ構造の競合は起こらないはずです。それぞれが構造を変更する場所に複数のブランチが存在するべきではありません。それは単に問題につながり、開発時間の無駄になります。dev bが構造変更に時間を費やすのに、dev bは同じことを別の構造に行っているのに、なぜ彼らは仕事を進めているのですか？構造を変更する必要がある場合、プロジェクトに関与するすべての開発者は、新しい構造をスコーピングするプロセスに関与する必要があります。これがいつ起こるかを理解するのに役立つ例を提供できますか？
—
ProxiBlue