[p4] Guidelines for codelines?
chuck.karish at gmail.com
Sat Nov 22 10:56:11 PST 2008
As several people have hinted the question here is the
design of the development process. Source control is an
implementation mechanism. I think of this as a data flow
problem: how does a change get from the developer's
workspace to the finished product with the least effort and
the fewest surprises?
What source control strategy works for your team depends
on their development style.
Here are three examples I've worked with:
1) Large team, six-month development cycle:
The rate of change was fast enough that working on main
produced frequent conflicts and build breaks. Solution:
Move all non-trivial changes onto development branches.
Use main only to receive integrates from development
branches. Allocate each team a two-day window every three
weeks to integrate their changes back to main. Fail to
re-stabilize main after your integrate and you have to revert
and wait for your next slot.
Pluses: The main code line never got too far from being
Minuses: Each team's tech lead had to spend several hours
every other morning integrating other teams' changes to their
team's development branch. Integrates to main were difficult
and stressful because they were so large; the integration
schedule was called the "Wheel of Death".
2) Small team, one-month development cycle:
All development was done on a development branch shared
by all developers. A tracking bug was assigned for each feature.
When it was time to release management chose which features
should be delivered and the developers integrated the changes
for those features to main, using the per-feature bug numbers that
were burned into the change descriptions.
Pluses: Simple branch model. Forward development rarely
interfered with releases. Developers found and resolved conflicts
Minuses: Some fiddlin was required on the release branch when
a file was modified for multiple features.
3) Large team, short release cycles:
This team used what they called an agile model in which everyone
worked on main. It was expected that main was always buildable
and always releasable. Breakage was flagged early by elaborate
pre-submit test servers and by continuous build-and-test daemons.
When it was time to begin a release cycle the source for the product
to be released was integrated to a release branch along with all of
the code on which it depended. If build, test, and QA on the branch
revealed any problems individual changes to repair the problems
were integrated from main to the branch.
Pluses: Developers don't have to maintain development branches.
Developers see and resolve conflicts early, which eliminates
painful large integrates at release time.
Minuses: Heroic measures are needed to keep the main code line
stable. This strategy worked only because the developers were
very smart and very responsible.
Chuck Karish karish at well.com (415) 317-0182
More information about the perforce-user