How to migrate content edits in Drupal from staging to live environment

Question

I have stagging environment where I used to add and update contents first and than move it to live site once the changes passed by the QA.

I can't use the backup and migrate module because of the larger size of the database.

Also can I make the process automatic so that every day I won't need to manually migrate the content from stagging site to live site.

Answer 1

Migration becomes one of the most important tasks when you work on stagging environment and upon finishing you to push the changes (database changes) to the production site

• Use the Features module for migrating the content types, block etc.
• Use Migrate module for migrating the entities and the best thing about migrate module is drush integration.
• Panels, views, rules can be directly exported and than imported on live site.
• Use Read only module if you don't want to take your site offline, it will allow access (reading) of new content while preventing the addition of new content.

If you want to automate the migration process than you can create the drush script for migrating the new contents (edits/updates), and schedule the cron for running the created script (when traffic is minimum on site so that it doesn't affects the performance of the site).

Answer 2

I use readonlymode when migrating my sites, which I daily do to migrate localhost content to remote host. I use drush's sqlq command to restore which better than BackupRestore module.

For proper migration, you must compare sites/all folder with that of live one. You also need to copy sites/default/files to the live one.

My typical restore goes like as in this Perl script:

chdir ("$home/public_html/$site") or die "Unable to change to site dire=$home/$site\n";

( $sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst ) =   localtime(time);

$mon++;

$year += 1900;

my $file = "$inputdir/$prefix-sql-dmp-$mday-$mon-$year.sql";

-r "$file.gz" or die "$file.gz does not exists\n";

#compare modules
my $modulesfile="$inputdir/$prefix-all-$mday-$mon-$year.tar.gz";
my $modulesdir="$home/public_html/$site/sites/all";
if( -f $modulesfile)
{
run_cmd("$home/scripts/gij-restore/dircmp.sh $modulesfile $modulesdir");
}
run_cmd ("gunzip $file.gz");

run_cmd ("drush cc all");

run_cmd_ignore ("drush cron");

run_cmd ("drush vset site_readonly 1");

run_cmd ("drush sqlq --file=$file");

run_cmd_ignore ("drush pm-disable --yes devel ");

run_cmd ("drush cc all");

run_cmd_ignore ("drush cron");

run_cmd ("drush vset site_readonly 0");

unlink "$file" or die "Failed to delete $file";

print "Site restore success\n";

sendemail($site,"Restore success!");

Answer 3

Migrating complete database can be risky, you will loose the changes on your live site.There are multiple ways to migrate, here is my view.

• Use features modules to migrate the content types with dependencies from development to live site,
• use migrate module to export your entities.

Views, panels and rules give you the export code ready to import, that pretty much covers up a migration process. Even if you migrating complete database, you can avoid tables like session, cache_*, watchdog and search (they have to be rebuild on next cron run).