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 might create a little overwork.. > > What's the best thing to do? I'm a bit lost... > > Best regards, > Bobby > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today - it's FREE! > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > > > _______________________________________________ > Info-cvs mailing list > Info-cvs@gnu.org > http://lists.gnu.org/mailman/listinfo/info-cvs -- David A. Bartmess Software Configuration Manager / Sr. Software Developer eDingo Enterprises http://edingo.net _________________________________________________________________ jSyncManager Development Team (http://www.jsyncmanager.org) jSyncManager Email List (https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel) 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 Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs