|
| From: | Paul Sander |
| Subject: | Re: braches best usage |
| Date: | Tue, 22 Feb 2005 00:19:26 -0800 |
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, address@hidden 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 tomerge to, just to check the viability of their changes. A cruisecontrolsystem 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 fromother 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 SCMto 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 address@hidden 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 address@hidden http://lists.gnu.org/mailman/listinfo/info-cvs
-- 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, writer.
| [Prev in Thread] | Current Thread | [Next in Thread] |