[cvsnt] managing development/testing/release process

Arthur Barrett arthur.barrett at march-hare.com
Tue Jan 17 01:47:03 GMT 2006


Mark,

The recommendations of the developers of CVSNT for QA process, including
change sets and promotion are a part of the eBook:
http://march-hare.com/cvsnt/features/book/

For a CM process to be effective is must ensure the integrity of the
project/appliccation, make the evolution of that project more manageable
and the interrelationships clear.
http://march-hare.com/cvspro/faq/faq9.asp#9dd

Success at this will be different for differing companies due to
cultural differences and management goals.  It is my opinion that
implementing someone else's successful CM implementation almost
certainly dooms you to failure.  March Hare Software also offer CM
process design to support customers, there are many companies with an
excellent track record of this.

CVSNT has change sets (bug numbers) that are ideal for grouping changes
together and linking changes to jobs/defects.  We use a combination of
branches and promotion levels (a specific type of branch) to structure
the development, test and release cycle.

Finally, I strongly recommend that you design your CM process in a
non-tool centric fashion.   The old saying goes "when you have a hammer
everything looks like a nail".  Design your CM process (business
focused) and then ask "what tools can implement this process", or "how
would I implement this process in CVSNT"?

Regards,


Arthur Barrett

-----Original Message-----
From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf
Of Mark Johnson
Sent: Tuesday, 17 January 2006 11:01 AM
To: cvsnt
Subject: [cvsnt] managing development/testing/release process


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
_______________________________________________
cvsnt mailing list
cvsnt at cvsnt.org http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt



More information about the cvsnt mailing list