memuller

Same issue here, on WP 3.3.

Rolling back the WP version indeed works, but is very annoying, and I’m unwilling to perform it on large blog networks.

I filled in a ticket about it with the bits of information here, let’s see what happens.

That’s some awesome feedback! Thank you all.

@ipstenu:

…it’s a LOT of work and a lot of customization to what YOU have and something you’ll want to hire for.

Indeed.

…use a sample DB with a selection of your posts that are the important types. But this one’s really complicated :/

Yeah, and and the resulting DB may end up not being a faithful representation of the real one. Much like Boone mentioned, I had a few edge cases issues that didn’t show up on the data slice I took.

* About your scripting approach:
Your approach seems specially interesting. I’m used to writing unit/integration tests for my other projects, so it pains me greatly to not do the same thing with WP.

Can you please share more information about how you do that (like what tools do you use)?

I should mention I work for a Fortune 100 bank, with thousands of people in a dozen countries. We take this stuff really seriously ??

That’s impressive, and makes me even more interested to know how you do that tests; since if it’s good enough for you, it’s also going to be for the vast majority of people.

We’re a religious non-profit organization here; which makes implementing good development practices a pain – since our income isn’t very dependent on the quality of the services we deliver (most of it comes from donations and the like), it’s really hard to get resources to improve things. It’s amazing how stale an enterprise can get when it doesn’t need to be competitive.

@boone:
Now thats a lot of info – let’s talk about it:

* About the server setup and repositories: that’s a lot similar to how we already have it running here (or to how we’d like things to run).

* About the database syncing: we tried the the local hosts file solution here, and observed the same points – easy and foolproof, but leads to a lot of mistakes and confusion. I them tried the script approach, trying to change the hostname on a few tables/fields that I knew mattered, but it didn’t work very well – maybe I’m missing some important stuff; or I should just give up on trying to change some specific places and scan every table/field instead. Since it’s exactly what you do, I would indeed like very much if you could share the script that you use.

* I really like your suggestion of using “action tags” on the commit messages. That’s going to be really helpful on non-WP projects too.

* We also took the same approach in regard to the wp-config .

* About QA, it also pains me to not have unit tests on it. Your descriptions of your workflow and how you branch stuff were very useful.

@rennick:
Interesting. Here, along with the hosts file entry, we’re experimenting with a browser extension (Fireproxy for Firefox) and our own proxy server to allow us to easily switch between the development/production environment.
The thought of “piping” the DB backup through a command-line tool in order to change the domain references didn’t occur to me – thanks, I’ll try that out

I have to ask … how did you do it before?

We’ll never know for sure, most people that worked on setting the thing up are no longer with us, and they didn’t document much. However, they didn’t work on some problems that we know are fixable (eg. the domain names), so I guess they believed that there was no way to make things a little more reliable, and just got used to it.

…how YOUR company handles development in general and what process you have to fit this into?

We use a VCS (Git) and a staging server that receives work. When we’re done with whatever we’re doing, we mark a release, and the code goes to production servers. We work mainly with Rails/Ruby applications, so we got used to have a lot of tools to make code more reliable and overall just make our life easier. A lot of the struggle is to make things that we take for granted (continuous integration, integration tests, etc) also work with WP.

About our processes, I think there are two major sources of conflict (all mentions to “code leaving the developers machine” means it entering the version control system):

* Code shouldn’t leave the developer’s machine unless it’s stable. So, we presume that each developer should have a local environment that enables him to reliably validate the code’s stability. Since we weren’t able to do that, we had to send code to the integration server to test it.

* All code that leaves the developer’s machine should be environment-agnostic – that is, it should not have any kind of information that locks it down to an specific server. If that cannot be avoided, code should be provided to adapt the application to each environment.

That means, for example, that the wp-config.php (which contains database information pertinent to each environment) should not leave the developer’s machine (which is fine).

That also means that, since we cannot avoid the fact that WP stores the domain name (an environment-specific thing) in the database, we should provide a code that easily changes it (which I can’t do right now, but I’m pretty sure it’s possible).

There’s still a problem with plugins & themes, we have a lot of them, of varying quality, and some of them don’t handle the different environments very well (sorry if that sounds vague, but it’s exactly because we are having trouble testing everything). Initially, we left the plugins out of the application itself (eg. they were environment-specific) so it would be easier to set up the environment; but the plugins are a very important part of the application, and testing without them just isn’t realistic.

a couple sql scripts to tweak the domain names to dev-domain.com or something similar

Yes, thank you – I managed to do that with normal WP installations (just changed two wp_options and all menus/attachments), but that doesn’t seems to be enough on multisite. I’m guessing that I’ll also need to change the wp_blogs and wp_sites tables… I’ll try that.