[wp-hackers] How do you "version" content?

Mark Jaquith markjaquith at gmail.com
Thu Apr 17 16:15:48 UTC 2014


On Wed, Apr 16, 2014 at 10:26 AM, Dino Termini <dino at duechiacchiere.it> wrote:
> I am setting up a git repo to manage my WordPress "stuff". I have a somewhat
> clear idea of how to setup my environment.
> However I would like to hear from the experts on what the best practices are
> to synchronize and reconcile content.
> In other words, how do you keep your dev/stg/prd databases in synch? (both
> directions)

For pulling down from production to staging or production to a local
development environment, I use mysqldump and rsync. I have custom
Vagrant commands on my local environment that automate this. The
procedure is to have a command that SSHes into prod, makes a mysqldump
(use -r, not to-file redirection operator >) to a
NON-WEB-ACCESSABLE-LOCATION, then rsyncs the dump file to the location
(either staging or local), and runs the db import command. You could
also leverage WP-CLI for this on either or both ends (wp db export and
wp db import). I actually prefer to NOT gzip the dump file before
transferring, and then I make sure to enable the -z flag in rsync.
This is actually more efficient in my experience, because if you
already have a recent-ish dump file on the destination, it won't
transfer the whole thing, but will do a diff, and then compress those
changes on the fly. With a binary compressed format, it'll probably
have to send the whole thing every time.

Next, I rsync uploads from prod to staging. I don't do this to local
dev if there are more than a gig or two of uploads — instead I just
have my local VM's nginx config proxy static file 404s to the
production server. In the local VM, I'm using the production domain
(pointed to my VM), so no URL rejiggering. On staging, which has to be
publicly available for clients to inspect, I use this to change the
domain on the fly:
https://github.com/markjaquith/WP-Stack/blob/master/WordPress-Dropins/wp-stack-staging.php

I've also used output buffers on the whole page to do that swap for
other things.

This is pretty straightforward. What's trickier is when you want to
migrate content from staging to production. RAMP is a solution. You
could also just write migration scripts as an mu-plugin or as WP-CLI
scripts and run those.

Right now I'm working on a plugin that solves this issue… lets you hit
"record" locally, make changes, hit "stop", and get a PHP export of
the changes that you can check in, and will run on deploy. Hoping to
get that done in the next couple months.

-- 
Mark Jaquith


More information about the wp-hackers mailing list