On 9/20/10 8:23 PM, MZMcBride wrote:
From my perspective, the initiation of branching has slowed down code pushes dramatically. This may be a false correlation I'm drawing, but I don't think so.
I do not know enough about the history at Wikimedia to say, but in general, that's why people go to a branching system in the first place -- to introduce a buffer between development and production.
Has there been any discussion about killing the branch system altogether?
After much experience with branch-based deployment systems -- including designing and implementing some for largish web properties -- I now think branches are a bad idea for most website development.
Every time I have worked with a system designed to isolate streams of development (dev, test, production) it has proven to be a net negative. Critical bugs are harder to fix, big refactorings are harder to put into production.
Flickr argues that the entire concept of "releases" is based on an outmoded notion of shrink-wrapped software. For websites, you don't want a system that tries for unattainably perfect releases. Instead you want a system that makes deployment easy, and recovery from problems routine. Flickr deploys 10+ times a day, and does a revert of a deploy probably once a week.
Check out this presentation, which explains the radically different development and deployment practices at Flickr:
http://velocityconference.blip.tv/file/2284377/
There are pros and cons to this approach.
It's not entirely appropriate for us because we do in a sense have a shrink-wrapped product -- MediaWiki -- and its releases ought to be stable.
Also, Flickr relies on the entire team being experienced and careful; they can't afford even one bad or naive developer.