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
"submit/assemble".
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, [EMAIL PROTECTED] wrote:
What I've done in this scenario in the past is to create an
"integration"
branch. NOT a QA branch, but one which the developers only are allowed
to
merge to, just to check the viability of their changes. A cruisecontrol
system runs a continuous build on the integration branch, to do both
of 1)
test the build to make sure no one breaks it syntactically, and 2) run
the
junit or other automated tests to ensure they didn't break it
logically.
This isn't much of an overhead, and if the developer does any testing
at all
on his box, using his copy of the integration branch, the results are
almost
always good to go to QA (merged to the QA branch for the next QA
build).
Note that the developers should merge THEIR branch directly to the QA
branch
(or the SCM admin should) to avoid introducing non-tested code merged
from
other developers.
It's fairly simple to setup the scripts to allow them to do this
without much
hassle, and it makes for an even better chance at passing QA's testing
if it
goes through these steps. I've always been able to (after a proving
period)
convince the management it's worth a minor hassle on the developer
and/or SCM
to get this much done...
On Monday 21 February 2005 05:50 pm, bobby temper wrote:
Hi,
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:
how can
we make that code go to QA? If we merge the code from the branch to
the
trunk, before doing QA, what if that code cannot go to the next
release?
I was thinking of creating a QA branch, and have everyone wanting
their
code to be QAed needs to merge their code to that branch. But then
again,
this mi
