Magento & Subversion (SVN) - Getting a Development Environment Started?

Question

Hello all,

I'm working on building a Magento site, and it's by far the most mammoth package I've ever worked with. I've decided to set up a proper development server and use Subversion for version control. I'm running in to a couple roadblocks and need some help.

What I've done so far:

1. Set up web hosting on a host that uses cPanel. My 'Live' site (mysite.com) will reside in ~/public_html/.
2. Created a 'Development' subdomain (dev.mysite.com) that points to ~/public_html/dev/.
3. Started a SVN repository inside ~/svn/. My repo contains folders branches | tags | trunk.
4. Imported a freshly untarred magento tarball (v.1.3.2.4) into my repo at trunk/magento.
5. Created two databases a. mysite_live and b. mysite_dev.
6. Checked out the magento code from my repo into ~/public_html/dev/ (dev.mysite.com)
7. Ran the initial Magento Installer, which populated my mysite_dev Db and created some config files (app/etc/local.xml is the only one I know of - there may be others?).

Here's where I'm stuck:

So I've got a fully functional Magento Install in my dev space. What I want to do now is get my live site deployed identical to my dev site, as a starting point. Because the config is different in the app/etc/local.xml file; plus Magento stores the value for {{base_url}} inside the database, it's not as easy as updating my svn trunk from my dev site, then exporting/importing the db.

As I get further down the road with this, I want for there to be a straightforward path to push everything on my dev site through SVN and to my live site, along with keeping the databases synced except for the value of {{base_url}}. I've read a couple forum posts elsewhere that reference using svn:ignore to avoid certain environment-specific files and directories, but don't know how to get set up on my live site and ensure everything is properly synchronized.

Should I just check out a copy of the base code from trunk/magentoo from my repo to my live site's space, then run an install, then set svn to ignore local.xml, and assume that they're identical except for local differences?

At this point I just don't know how to proceed, and am reluctant to make any guesses in case it'll result in having to wipe everything out and start over again in the near future.

As a side note - I also need to create a 'Demo' branch of the code for another subdomain; to show to people as proof-of-concept. I'll probably just cross that bridge when I come to it. Maybe it'll all make sense by the time I get to that task.

tl;dr version - how do I manage Magento development&live code&Db's with SVN?

Thanks to all for taking the time to read and reply!

Answer 1

First thing to do is check in the installed version of the program. That way, the copy of the program in the repo is a working one that you can actually use. Then you will need to ignore some files and directories so that you can run the other environments. local.xml is a good example, but also set ignore on the following:

/var/report/*
/var/log/exception.log
/var/log/system.log
/var/locks/*
/var/session/*
/var/cache/*
/var/tmp/*
/media/tmp/*

There are probably others but this should give you a good start. If you think that you might make changes to local.xml (and you might), copy local.xml to local.xml.dist and check the .dist version into the repo. When you checkout onto your other sites you will still have to make the changes manually, but it will be easier to track.

For the database, a common practice is to do a mysqldump on the dev environment and keep that in the repository as well.

mysqldump -u user -p database > mysqldump.sql

You'll have to enter your password for that one. Now the copy in the repo is a complete copy of the site. To set up another environment, you'll check out the entire code base and then import the MySQL file into the database.

Remember that when you do this (and any time you update the database in the repo and then want to update the changes on other environments) you will need to change the {base_url} and {secure_url} in the database. I've seen some environments where developers created scripts to accomplish this automatically.

Finally, try to make all changes to your dev copy of the site, as it will help keep your database in sync. If you make changes on the live copy without at least also reflecting them in dev, you will probably accidentally overwrite them later with one of the dumps and then wonder where your functionality went.

Hope that helps. If you have other specific questions, let me know.

Thanks, Joe

Answer 2

I realize this is not exactly what you asked for but just want to tell you about my setup because I think it's not practical to continue to sync the dev database to production once you go live. You're probably going to want to make changes to your dev database for testing which are not always easy to revert. Building your content (products, etc) in the live environment and occasionally copying the database back to development I find works very well.

For my project I have built my live environment by installing Magento from scratch and just checked out the directories from SVN at these points:

/app/code/local/MyOrg
/app/design/frontend/default/myorg
/skin/frontend/default/myorg

Any customizations you make should be in one of these directories.

I manage this directory manually on the live server:

/app/etc/modules

You only need to create a file there if you create a new module yourself.

Answer 3

I wrote Module Manager specifically to solve these issues.

I do not recommend versioning app/etc/local.xml so that each environment can have different database credentials, but I do recommend versioning everything else using modman. Also, I recommend having modman run a script that clears Magento's cache and applies database updates such as the one found here.

When used properly you can "svn commit" to your trunk and simply run "modman update-all" on your other environments (including live) to update. For a safer update on 1.4 you can run

touch maintenance.flag; sleep 2; modman update-all; rm maintenance.flag