«
»

Below I put some snapshots from Googl’e chrome release cycle presentation with some comments.

They originally planned this :

chrome release plan

And got a lot of troubles with this cycle like :

  • Long lived branches, which : Made supporting the branch (i.e. merging changes) more difficult as we drifted further from the trunk…
  • Unpredictable release cycles, with date targets we could never hit, and….
  • Engineers who were always in a rush to get their features into “this” release since we couldn’t make any promises about the schedule
    so they slightly change ( and simplify ) it to this 3 channel diagrams by making release shorter ( and reduce scope )

So they change traditional scheme to this one :

chrome release block diagrams

And then make it work in real life by cutting scope at release ( by disable features ) : Establish clear expectations (and engineering practice) to developers that any features not ready to ship at branch will be disabled (i.e. we only cut post branch, never add).

chrome release block diagrams

So it works fine for google guys and their rules are :

  • The branch point is the end of our development cycle
  • Features only get disabled post branch point
  • Features should be engineered so that they can be disabled easily (1 patch)
  • Only stability, security, and critical regressions can ever block a release

For me it’s looks fine for in-house development, but for me it’s big question how to apply same scheme for outsource development.

This entry was posted by Alexey Bokov on January 8, 2011 at 7:19 pm under programming, project managment, useful links. Tagged , , , , , , , , , , , , , , , , , , , , . You can leave a response, or trackback from your own site. Follow any responses to this entry through the RSS 2.0 feed.

Leave a Reply