CODEWITHSUNDEEP
databasemagentodeployment
Jared Eitnier
Jared Eitnier

Reputation: 7152

how to safely deploy stage database to live production database in magento

Being very new to versioning and source control I'm wondering how some of you have gone about safely updating your dev database changes to production using Magento and what tools help you do it.

I've got a repository setup for my dev changes and a local machine running a dev version of magento, but I don't know the safe (and proper) way to merge my database changes. What if I add some products, add an extension, change some admin settings in my dev environment but want to merge my changes with a live store that is taking orders, adding customers, etc.? I would think that some type of merge would be appropriate, almost like source control for a database but is this even possible?

I'm not sure if it helps or matters but I am using NetBeans and I frequently use Navicat to browse through db tables and such.

Upvotes: 4

Views: 3512

Answers (2)

XPS
XPS

Reputation: 330

Extensions have install/upgrade scripts, so update production should not be a problem.

But if you want to transfer products/attributes changes from staging to production, then you need to use export/import tool. For example, it can be a native magento export into csv.

Or I can propose to use automatic migration tool, that will compare staging and production database, and transfer all products or attributes that missed on server http://xpscommerce.com/blog/quick-push-magento-database-to-production/

Products transfer include images transfer too.

To run migration tool, it required to setup XMLRPC account to access server data.

Upvotes: 0

Dan LaManna
Dan LaManna

Reputation: 3501

Versioning Database Schema
Not extremely relevant - since each module in Magento can have its own set of setup/upgrade scripts. If interested though, there are tools for managing the schema of a database, such as dbDeploy.

Versioning Database Content
Imagining the environments as a set of tiers, at the top is the staging environment, and below it (on the same level) lie the development environment(s). All code changes can be done on any environment since all environments are just working copies of the same versioned source code. Each database is grabbed from the next "tier" ups environment. So for example, a dev environment would pull the database from the staging environment, and when the production environment exists, the staging environment will pull from there. So any changes to the database (ie updating a product, changing a setting in the config pane, etc) has to be done on the uppermost tier, and then all tiers below it will receive the changes the next time they update their database. Now obviously when developing you can change as many things as you want to ensure it works well on your development environment before making those changes higher up.

How the pulling business works
Pulling (and pushing) the database is pretty simply done, a mysqldump is performed of the database, then search/replaced (using sed or something similar) with the url changes, and then imported into the new database.

Having said that...
Kudos to you for having your source code versioned, this at least means that if you do have to follow my scenario, that you can fully test a module on a development environment before making the changes to production. I wish I could offer more of a concrete "solution" - as having to perform changes on multiple environments is certainly not ideal - though I'll be interested what others bring up.

Upvotes: 4

Related Questions