My team and I are working with a client who has an existing WordPress site with a fair bit of content and a custom theme they built. It is a group blog, meaning it has several bloggers all around the world who are adding & editing content all the time.
Our job is to create an entirely new theme, with quite a few new features. Some of these features will require new custom widgets, plugins, and database fields.
We’re currently working off our own development machines and integrating them into a single development server. All code is versioned in SVN. Our appointed DBA is manually merging any database changes into the dev DB right now, though hopefully he’ll be able to automate that soon.
We just started talking about our production release process. Meaning: once we’re done, how are we going to get all of our custom code onto the production (the live) server smoothly and with as little disruption as possible?
We have a few plans in mind, but I would love to hear how others have tackled this issue too. Are there any best practices to follow or known pitfalls to avoid?
If you follow SethMerrick’s advice, you can greatly reduce the switchover time by lowering the TTL on the appropriate DNS records to 5 mins or so several hours (depending on what the current TTL is) before you change the IP address.
By doing this you are telling remote DNS servers to only cache the address for 5 mins. Once you change the IP, you can increase the TTL to whatever it was before. To further minimize the effect, do the switchover during a low traffic period.
I’m not sure if this is applicable, but I just went through a similar process of simultaneously migrating and upgrading a high-traffic site.
The basic strategy was to work on a staging server, then when everything was ready, do a mysql dump on the live server, import it to the staging server, do any required cleanup, then point the DNS records to the staging server, causing the staging server to become the new live server.
The tricky bit is to then merge all the data that accumulates during DNS propagation into the staging server (which is now the live server). In other words, if 30 hours pass between when you do your mysql dump / update DNS and when DNS propagation is complete, you’ll have to selectively merge 30 hours of records from the old site to the new one.
It’s not a seamless process, but by the time we got a week down the road all the kinks had smoothed themselves out.
@Mike Lee: Great question, and one of the holy grails of WordPress (or any of the mainstream open-source CMSes that I’m familiar with for that matter such as Drupal, Joomla, et. al.)
While it’s certainly not meant to address your use-case do check out my answer to a related question which describes a beta-level plugin I just made available via WordPress Answers Exchange called WP Migrate Webhosts (yes, I suck when it comes to creative naming.)
But I also want to solve the use-case you describe with a plugin and am currently thinking about how to accomplish that. I’m thinking the way to approach it is give up on solving it generically and instead address the known patterns that exist in WordPress and then allow anyone else to “hook” my plugin for special use-cases. I’m also thinking an approach is to serialize the data and structures in WordPress as data in a PHP file so that a future plugin could apply those changes as deltas just like a source code control system applies deltas to arrive at the current version of source code.
So while I’m not answering or solving your problem in full I hope I’m giving you some good food for thought and also hoping that you or someone else might want to collaborate on an eventual solution.