Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
I am looking for some help, suggestions, discussion regarding the general Development/Testing/Release process as it relates to cvs, and branches and/or tags. I am being asked by my QA department to implement a process, and what I would like to do is design something based on convention and best practices, rather than just dive in and create a mess. I don't expect anyone to say "here...do this", but I would appreciate suggestions, and especially direction to good resources on the subject. We currently develop in the main trunk, and run both continuous builds, and periodically QA builds out of the main trunk. We branch when we release a version (or at least create a branch tag) to allow modifications for future patches to occur on the branch, while also allowing development for the next version to continue on the main. This works well as long as the group is small enough, and it stays simple. We are starting to outgrow this. We would like something more like this: Developer(s) for a defined change set start with current "approved" code base, and make changes, committing them back into the repository, but in such a way that they are identified as not part of the approved code base. This branch or label set would need to be able to be retrieved and built. When the specific change set is ready, it would be prompted to QA, where it can be tested (integrated with the approved code base, but isolated from other changes-in-progress), and if successful, prompted to the "approved" state, and now part of the approved code base. This would need to account for multiple scenarios like this running concurrently, without interfering with each other. I realize this can possibly be accomplished with branches and/or different sets of labels. What I am looking for is the simplest approach which can be easily understood and followed by development, QA, and of course configuration management (me). I realize this is not a small question, but anyone willing to offer feedback, or point me to an appropriate thread or book would be appreciated. Thanks, Mark Johnson