Re: Best practises for Configuration Management before build

I have still a different stance:  Never, ever discourage someone from  
checking in their code, regardless of its condition.  And building the  
latest checked-in code is worthless, because for the very reason that  
you don't know what its condition is.  It should be qualified in some  
way, either by having a user communicate a commit number or by running  
an additional procedure to declare a configuration (list of source  
files and version numbers) as being useful in a build.  This  
qualification can fire off a build automatically if necessary, or it  
can be collected and built on a predefined schedule.

The benefits of this are that users check in their work frequently,  
which if nothing else gives a reliable backup.  It encourages the  
users to use the version control system to share their code, rather  
than going out of process (e.g. tar files) to do their intermediate  
integrations.  It adds another layer of certification from the users  
that the code will indeed build.  It provides a method (that can be  
automated) to remove defective code from a broken build if the above  
safeguard fails.  It provides another hook for improving process  
automation and gathering metrics.

The drawback is that it requires the users to perform an extra step.   
The benefit of the extra step must outweigh the expense (i.e. hassle)  
of doing it.

One successful implementation of this has been discussed at some  
length in this forum.  Search the archives for "submit/assemble".   
That particular method provides a means to accumulate good changes  
(and back out bad changes) in a way that's repeatable with  
reproducible results.

In my implementation, defect tracking was tightly integrated with  
version control and the work flow.  This allowed us to correlate the  
actual versions of each file implementing a bug fix to the ticket, and  
to track the state of the ticket through integration, testing, and  
release, and to provide and automatic starting point for release  
notes.  It was *hugely* successful, cheap to implement and execute,  
and convenient for the users.

On Aug 31, 2009, at 6:11 PM, Arthur Barrett wrote:

> 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
>
>
>