Wordpress site release management strategy

Question

I'm updating an existing wordpress site making significant modifications the the theme and site structure, as well as making updates to plugins which in turn store their data into mysql database.

As far as I'm aware there are 2 (3?) possible strategies here:

1. 'Dump-and-load' MySQL database from DEV to LIVE and replace wp-content folder with latest updates.
2. Import changes via WP-importer and replace wp-content folder with latest updates.
3. Make database changes manually via WP admin interface and replace wp-content folder with latest updates (this is useful only for minor changes).

While I am developing in my own separate environment this is for an existing website which is currently live and will continue to receive updates from the public such as comments and entries into contact forms, hence I expect the database to be different now from when I release my changes.

Given this the options above provide the following problems.

1. DUMP AND LOAD

The 'dump-and-load' strategy seems to be out of the question as my data is being updated behind the scenes (this would have been my preferred approach as this is easily rolled back).

Result: requires synchronising databases post release to get latest updates, TOO COMPLICATED.

2. USE THE IMPORTER

Using the WP-Importer plugin page and post IDs will get updated, screwing up styling that relies on the post IDs to get activated. This in turn creates a CSS nightmare that I wish to avoid, having to go though the CSS after release to update the new page/post IDs with the ones the database created.

Result: Too finicky, not very professional approach leading to long and complex release process.

3. UPDATE DATABASE MANUALLY

This option is great for small changes but when for more complex releases the list of steps to follow on the PROD interface becomes long and hard to follow, making it easy to make mistakes.

Result: Too easy to screw up, only a last resort.

IS THERE A STANDARD WORDPRESS RELEASE STRATEGY FOR EXISTING WEBSITES?

So basically, my question is: What release process do other wordpress developers follow when UPDATING an existing website? Is there an option that I have not listed below that minimizes hassle and reduces time and complexity during release?

I've set up source control for the site using GIT and I am used to automating things via ANT or similar release script, this may be overkill for the current project but would be ideal to at least know of a simple way to update a wordpress site and minimize the chances of screwing it up.

Thanks!

Answer 1

I don't think this is particular to WordPress, it's a similar situation to any custom site. I personally favor replaying the SQL changes on production that were made on dev. The tricky part is that you have to know what SQL changes were made. For example a certain plugin may make some schema changes when you install it - you need to know what they were. You can do that by creating an export of your DB as SQL before installing a plugin, then take another export after and do a diff on the files.

Since you say you're making the modifications then I might assume you know what SQL changes you are going to make? Just make sure all changes you make to the DB are in the form of SQL script files and not just editing using the GUI (you can use the GUI to help write the queries, but save the actual SQL). After all of your changes are done you should have a bunch of SQL scripts that you ran during your development process - you can re-run them in order without encountering errors.

Then when it's time to push to production, create a staging version of production (that is take a fairly current DB backup of production). Run your update scripts on that and test that everything is ok. If it is, then you can run on production.

definitely make a backup of production before running any changes on it!

Answer 2

• The guy behind WordFence was working on a deployment plugin called Deploymint.
• There's a new one called WP Stack.
• Metal Toad Media discussed using Capistrano, but that Capistrano isn't specific to WP.
• CrowdFavorite launched a service called RAMP.

Needless to say, you have some other options. If you're making db changes manually make sure you're working with the serialized data effectively. I recommend using Search and Replace DB. WordPress also had a great little trick for changing the site url entirely from the wp-config file.

Answer 3

I assume you have everything running in a test environment. I would then:

• Create a new database in your live environment.
• Preload it with all content and configurations for the new site.
• In your test environment, configure your config.php to point to the new database.
• Upload all files to the live server. Upload your config.php last.

This will minimize downtime.