Question

I’ve been reading up today on database synchronization in Magento.

One thing I am currently struggling with is what needs to be synced during development and during uploads to production. Now assuming that a batch of changes will consist of changes to the DB and code alike, below would be my understanding of a model workflow (I do not currently use a ‘stage‘ server so that is bypassed in this example):

1. Sync dev DB from production DB
2. Checkout working copy of code to dev machine
3. Make changes and test them on dev server
4. Accept changes and commit them to svn repository
5. Touch Maintenance.flag on production server and prepare for upgrades (this altogether eliminates sync issues from users interacting with live data that is about to change right?)
6. Merge branches to trunk and deploy repository to production server
7. Sync dev DB back to production DB and test changes

So items # 1 & 7 I don’t fully understand when working with Magento:

• What needs to be synced and what doesn’t?
  • It seems ridiculous to sync order and customer info to me so I wouldn’t do it.
  • I would want product schema and data synced though obviously, and any admin changes, module changes, etc. How to handle that?
• What about HOW to sync? (MySql dumps, import/export, etc)
  • Currently I’m using Navicat 10 Premium which has structure and data sync features (I haven’t experimented yet but they look like a huge help)

So I don’t necessarily need specifics here (but they would help). More or less I want to know what works for you and how happy you are with that system.

Answer 1

I use phpunit to build a dev db. I wrote a short script which dumps xml data from the live database and I used it table-by-table, munging anything sensitive and deleting what I didn’t need. The schema for my dev database never changes and never gets rebuilt. Only the data gets dropped and recreated each phpunit run.

May not be the right solution for everyone because it’s never going to be good for syncing dev up to stage/production, but I don’t need to do that.

The main benefit is how little data I need for the dev db. It’s about 12000 lines of xml, and handles populating maybe 30 different tables. Some small core tables persist as I don’t write to them and many tables are empty because I do not use them.

The database is a representative sample, and is very small. Small enough to edit as a text file, and only a few seconds to populate each time I run tests.

Here’s what it looks like at the top of each PHPUnit test. There’s good documentation for PHPUnit and DbUnit

<?php
require_once dirname(dirname(__FILE__)) . DIRECTORY_SEPARATOR . 'top.php';
require_once "PHPUnit/Extensions/Database/TestCase.php";

class SomeTest extends PHPUnit_Extensions_Database_TestCase 
{
    /**
     * @return PHPUnit_Extensions_Database_DB_IDatabaseConnection
     */
    public function getConnection() {
        $database = MY_DB
        $hostname = MY_HOST
        $user     = MY_USER
        $password = MY_PASS
        $pdo      = new PDO("mysql:host=$hostname;dbname=$database", $user, $password);
        return $this->createDefaultDBConnection($pdo, $database);
    }

   /**
    * @return PHPUnit_Extensions_Database_DataSet_IDataSet
    */
    public function getDataSet() {
    return $this->createXMLDataSet(dirname(dirname(__FILE__)) . DIRECTORY_SEPARATOR . 'Tests/_files/seed.xml');
    }
}

So, now you just need a seed file that DbUnit reads from to repopulate your database each time Unit tests are invoked.

Start by copying your complete database twice. One will be your dev database and the second will be your “pristine” database, that you can use to dump xml data in case you start having key issues.

Then, use something like my xml dumper againt the “prisine” database to get your xml dumps and begin building your seed file.

generate_flat_xml.php -tcatalog_product_entity -centity_id,entity_type_id,attribute_set_id,type_id,sku,has_options,required_options -oentity_id >> my_seed_file.xml

Edit the seed file to use only what you need. The small size of the dev db means you can examine differences just by looking at your database versus what’s in the text files. Not to mention it is much faster having less data.