[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: braches best usage
Re: braches best usage
Tue, 22 Feb 2005 00:19:26 -0800
I've seen a couple of other methods used successfully that let
developers share the same branch with integration and QA. These can be
used in isolation or in combination to advantage, and they don't
preclude developers from creating their own private branches. A strong
point of these methods, due to the branch sharing artifact, is that
merging is avoided.
The first method is to implement a hand-off mechanism from developers
to integration. Only those sources that have been handed off are
eligible for integration. This can be done with tags and some
bookkeeping, or by passing around lists of files and version numbers.
Normally hand-offs would be queued and handed-off files would be used
to populate a build area. Depending on the sophistication of the
implementation, changes can be backed out, overlapping dependencies can
be checked and processed appropriately, and version numbers can be
verified to increase monotonically. A similar hand-off can be made
from integration to QA, containing the aggregate of developer hand-offs
since the last hand-off to QA. One implementation of this has gotten a
lot of discussion in this forum over the years; search the archives for
Another method is to keep a queue of builds that are shared across the
entire cycle. Builds are done once and their results become immutable.
As a build is proven at each stage of the process, it gets promoted to
a higher level of confidence. Each stage also has a range of choices
in which to begin their qualification. Old or bad builds get removed
while good builds are retained and are eventually shipped. The dirq
tools located at http://www.wakawaka.com/source.html can assist with a
build promotion system.
A third method involves dedicating a branch to each stage of the
process. For example, have a development branch (or private feature
branches), an integration branch, and a QA branch. Changes are merged
from development to integration to QA, but in such a way that there are
never any merge conflicts. It requires a certain amount of discipline
on the part of the engineers because they must first merge from
integration to development and resolve conflicts in their own
workspaces, then commit and push the results back to integration. This
method has the advantage that any change, if it's tagged, can be
removed from the integration and QA branches by way of reverse merging.
There are potential race conditions but they can be alleviated by
careful assignment of ownership, a reservation system, making sure the
target versions are the latest on their respective branches, or even
just good project management. Note that in CVS, if you use a
development branch then it should be the trunk. If you use private
feature branches then you make the integration branch be the trunk.
And you will likely find that you need some kind of access control to
keep people from modifying the integration and QA branches directly;
allowing conflict resolution and other direct changes on the
integration and QA branches has a way of breaking automated merges and
reverse merges at a later time.
On Feb 21, 2005, at 8:39 PM, address@hidden wrote:
What I've done in this scenario in the past is to create an
branch. NOT a QA branch, but one which the developers only are allowed
merge to, just to check the viability of their changes. A cruisecontrol
system runs a continuous build on the integration branch, to do both
test the build to make sure no one breaks it syntactically, and 2) run
junit or other automated tests to ensure they didn't break it
This isn't much of an overhead, and if the developer does any testing
on his box, using his copy of the integration branch, the results are
always good to go to QA (merged to the QA branch for the next QA
Note that the developers should merge THEIR branch directly to the QA
(or the SCM admin should) to avoid introducing non-tested code merged
It's fairly simple to setup the scripts to allow them to do this
hassle, and it makes for an even better chance at passing QA's testing
goes through these steps. I've always been able to (after a proving
convince the management it's worth a minor hassle on the developer
to get this much done...
On Monday 21 February 2005 05:50 pm, bobby temper wrote:
I have a point that confuses me about branches usage.
We have developpers that want to isolate themselves from the trunk, by
creating a branch.
After that, the code needs to go to QA. This is where i'm confused:
we make that code go to QA? If we merge the code from the branch to
trunk, before doing QA, what if that code cannot go to the next
I was thinking of creating a QA branch, and have everyone wanting
code to be QAed needs to merge their code to that branch. But then
this might create a little overwork..
What's the best thing to do? I'm a bit lost...
Express yourself instantly with MSN Messenger! Download today - it's
Info-cvs mailing list
David A. Bartmess
Software Configuration Manager / Sr. Software Developer
jSyncManager Development Team (http://www.jsyncmanager.org)
jSyncManager Email List
But one should not forget that money can buy a bed but not sleep,
finery but not beauty, a house but not a home,
medicine but not health, luxuries but not culture,
sex but not love, and amusements but not happiness.
Info-cvs mailing list
Paul Sander | "When a true genius appears in the world, you may
address@hidden | know him by this sign: that all the dunces are in
| confederacy against him." -- Jonathan Swift,