Professional Documents
Culture Documents
Chrome Release Cycle 12 16 2010 PDF
Chrome Release Cycle 12 16 2010 PDF
Our Philosophy
Think of any major website, even the fancy Web 2.HTML5
ones... do they have version numbers?
We took the same approach to our client software as an
online web service.
That is... we treat releases as a means of getting features
out to users and not goals in and of themselves.
It's about flow.
Primary Goals
Shorten the release cycle and reduce the life span of a
branch (make merges easier)
Make releases more predictable and easier to scope
Reduce the strain on the entire team
Good
Bad
Block diagrams
The pace of the schedule sets the boundaries for the amount
of work that can be completed.
It's important to have specific points in the schedule to
review features and cut scope.
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).
Plan to Pitch
Reached out to the various cross functional groups on the
Chrome team, who would all be impacted, before
approaching our executives.
Engineering, QA, Product, Marketing, Support,
Localization, Security, etc...
There were a lot of concerns to address, but the exercise
forced a lot of thought on the implications of the schedule
change.
It took time, but it made the pitch easier to present to the
leadership and the rest of the team.
Concerns
Would large feature development still be possible?
"Yes, engineers would have to work behind flags, however
they can work for as many releases as they need to and can
remove the flag when they are done."
Can the engineers keep up?
"Their pace won't need to change, since features can be
disabled there should be no milestone pressure, things ship
when they are ready."
What would a world look like where we didn't base our
marketing on releases?
"We market features, not releases."
And so we implemented it
11 week overlapping schedules.
Key Lessons
Conclusion
Speed alone isn't always the right answer, it's about keeping
things running smoothly.
For us, scope was getting in the way of that goal.
We basically wanted to operate more like trains leaving Grand Central Station
(regularly scheduled and always on time), and less like taxis leaving the Bronx
(ad hoc and unpredictable).