Magento Dev Environment on Windows 7

In this post, I’m going to walk through how our development team configured our development environment on a Windows OS for Magento.  The impetus for this was to support an out sourced site running Magento in a LAMP environment; keeping in mind the need for continued support of current projects on the Windows stack.  Thus we’ve moved to using XAMPP on Windows to support a company site on Linux.  Fun right!?

We decided to go with the XAMPP Package to install Apache, MySQL and PHP.  The version may be unimportant, but XAMPP 3.1.0 Beta 6 was used at the time of this writing.  When finished with our environment, we had three sites we could hit from our development machines:

  1. The XAMPP Startup/Splash page on the root (Example: http://local.dev:100/)
  2. A fresh Installation of Magento at a subdomain (Example: http://magento.local.dev:100/)
  3. A copy of the company site (running Magento) configured at a subdomain (Example: http://company.local.dev:100/)

The following is a list of downloads we found useful for setting up the development environment:

  1. XAMPP (the platform)
  2. NetBeans IDE (the development tool)
  3. XDebug (debugger for PHP)
  4. WinSCP (used to move files off Linux server on to development machine)
  5. Git (Distributed Version Control System)
  6. 7-zip (used to unzip compressed database and folders from Linux environment)
  7. MySQL WorkBench (MySQL GUI for development)

Below is a general outline of steps taken to establish these three sites on our development machines:

  1. Using a Zip Package of XAMPP
  2. We Kicked off the setup_xampp.bat file after storing the folder structure in the desired location
  3. Configured Port to use 100 instead of 80 (optional) due to IIS using port 80 (under install-path\xampp\apache\conf\httpd.conf)
  4. Added new domain names in the Hosts file (c:\windows\system32\drivers\etc\hosts)
  5. Configured Virtual Hosts File (install-path\xampp\apache\conf\extra\httpd-vhosts.conf)
    1. Referenced domain names from the Hosts file
    2. Added MAGE_IS_DEVELOPER_MODE “1” to Each Virtual Host configured
    3. Each Virtual Host referenced a folder under the default install-path\xampp\htdocs\ path using the DocumentRoot attribute

      Sample vhost file

      Sample vhost file

  6. Launch/Restart Apache and MySQL services under XAMPP control panel  (install-path\xampp\xampp-control.exe)
    1. open default website based on configured domain and port and confirm “XAMPP For Windows” site opens
    2. Local XAMPP Site Complete
  7. Obtained Copy of Magento Enterprise Edition (Community will suffice)
    1. Copied Magento folder structure under the install-path\xampp\htdocs\ path
    2. Created a new database for Magento using mysql (or MySql Workbench)
    3. Site opened with installation page for Magento.
    4. Began Installation
    5. Magento Out of the Box Development Site Complete
  8. Obtained Copy of Company Site (developed on Magento)
    1. Used WinSCP to retrieve a copy of Company Site from Linux servers (or pull from Git repository)
    2. Retrieved a copy of the database as well (using MySqlDump)
    3. Retrieve a copy of the media folder as well
    4. Create database schema for the new database in mysql (or MySql Workbench)
    5. Imported SQL file into new database
    6. Confirm app/code/etc/local.xml exists and configured accordingly
    7. Change domain name in core_data_config table to reflect development URL
    8. Run Site
    9. Company Magento Site Complete
Advertisements

7 thoughts on “Magento Dev Environment on Windows 7

  1. Thanks for the well laid out post, please can you share how you introduced version control (Git/Github) in the midst. Also I was wondering why you felt it is necessary to have a copy of the company site local, does it make any difference of if you left the live site at the live host. I want to setup a similar dev environment, I just want to see what the best way to incorporate Git

    • @Val Okafor: For us, we have a private “Master” repository of the production site on GitHub and each developer has a forked copy of the code. While we could all work from the “Master”, we chose to create our own forks for two reasons. First, none of us have ever used Git and are still learning; second, we didn’t want to step on each others toes during development and accidently screw up another developers work. In hindsight, using git branching instead would have mostly alleviated this issue, but we still prefer each man having his own island, so to speak. Having a copy of the company site locally is, in our opinion, vitally important. We’re free to work on the site autonomously without affecting each others testing and coding. Again, each man is his own island. When each developer is ready to release code, they push it to a shared QA server (on a linux box, testing any inconsistencies between Linux and Windows environments) and merge with other developers to finish the picture of what the production site will become. When we have satisfied the QA testing we “git push” QA to GitHub and “git pull” from GitHub to production. Hope that helps!

  2. Thanks for explaining, that makes sense and I will try to incorporate some your strategies into my dev. environment,

  3. Could you walk me through how you handle future Magento core updates, and issues with figuring out what files were removed from updates and major changes to layout, template, and CSS files that may break your custom theme.

    I’ve setup things similar to you but I use SVN with vendor branching to make core updates easier, but it still seems very difficult at best.

    We also commit changes from multiple local Dev boxes to a Dev server hosting our SVN repo which uses post commit hooks to update a unified working copy for testing, then from there we can push to a staging server which allows us to pull a live copy of our database and test for any issues in a simulated live setup right before we then push the final product to the live server.

    We also use the same production domain name for every environment (local, dev, staging, and live) but use a Firefox extension that allows us to switch hosts files so we can view any one we want at any time, including coworkers’ local copies for help and collaboration.

    • Steven, sounds like you may be a bit further along than we are. I’m researching configuring a continuous deployment pipeline for our sites, but haven’t made it there yet. We’ve moved to Mac OS-X, so our configuration isn’t the same as I speak of above, but we’re still using a similar process. I use GIT currently to manage multiple developers pushing code for site updates weekly. The developers create a new branch for each task and we merge, rebase and cherry-pick those branches into a release branch within our staging environment. Once all new code has been verified/tested on our staging environment we push the release to production (merging our release branch into our master on production).

      With respect to Magento, all updates, whether core patches or otherwise, are implemented in development and pushed to staging and production via GIT. GIT does a great job of keeping tabs on which files were changed (even removed). I use the command line for GIT and am quite comfortable with jumping between branches and compiling several branches into a release for production.

      Hopefully that provides a suitable answer to your question. If not, let me know. I’ll have to check into the FireFox extension you mention. It sounds like a clever way to address domain names to multiple environments.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s