[p4] Implementing mainline model with build promotion

[Jeff Grills]

One thing that can greatly change your promotion strategy is whether or
not you need to support multiple builds in the field.  If you're in the
nice situation of controlling your customers (which may be your own
internal company, one of the few ways that happens) and can force them
to upgrade at the same time, you can get by with something a lot more
simple than you could otherwise.  I'm a big fan of simple.  So I'd
propose something like this:


                                    
Main --------------------------------------
       |                            | (cycle repeats here)
       v                            v
Test --------------------------------------
                    |     |     |
                    v     v     v
Release -----------------------------------

Main is where a lot of development occurs, and may be unstable.  It gets
integrated to test occasionally, where it gets built and worked over by
QA.  Fixes occur in test and test is rebuilt.  Fixes in test must be
integrated back to main (not shown in the above ASCII graphic to keep it
simple).  Once QA is happy with what is in test, it gets integrated to
release and pushed out to customers.  Issues may be found in the field
that require another couple iterations in test, which are then
integrated to release when they're approved.  If a new version has
already been created in test and something super critical happens in the
field, it can be repaired in the release branch, tested, and pushed out
again.  Changes made to release in this manner must be pushed back to
test and then again through to main (again, not shown in the ASCII
graphic).  If your deployment vehicle is perforce itself, you might want
a deployment branch that hangs off release for that class of emergencies
- hopefully you'd never need it, though, so I'd omit that branch unless
it proves to be necessary (although I'd argue it should never be
necessary - you should fix whatever upstream problem is causing you to
release buggy builds).

If you want a more stable main branch, you can do development in
branches that occur before main (which we can call development1 ..
developmentN), and QA those changes before they get pushed to main.
Hopefully, then, the push from main to test only has to deal with issues
that are caused by the interaction the multiple branches feeding into
main.  You could even avoid that issue by pushing the latest main into a
development branch and QA'ing that before pushing that development
branch into main, although then you can really only consider pushing one
development branch at a time into main since the development branch has
to have the current main before it begins test.

If you need to support multiple releases in the field at the same time,
you need to retain their state so that you can do critical bug fixes to
any version that may be live.  You could construct a test and release
branch pair per version that is going out to the field, which I would
base off of the main branch.  That clearly becomes a lot more expensive
to manage than a single test/release pair.

j



-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Stephen Nesbitt
Sent: Tuesday, June 26, 2007 12:32 PM
To: perforce-user at perforce.com
Subject: [p4] Implementing mainline model with build promotion

All:

I'm hoping the collective wisdom of the group can provide me with some 
insight on how to implement build promotion within the environment of a 
mainline branching model.

Here's the basic branching scenario:

[main]-----------------------------------------------
             |                              |
             [july release]-----------------|------
                                            [
                                            |[august rel]-----------


[main] is owned by cm and serves as the primary parent and "latest
best". 
The [july release branch] supports continuous integration with frequent 
dev builds and less frequent - twice a day - formal builds delivered to 
QA. 

My question is on what branch should the QA build occur? on the [july 
release branch] or on [main]? Or - to say it another way - does the 
promotion from the july effort to main occur before or after the build.

My gut tells me to perform the QA build on the [july release]. Once QA
has 
accepted that build the promotion occurs (using the changelist on which 
the QA build was based). This is a copy merge and - theoretically - main

should be identical to the july effort at the time of the QA build 
changelist.

That's the catch I am concerned about. The actual QA build - which might

get promoted to release was executed against, say, changelist #1 on the 
july release branch. For reproducibility purposes, however, the release 
is marked as, say changelist #2, on the main branch. I am asserting that

changelist #2 on main is identical to changelist #1 on the july release 
development branch.

So, does anyone do something equivalent? Am I completely out to lunch
here 
and just asking for trouble? Any thoughts, hints, opinions advice? How 
are others handling the case of development on a branch with builds
which 
are promoted to various statuses?

Thx!
-- 


Stephen Nesbitt
CM Architect/Lead
The Cobalt Group
snesbitt at cobaltgroup.com
x8271
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user