Magento Development Setup

Question

this question is directed towards setting up the development environment. I have some specific requirements:

1. I want to be able to use my solution under Linux, Windows and Mac OS, since people of our team use all these OS (e.g. front end developers use Windows / Mac, back end developers mostly use Linux)
2. I need to use modman
3. I need to use composer
4. I need to use Github as well as my private Git repositories
5. I need a proper IDE like Netbeans or PHP Storm
6. I want very good performance

My current setup is a virtualized Ubuntu image within Virtualbox. All three OS can run Virtualbox, so points 1) - 5) are all satisfied.

However, currently, I am not completely satisfied with 6). This is especially true when running the solution from within Ubuntu 12.04. The Virtualbox seems much more stable and responsive under Windows 7. However, many people in our team are using Linux, so I would like to improve the solution.

Does anyone have a comparable setup in VMWare or maybe even docker.io and can report whether it runs more stable? Or does anyone have other comparable solutions / ideas?

Answer 1

I use vagrant, git and some build script on phing. The vagrant machine run database and web server, git used locally to track changes in my extensions and build script used to update /var/www directory on my vagrant machine (well actually it used everywhere where i need to build an environment).

Phing

Probably most interesting part is phing, which work like modman + composer for me. It has few targets defined including build, setup and install.

The build target download certain version of magento (specified in build config) from internal webserver and extract it into build directory. Then run other targets which setup permissions for files and cleanup the cache. Then it create symlinks to all files in the source directory. In result I get all files ready to use in my build directory. If magento core files already in build directory it skip downloading and just update symlinks, so I use this target to rebuild environment everytime I need to update symlinks. For vagrant machine source directory is in /vagrant/src (shared folder) and build directory is /var/www.

The install target download and import database dump for certain magento version. Then run setup target.

The setup target just create a local.xml file with all settings.

In my company we use unit testing and CI tools, so this way to build a magento environment allow us to test our extensions on different versions of magento, and run it with and without installing.

I have created a "shortcut" on vagrant machine which simplify access to build. For example to rebuild project I need just type vagrant ssh -c magebuild and it's automatically run phing in /vagrant directory.

Then I have assigned this command to certain key combination in my PHPStorm IDE and now I can rebuild project just by pressing Alt + B in my IDE. But since I use symlinks it's not really often operation.

Vagrant

A box for vagrant it's my own box with Ubuntu 12.04 on board, it's actually just standard precise 12.04 with all software preinstalled + shortcut and some configuration. In vagrant file I put just port forwarding settings, private network to be able to use xDebug and put build shortcut to provisions.

GIT

In git I track only my extension files, build.xml for phing and Vagrantfile. So everybody who want to create an environment can just clone repository, and run vagrant up. Then he will get VM up and running ready to work. All this process takes 1-2 minutes. If you want to build project locally (without using VM) you can run phing build install.

Answer 2

Currently my development environment is Ubuntu v12.04 with VMWare. I work entirely inside of the VM, with full GUI and only use samba file sharing within Ubuntu if I need to get to the files from my host OS which is Windows 7. I normally access and map a network drive via the internal IP of the VM via NAT for networking to the VM. Using other solutions proved to be much slower like VMWare's Shared Folders. I have this disabled in my VMWare Image settings. I do however install VMWare tools to allow for easy copy/pasta to my host machine and vise versa.

As Matthias Zeis pointed out, be careful in your selection of networking/shared folders with your VM as some will prove problematic.

I was previous user of VirtualBox but found VMWare to be more stable and performs acceptably (at least for me). I would however perform your own tests to best suit your needs and requirements, ie. Vagrant uses VirtualBox.

IDE: I was using Netbeans quite extensively as my IDE of choice but have since moved to a more lightweight solution as Sublime Text 2. I rarely will open Netbeans as mainly for X-Debug purposes and easier Refactoring. Netbeans, PHPStorm, Eclipse, etc. are all Java based IDE's and can be very resource hungry.

HARDWARE: To add more, Hardware will always be a key role in performance (obviously). If your developers are still using platter HDD I would look to invest in SSD for them. Since Magento has a very large amount of files/folders it will greatly speed up developers performance. While developing: With all caching off, and While simply traversing the folder tree in SVN/GIT, or your IDE. Giving your VM enough RAM is also just as important.

My Host Machine: Samsung SSD 512GB Drive space, Win7 (64bit), 8GB RAM, i7 2.4GHz (8 cores)

My VM Machine: Samsung SSD, 30GB Drive space, Ubuntu 12.04 (32bit), 3GB RAM, i7 (4 cores allocated).

QUESTIONS TO ASK: The biggest question is, to create one Developer VM Image that is lightweight and reusable across multiple projects, or to create an Image per project. Previously I was trying to do smaller VMs on a per project basis however the reconfiguring constantly to go with my development workflow became too much of a chore, and now use one larger VM and try my best to keep each project as isolated as possible.

Maintaining OS, IDE, LAMP Stack, updates/configurations, etc. can become a chore if multiple VM's per project is the route chosen. Ultimately leading to longer development time (and even worse un-billable time for local environment setups).

This has also proved helpful, as I was quickly able to access other project files without the need to open up a new VM and slice my Host hardware even more. The downside is ideally I would want each project to be siloed from other projects to prevent any unforeseen issues with the environment (ie. php.ini, my.cnf, httpd.conf, etc.). So far the tradeoff of having all projects easily accessible has proved to more resourceful.

Again this is up to your requirements and needs so evaluate them before hand.

FEEDBACK: Which leads to feedback. Get as much input from your developers as possible. Ultimately their requirements need to be met and their problems understood before a proper solution can be set up and put into place. Everyone has different workflows, and not everyone is comfortable working in the OS you may chose for development. My rule of thumb is let the developer chose their OS and IDE they are most comfortable in and will perform best with. So even a lightweight headless linux VM may prove useful to their needs, but obviously can run into the issue of sharing the folders across the local network between the Host and VM.

PORTABILITY: I have also toyed with the idea of keeping my VM Image on something like Dropbox so I could easily access it at any time I may need. Since services like Dropbox compare bit by bit of what's stored it seemed logical that only the bits i've changed would be synced. However this proved not to be the case as I believe it has to do with the internals of how the Image file is saved, and I would be waiting all day/night just for my VM to sync.

NOTES: The larger the drive space allocated to the VM the larger the Image will become, keep this in mind when distributing the Image to your developers. Front loading your project files per project may be overkill and I would leave this to each developer to set up after they have the created image.

Ashley Schroder has a somewhat old related article that is a good read, as well as some of the comments by Fooman and Colin

• http://www.aschroder.com/2010/07/structuring-your-magento-project-for-engineering-not-hacking/

Hopefully this helps with insight to your listed item of problem, #6.