Magento開発のセットアップ


23

この質問は、開発環境のセットアップに向けられています。特定の要件がいくつかあります。

  1. 私たちのチームの人々はこれらすべてのOSを使用しているため、Linux、Windows、およびMac OSで私のソリューションを使用できるようにしたいです(たとえば、フロントエンド開発者はWindows / Macを使用し、バックエンド開発者は主にLinuxを使用します)
  2. modmanを使用する必要があります
  3. コンポーザーを使用する必要があります
  4. GithubとプライベートGitリポジトリを使用する必要があります
  5. NetbeansやPHP Stormのような適切なIDEが必要です
  6. とても良いパフォーマンスが欲しい

私の現在のセットアップは、Virtualbox内の仮想化されたUbuntuイメージです。3つのOSすべてがVirtualboxを実行できるため、ポイント1)-5)はすべて満たされます。

しかし、現在、私は6)に完全に満足していません。これは、Ubuntu 12.04内からソリューションを実行する場合に特に当てはまります。VirtualboxはWindows 7の方がはるかに安定しており、応答性が高いようです。しかし、チームの多くの人々がLinuxを使用しているため、ソリューションを改善したいと思います。

VMWareまたはdocker.ioに匹敵するセットアップがあり、より安定して実行されるかどうかを報告できる人はいますか?または、他の同等のソリューション/アイデアはありますか?


いい質問です!同様の設定にも取り組んでいますが、まだ通常のワークフローには入れていません。答えを楽しみにしています。
アンナフォルクル

簡単なアイデア:LinuxでVMなしで動作し、VMで実行されるすべてを直接インストールすることは不可能でしょうか?または、1つのプロジェクトに1つのVMを使用しますか?
アンナフォルクル

VMをヘッドレスで実行していますか、それともGUIを使用していますか?また、VM Imageファイルシステムをホストシステムとどのように同期していますか?共有フォルダー?サンバ?(IDEはVMではなくホストで実行されていると仮定しています)。それは大きな違いを生むことができます。
ヴィナイ

@AnnaVölklはい、可能ですが、いくつかの利点が失われます。たとえば、ベースイメージを更新するたびに、すべてのLinuxユーザーは手動で変更を更新する必要があります。また、1台のコンピューターから別のコンピューターに持ち帰りたい場合(たとえば、自宅や他の場所で仕事をする場合)、事態はずっと難しくなります。
mpaepper

1
アンナが言ったように、私たちもこのような仕事をしています。Vagrantを使用してVMイメージを構築していますが、これは非常にうまく機能しています。あなたが言うように、パフォーマンス(共有フォルダーのファイルI / Oの速度に関して)は、切り替える前に取り組む必要がある主なものです。Linuxホストシステムの場合、NFS共有が役立つ場合があります。私たちの大きな問題は、ほとんどの開発者がWindowsホストシステムを使用しており、リンクとは反対にWindowsのパフォーマンスがまったく良くないことです。私は今、さまざまな人々からこれを聞いていますが、それは私たちだけではありません。
マティアスツァイス

回答:


8

phagingではvagrant、git、およびいくつかのビルドスクリプトを使用します。VagrantマシンはデータベースとWebサーバーを実行し、gitはローカルで拡張機能の変更を追跡/var/wwwし、Vagrantマシンのディレクトリの更新に使用するビルドスクリプトを使用します(実際には、環境を構築する必要があるすべての場所で使用されます)。

Phing

おそらく最も興味深い部分はphingで、これはmodman + composerのように機能します。ビルド、セットアップ、インストールなど、いくつかのターゲットが定義されています。

ビルド内部Webサーバからターゲットのダウンロード(ビルド設定で指定)のMagentoの特定のバージョンとは、ビルドディレクトリにそれを抽出します。次に、ファイルのアクセス許可を設定し、キャッシュをクリーンアップする他のターゲットを実行します。次に、ソースディレクトリ内のすべてのファイルへのシンボリックリンクを作成します。その結果、ビルドディレクトリで使用するすべてのファイルを準備できます。ビルドディレクトリにすでにmagentoコアファイルがある場合、ダウンロードをスキップしてシンボリックリンクを更新するだけなので、このターゲットを使用して、シンボリックリンクを更新する必要があるたびに環境を再構築します。vagrant machineの場合、ソースディレクトリは/vagrant/src(共有フォルダ)にあり、ビルドディレクトリは/var/wwwです。

特定のmagentoバージョンのインストールターゲットのダウンロードおよびインポートデータベースダンプ。次に、セットアップターゲットを実行します。

セットアップターゲットは、ちょうどすべての設定とlocal.xmlファイルを作成します。

私の会社では単体テストとCIツールを使用しているため、この方法でmagento環境を構築すると、さまざまなバージョンのmagentoで拡張機能をテストし、インストールの有無にかかわらず実行できます。

ビルドへのアクセスを簡素化するvagrantマシンで「ショートカット」を作成しました。たとえば、プロジェクトを再構築するには、入力するだけvagrant ssh -c magebuildで、/vagrantディレクトリで自動的にphingが実行されます。

次に、このコマンドをPHPStorm IDEの特定のキーの組み合わせに割り当て、IDEでAlt + Bを押すだけでプロジェクトを再構築できるようになりました。しかし、私はシンボリックリンクを使用しているため、実際には頻繁に操作されることはありません。

放浪者

浮浪者のための箱は、Ubuntu 12.04が搭載された私自身の箱であり、実際にはすべてのソフトウェアがプリインストールされた+正確な12.04であり、ショートカットといくつかの設定があります。Vagrantファイルには、ポートフォワーディング設定、xDebugを使用できるようにプライベートネットワークを配置し、プロビジョニングへのビルドショートカットを配置します。

GIT

gitではbuild.xml、phingおよびの拡張ファイルのみを追跡しますVagrantfile。そのため、環境を作成したい人は誰でもリポジトリを複製して、迷走することができます。その後、VMを稼働させて動作するようにします。このすべてのプロセスには1〜2分かかります。プロジェクトをローカルで(VMを使用せずに)ビルドする場合は、を実行できますphing build install


2

現在、私の開発環境はUbuntu v12.04とVMWareです。完全にGUIを使用してVM内で完全に動作し、Windows 7であるホストOSからファイルにアクセスする必要がある場合にのみ、Ubuntu内でsambaファイル共有を使用します。 VMへのネットワーク接続のためのNAT経由のVM。他のソリューションを使用すると、VMWareの共有フォルダーのようにはるかに遅いことが判明しました。VMWare Image設定でこれを無効にしています。ただし、VMWareツールをインストールして、ホストマシンへの簡単なコピー/パスタを可能にします。

Matthias Zeisが指摘したように、一部のVMでは問題が発生することがあるため、ネットワーク/共有フォルダーの選択には注意してください。

私はVirtualBoxの以前のユーザーでしたが、VMWareの方が安定しており、許容範囲内であることがわかりました(少なくとも私にとっては)。ただし、お客様のニーズと要件に最適な独自のテストを実行します。VagrantはVirtualBoxを使用します。

IDE: NetBeansをIDEとして非常に広範囲に使用していましたが、その後Sublime Text 2としてより軽量なソリューションに移行しました。主にX-Debugとリファクタリングを容易にするためにNetbeansを開くことはめったにありません。Netbeans、PHPStorm、EclipseなどはすべてJavaベースのIDEであり、非常にリソースを消費します。

ハードウェアさらに追加するために、ハードウェアは常にパフォーマンスにおいて重要な役割を果たします(明らかに)。あなたの開発者がまだプラッタHDDを使用している場合、私は彼らのためにSSDに投資したいと思います。Magentoには非常に大量のファイル/フォルダーがあるため、開発者のパフォーマンスが大幅に向上します。開発中:すべてのキャッシュをオフにして、SVN / GITまたはIDEでフォルダーツリーを単純に走査します。VMに十分なRAMを割り当てることも同様に重要です。

私のホストマシン:Samsung SSD 512GBドライブ容量、Win7(64ビット)、8GB RAM、i7 2.4GHz(8コア)

私のVMマシン:Samsung SSD、30GBのドライブ容量、Ubuntu 12.04(32ビット)、3GBのRAM、i7(4つのコアが割り当てられています)。

質問: 最大の質問は、複数のプロジェクトで軽量で再利用可能な1つの開発者VMイメージを作成するか、プロジェクトごとにイメージを作成することです。以前は、プロジェクトごとに小さなVMを実行しようとしていましたが、開発ワークフローに合わせて常に再構成するのは面倒でした。

プロジェクトごとに複数のVMが選択されている場合、OS、IDE、LAMPスタック、更新/構成などのメンテナンスが面倒になることがあります。最終的には開発期間が長くなります(さらに悪いことに、ローカル環境のセットアップでは請求できない時間がかかります)。

また、新しいVMを開いたり、ホストハードウェアをさらにスライスしたりすることなく、他のプロジェクトファイルにすばやくアクセスできたため、これも役立ちました。欠点は理想的には、環境(たとえば、php.ini、my.cnf、httpd.confなど)で予期しない問題を防ぐために、各プロジェクトを他のプロジェクトからサイロ化することです。これまでのところ、すべてのプロジェクトに簡単にアクセスできるようにするというトレードオフは、より機知に富んでいます。

繰り返しになりますが、これは要件とニーズ次第であるため、事前に評価してください。

フィードバック: フィードバックにつながります。開発者からできるだけ多くの情報を入手してください。最終的には、適切なソリューションをセットアップして導入する前に、要件を満たし、問題を理解する必要があります。誰もが異なるワークフローを持っているため、開発用に選択したOSで快適に作業できるとは限りません。私の経験則では、開発者がOSとIDEを最も快適に選択し、最適なパフォーマンスを発揮できるようにします。そのため、軽量のヘッドレスLinux VMでもニーズには役立つかもしれませんが、明らかに、ホストとVM間のローカルネットワークでフォルダーを共有する問題に遭遇する可能性があります。

移植性: VMイメージをDropboxのようなものに保存して、必要なときにいつでも簡単にアクセスできるようにするというアイデアにも挑戦しました。Dropboxのようなサービスは保存されているものを少しずつ比較するので、変更したビットのみが同期されるのは論理的に思えました。しかし、これはイメージファイルの保存方法の内部に関係していると信じているため、事実ではないことが判明しました。VMが同期するのを昼夜を問わず待っています。

注: VMに割り当てられるドライブ容量が大きくなると、イメージも大きくなります。開発者にイメージを配布する際には、このことに留意してください。プロジェクトごとにプロジェクトファイルをフロントローディングするのはやり過ぎかもしれません。これを各開発者に任せて、イメージを作成した後にセットアップするようにします。

Ashley Schroderには、FoomanとColinによるいくつかのコメントだけでなく、読むのに適したやや古い関連記事があります

うまくいけば、これがリストされている問題項目、#6の洞察に役立つことを願っています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.