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.
--
Neil Kandalgaonkar |) <neilk(a)wikimedia.org>