RE: Best practises for Configuration Management before build

[Arthur Barrett]

Rupa,

> As there are many experts in Configuration Management in this 
> group I ask of this opinion here -

I think that is a poor idea.

This mailing list is for the discussion and support of users of the CVS
version control system.  It is assumed that you have already:
1) looked at your business requirements and identified specific
measurable criteria to determine the success or failure of SCCM in
supporting those requirements
2) chosen a SCCM methodology that supports those requirements and 
3) determined that the SCCM methodology can be implemented in CVS
effectively

After you have implemented your SCCM utilising CVS and other tools you
should:
4) continuously measure the criteria to determine the rate of success of
the SCCM project
5) invest in your open source software by providing documentation, hours
of coding and/or financial support for the software
6) upgrading the software to keep with current features
7) continue to study industry best-practice for how SCCM is helping
other similar companies

A support mailing list is ideal for helping you implement your
methodology in CVS, but not at helping you determine the advantages and
disadvantages of methodologies that are unimplementable in CVS.  And any
SCCM oriented mailing list is unsuitable to helping you determine your
business goals.

A newsgroup more dedicated to generic discussion of SCCM is this one,
though like all mailing lists it has it's quirks:
http://groups.google.com/group/comp.software.config-mgmt/topics?lnk=srg

Note: some members do go on a lot about a web site 'cmcrossroads' -
please be aware that 'cmcrossroads' is is by no means objective, just as
any one person on this mailing list, or config-mgmt should not be
considered objective.  

> Before doing a build there may be a practice to check all 
> working copies if there are any files which are modified but 
> not checked-in.

You are right.  There may be.  There also may not be.  If you could tell
us about your business objectives, and your SCCM methodology and how
this fulfills your objective everyone would have a much easier time
assisting you.

> So one person may go around checking status of files in each 
> person's working copy and accordingly check-in files which 
> are not checked-in.
> Is there any other way to ensure that developers have not 
> inadvertently left out checking-in files which they should 
> have checked-in?

Jim and Bob have both tried to discourage you from this.  They have made
assumptions about your business obectives and your SCCM methodology and
specifically how it supports your business objective.  I will not try to
make such assumptions and instead take you at your word - you need to do
this.

Taking this position: Jim's answer that you need to train your workers
is also my best answer.

We had a similar requirement years ago, for audit compliance and
customer billing we needed to have all developers check in their work by
COB each Friday.  I trained my staff to do this.  Of course I trusted
them too, but that didn't mean I also didn't measure.  

I got a report of how much work (lines/files) was checked in for each
team member on Friday, and also an 'at' job ran on each PC late Friday
night to search for sandboxes and uncommitted files on each PC.  On
Monday I could 'see' if any team member had not followed procedures and
committed all outstanding work.  If I suspected a team member of
non-compliance I asked them about it, and generally they had either
forgotton (and were reprimanded) or had really forgotton (about a piece
of work or a particular sandbox) and were given some refresher training
on how to run and use the tools.

Jim and Bob have also both mentioned continuous integration.  I find
this hellish.  The theory is very good, and indeed our development team
use it, but I see it misused more often that used effectively.  I
believe that to be effective that continuous integration needs to be
coupled with promotion or maturity (change management), not checkin
(version control).  

I do not want the benefits of continuous integration to act as a
disincentive to commit early and often (which is good for documentation,
co-operation, billing, project management, etc).  So I encourage commit
early and often, and then promote changesets when they are ready to
build, and then re-promote as often as necessary.  This is why CVSNT,
ClearCase, Dimensions, CM Synergy all have support for user defined
change sets and merge-by-chageset (which SVN, CVS, Git, VSS do not).

So I hope from my comments that you can see that the key to the answers
is not command 'x' or tool 'y', but rather an understanding of your
business requirements and how your SCCM process is expected to address
them.  If your business requirement is to improve your billing for
hours/lines of code, then your SCCM process needs to facilitate people
committing early and often and assigning those commits to customer
projects and counting the hours/lines.

Remember: SCCM is an overhead.  Or to put it more bluntly, SCCM is a
cost.  The reason why so many people do not like version control is that
usually the costs outweight the benefits (Susan Dart previously of the
Carnegie Mellon Software Engineering Institute did some studies to
document this I believe).  CVS may be 'free' but SCCM will cost you - it
will cost you every hour of every day.  Investing some cold hard time
(and probably cash) in good analysis of your business requirements, of
SCCM methodologies, project management and finally tools and software
will pay off in ensuring that your final system delivers measurable
benefits that outweight the costs. 

Finally - I think that the tool 'Cruise Control' mentioned by Jim is (at
least partially) responsible for an enormous amount of wasted time and
effort and unsatisfactorily implemented SCCM systems.  Why?  Because it
is implemented poorly (I usually come across it at customer sites
'polling' CVS for changes even 2 or 3 seconds) and does nothing to
actively encourage people to think about good or effective SCCM. 

Regards,



Arthur Barrett