12

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?

Improve this question

3 Answers 3

Reset to default
4

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.

Improve this answer
2
  • We just started doing that, coincidentally. It definitely helps. We can't afford a long deployment period. Thanks for adding that tip!
    – Mike Lee
    Commented Aug 16, 2010 at 21:30
  • Note that you should change the TTL that much time before you actually change the IP. In other words, if TTL is one week, you should change the TTL to 5 minutes one week before you change the IP, so that everyone will be on the new TTL when do so.
    – Daniel C. Sobral
    Commented Mar 27, 2012 at 21:09
2

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.

Improve this answer
3
  • In this scenario would you make the old site effectively read-only while DNS is in transition to prevent changes to the site that will not be migrated?
    – Trevor Bramble
    Commented Aug 12, 2010 at 16:31
  • That's an alternative approach, to just prevent any new data from being added to the old site's db during the transition. The approach I mention above, though, leaves the old site active during the transition, then manually merges any extra db entries that appeared during the transition (new posts, comments, etc.) into the new site. edit: just wanted to mention that acterry's suggestion about TTL Records is fantastic advice.
    – SethMerrick
    Commented Aug 13, 2010 at 21:36
  • We've done something similar to that to. Not seamless, but hey, it works.
    – Mike Lee
    Commented Aug 16, 2010 at 21:27
2

@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.

Improve this answer
2
  • WP Migrate Webhosts sounds like a much-needed plugin. Thank you for sharing that, and this feedback!
    – Mike Lee
    Commented Aug 16, 2010 at 21:21
  • Yes, I think so. I hope to get collaboration so I and others can evolve it to be uber useful! Thanks for the up vote.
    – MikeSchinkel
    Commented Aug 16, 2010 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.