CODEWITHSUNDEEP
svnversion-controldeploymentmagento
David
David

Reputation: 191

Magento staging and production

I have been developing with magento for a while now and things are starting to make sense and become much more deliberate and organised. One aspect though still seems quite messy - moving a site from development to production.

Can anyone offer some good processes for this - up to now I have simply been exporting/importing the the development database, copying source files over, clearing out test orders, customers etc then changing base urls, htaccess files etc.

It all seems a bit messy and error prone. Do any of the more experienced Magento developers have a good process in place for this task that they could share.

Upvotes: 19

Views: 5502

Answers (2)

Prasath Albert
Prasath Albert

Reputation: 1457

1) Copy the files. Clear the var/cache and var/session folders.

2) Export the database, create a staging database, and import this dump file.

3) Update the app/etc/local.xml file with your new staging database information.

4) Modify your database using a tool such as PHPMyAdmin, and edit the ‘core_config_data’ table to update the base URLs (/web/secure and /web/unsecure)

for this Run the query:

 SELECT * FROM core_config_data WHERE path = 'web/unsecure/base_url' OR path = 'web/secure/base_url';

and modify the values of resulted rows.

5) If you have SSH access, run this command in the staging store’s document root:

./pear mage-setup .

6) Run the website in the browser

Upvotes: 0

Joe Mastey
Joe Mastey

Reputation: 27119

My process is usually managed around a source control repository (SVN in my case), which makes things much easier (or possible, really...). The idea is to keep everything possible in the repo and use SVN updates and tags to publish changes.

local.xml: I move this file in SVN to local.xml.dist and ignore the actual local.xml file in the repo. This lets you use different database credentials and hosts on your installations without polluting the codebase.

other ignores: Check out this question for more files that should be ignored in the database. Basically, anything unique to the environment should be kept out of version control and handled on the actual host. Your .htaccess files will be relevant here.

host setup: My staging environment and dev environments are set to run off of /trunk from the repository. Development occurs here, and can be pushed to stage periodically (or on demand) via svn up to show new features to the client and do UAT. The production environment needs some protection from the Wild West of trunk, though, so that environment runs off of tags. Whenever a feature set is ready to go out, I create a new tag from trunk and do an svn switch to move to the new code set. Doing things this way also gives me an easy undo for production (switch back to the last tag). Thus I have removed all manual file pushes from my life, which is good.

An even better system (which I've had no need for yet) would be to use svn export to create a complete copy of the code tree on the production system, and use ln to switch between them. Something like this:

> cd /home/apacheuser
> ls -l
www -> /home/apacheuser/tag_1.0.1
tag_1.0.1

> svn export /url/for/repo/tags/1.0.2 tag_1.0.2
... svn exports here ...

> rm www; ln -s /home/apacheuser/tag_1.0.2 www

That way, version changes are instantaneous.

db sync back from production: To allow me to work on production-ish data, I have a cron-job set up to dump the production database and import it into staging. While this is happening, the script will remove sensitive customer data (and change customer email addresses so that all emails go to me). It will also change credit card gateway settings to a test gateway and change the base_url parameters so that the staging site URLs work properly.

new development: You may notice here that different environments run off of roughly the same codebase (minus any new changes), which may seem troublesome to you from what you've noted about database changes etc.

The only way to manage this complexity (and the right way, at the same time!) is to make sure that the code itself keeps track of necessary changes to the environment. Magento supports automatic module version upgrades, including database scripts, which you should use to make schema changes, etc. This means that, as you deploy new code to staging/production (or as you get it from another developer in your dev environment), all database patches are applied automatically.

This also means that you need to write new functionality to be as non-destructive as possible. Magento themes, disabled modules and such can be used to make this a reality. For example, when creating a new theme for the site, make sure not to modify any of the core behavior, and keep all new assets in a theme that will be inert on production until deployed.

more developers: This setup is based around a relatively small number of developers on a project. There is an implicit assumption that, when you want to tag a new release, you can get trunk into a working state to do so. With more developers, this will be the case less and less, so a more complex repo setup is necessary. If I run into that, my plan is to move over to using git instead of SVN and to use feature branches for new development.

Let me know if any of that was unclear. Hope that helps!

Thanks, Joe

Upvotes: 27

Related Questions