[wp-hackers] WP Development & Production Sites

Mike Schinkel mikeschinkel at newclarity.net
Mon Nov 29 10:51:56 UTC 2010


On Nov 29, 2010, at 5:18 AM, Andrew Nacin wrote:
> Really, what you should do, is reverse the deployment process, as Otto
> suggests. Don't work off http://localhost/example/ then try to deploy to
> example.com. Rather, have your install believe it is the live example.com,
> then fake it to work on your staging environment. If it breaks on live, you
> have a problem; it it breaks on staging, well, that's not much of a problem,
> is it?


 It's a nice, idealistic approach and it works for most people who have simple scenarios but doesn't work for more complex scenarios.  Case in point, when a client asks to maintain several versions at several different subdomains (literally in my case "staging", "demo", and "demo2") and them all work all from their computers and their client's computers, and they want they each update periodically when they request managing multiple configurations simply gets to be too big of a PITA.

> It's honestly trivial to properly set up a development environment that fits
> the needs of both you and your client. I would just advise you that you look
> at it from the production environment to the development environment, rather
> than the other way around.

Yes it is possible when things start getting complex that I could juggle all the balls as you suggest and keep them all from dropping.  But it's an approach requires too much manual effort, and fails too easily.  In other words, that solution does work in many of the more simplistic cases but is not a panacea.

> In the end, ultimately, what you have are thousands of developers all with
> their own techniques. Over time, many of you will tune and perfect your own
> techniques to match your own deployment cycles, processes, and requirements,
> but notice the key words there: "your own". These techniques will likely
> converge into neat categories, but it is largely a to-each-his-own issue.
> This doesn't affect the vast majority of users. (And, may I add, that those
> who are affected by it, generally have the added and convenient benefit of
> knowing how to write code.) As Jacob just wrote, this is quite the esoteric
> issue.

I've heard the refrain that "everyone's use-case is too different to create something that works for everyone" on many different platforms, for over 20 years.  I almost believed it back in the late 80s, but I've seen the assertion disproven too many times. The web disproved the assertion that "dissimilar computers can never be integrated onto a common network," and WordPress itself disproves the assertion that most websites can't be built on a single framework because their requirements are "too different."  Sure there are outliers, but the number of real outliers need only be tiny.

So I've seen this problem solved before on other platforms and I'll see it solved on future platforms again.  And it will be solved at some point in the foreseeable future for WordPress too, just probably not in core.

-Mike



More information about the wp-hackers mailing list