>--- Forwarded mail from [EMAIL PROTECTED]
>we have been struggling for several months now trying to understand how to
>use CVS in an integrated development environment, i.e. development, QA, and
>production.
>- should development commit changes to the main HEAD or in a development
>"branch"?
>- does a QA department have their own branch or do they use the development
>branch?
>- how are revisions moved from development and QA? do you merge to and from?
>- should versions be tagged when they are released or tagged every step of
>the way?
>the greatest help would come from someone explaining exactly how their
>company uses CVS. any help would be greatly -- GREATLY -- appreciated.
>--- End of forwarded message from [EMAIL PROTECTED]
If I understand your question properly, you're asking how various shops
perform the hand-off from development to Q/A. You seem to recognize that
the stuff Q/A wants is not necessarily the latest work completed by the
developers.
One method that I've seen used very successfully with CVS is what I call
the release/integrate or submit/assemble method, which is a type of change
control. The way it works is that the developers identify sets of files
(call them "changes") that are eligible for the next build. These changes
accumulate between builds, and are used by the build team (in combination
with the contents of the prior build) to assemble a new build area. The
result is compiled and supplied to Q/A for testing.
If the build fails, individual changes can be removed, and the updated
build area is cleaned and recompiled. This recovery can sometimes be
automated (depending on the nature of the build and how much it can be
modified to accomodate this type of analysis). It helps a lot to have
the build process make multiple passes (per subsystem, as opposed to the
traditional recursive Make that builds tools then headers then libraries
then executables) and track which files are created during each pass,
the build process never modifies any source file, and the build process
records sufficient information in the logs to identify specific failures
and trace them back to source files. It's also helpful if the build
process records any files used by an include mechanism by the source
files identified to contain errors.
