On Thu, Oct 21, 2010 at 8:18 PM, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote:
Nope. Automated tests help a lot with this approach
but Flickr doesn't
have much better tests than MediaWiki does.
We *should* have better tests, but I would just say that it is not
required for us to have a great test suite before doing this.
Interesting.
Doing things the Flickr way entirely would require:
1 - A "feature flag" system, for "branching in code". The point is
to
start developing a new feature with it being turned off by default for
most environments and without succumbing to branching and merging
misery. In other words, day one of a new feature looks like this:
if ( $wgFeature['MyNewThing'] ) {
/* ... new code ... */
} else {
/* ... old code ... */
}
Of course if you're fixing bugs there's no need to hide that behind a
feature flag.
I always do this anyway, personally (as apparently Bryan noticed).
Sometimes it can get cumbersome and hard to maintain, but thankfully
it means I've never had to learn how to use SVN branches. :)
2 - Every developer with commit access is thinking
about deployment onto
a cluster of machines all the time. Committing to the repository means
you are asserting this will work in production. (This is the hard part
for us, I think, but maybe not insurmountable).
This was true when we had regular deployments too. Anything that
wasn't ready for production yet would just get reverted.
TranslateWiki still runs on trunk, and its developers vigorously prod
anyone who breaks trunk. So I think we're okay on this score.
3 - One can deploy with a single button press (and
there is a system
recording what changes were deployed and why, for ops' convenience).
We have something like this . . .
4 - When there's trouble, new deploys can be
blocked centrally, and then
ops can revert to a previous version with a single button press.
. . . not this, I don't think, but doesn't sound too hard.
5 - Developers are good about "cleaning up"
code that was previously
protected by feature flags once the behaviour is standard. (HINT: this
is the part Flickr doesn't talk about in public... but as an open source
project with more visible dirty laundry, perhaps we can do better.)
This doesn't seem like it should be hard.
Anyway, it's something to think about once we get review and
deployment caught up. Maybe we should do daily deployment instead of
weekly, or even multiple-times-daily.