On Thu, Oct 21, 2010 at 8:18 PM, Neil Kandalgaonkar neilk@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.