Best practises for Configuration Management before build

[RupaL]

Hi,

As there are many experts in Configuration Management in this group I ask of this opinion here -
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.
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?

Regards,
Rupa

[Jim Hyslop-5]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rupa Bholanath Lahiri wrote:
> As there are many experts in Configuration Management in this group I
> ask of this opinion here - 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. 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.

I think that would be a bad idea. If I have a file checked out, it may
not be ready to be checked in. Forcing a check-in may actually break the
build.


> Is there any other way to
> ensure that developers have not inadvertently left out checking-in
> files which they should have checked-in?

You need to train and trust your developers. Automated processes can
only take you a limited way. How would you handle new files which were
added to the repository? CVS cannot tell whether a file which has not
been added to the repository is critical to the build. I'm not sure any
configuration management system could.

There are ways around this. First of all, train your developers in the
cardinal rule of team development: Never Break The Build!

The command 'cvs -n -q update' will show a list of files that have not
been checked in, and files that have not been added to the repository.
Get your developers in the habit of using that command.

Scrum, XP and other practices push the concept of continuous
integration. Boiled down to its simplest, that means you break your work
down into chunks that can be checked in frequently. Other developers in
the team refresh their working copies frequently as well. The definition
of "frequently" can vary from team to team, but is usually "not more
than a few days", and can sometimes be "several times a day".

You might also consider setting up a computer dedicated to performing
automated builds. There are many tools, such as Cruise Control, which
will automatically detect a check-in, refresh a local checkout and start
a build.

- --
Jim Hyslop
Dreampossible: Better software. Simply.     http://www.dreampossible.ca
                 Consulting * Mentoring * Training in
    C/C++ * OOD * SW Development & Practices * Version Management
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqbvdoACgkQLdDyDwyJw+NZLACgsO8OH3egL+O7rVHCrQl/JdzM
a8wAoIveqe0GX96+3H0DyESnv0uBIjCH
=msXo
-----END PGP SIGNATURE-----

[Bulgrien, Kevin-2]

> -----Original Message-----
> From: Rupa Bholanath Lahiri [mailto:RupaB_Lahiri@...]
> Sent: Monday, August 31, 2009 4:57 AM
> To: Info-cvs@...
> Subject: Best practises for Configuration Management before build
>
> Hi,
>
> As there are many experts in Configuration Management in this
> group I ask of this opinion here -
> 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.
> 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?
>
> Regards,
> Rupa

 
After watching the numerous threads appearing, I feel compelled to
recommend the best practice of reading what CVS is and what it is not
as described in CVS documentation:

http://ximbiot.com/cvs/wiki/CVS--Concurrent%20Versions%20System%20v1.12.12.1:%20Overview

For example:

CVS is not a substitute for management.
CVS is not a substitute for developer communication.
CVS is not a configuration management system.

The use of "CVS" in these statements is primarily a result of the
statements being made in CVS documentation.  The statements are
true even when the names of many other version control systems are
substituted.  Much of the prior discussion appears to indicate that
CVS is being asked to be something it is not.  This does not mean
the tool is inadequate.  It probably means something else is
inadequate.

In my opinion, it would be supremely foolish to attempt to examine
working copies.  The number of broken working copies, or ones that
have no relevance whatsoever to the current build on a server I
maintain vastly outnumbers those that are relevant to the current
build.  It is almost guaranteed that the project would be greatly
damaged (in many, many ways, not just the build) by attempting to
process working copies.

I suggest doing a search on "CVS Best Practices" for a great deal
of valuable information on this topic.

http://lmgtfy.com/?q=cvs+Best+Practices

---
Kevin R. Bulgrien
Design and Development Engineer

This email message is for the sole use of the intended recipient(s) and may contain General Dynamics SATCOM Technologies confidential or privileged information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message.

[Bob Proulx]

Rupa Bholanath Lahiri wrote:
> 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.

I would not want that.  I typically save and build incrementally.
There will be ten thousand tiny little saves and compiles before I am
ready to commit a changeset.

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

What are trying to protect against?

> Is there any other way to ensure that developers have not
> inadvertently left out checking-in files which they should have
> checked-in?

You should look at implementing an a Continuous Integration build.
Also developers should be able to run a clean checkout build and test
whenever desired.

  http://martinfowler.com/articles/continuousIntegration.html
  http://en.wikipedia.org/wiki/Continuous_integration

This should include both an automated build and an automated test
environment.  Get everything working.  Then keep a policy (usually by
peer presure from other developers) that the build is always ready for
release.  When the build and test is broken then only allow commits
that fix the build.  During development do not allow the build and
test to remain broken and if it is then make getting it fixed a
priority.

Bob

[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

[Paul Sander]

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

[Arthur Barrett]

Paul,

> > I do not want the benefits of continuous integration to act as a
> > disincentive to commit early and often
>
> I have still a different stance:  Never, ever discourage
> someone from checking in their code

Erm... I thought that was *exactly* my point.  


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

Tony and I and March Hare Software and lots of other people have put a
lot of effort and time into extended CVS to do these extra things for
people who need it.  Since 'traditional' users of CVS have no
desire/need for the overhead of these extra 'features' it got put in a
separate 'CVSNT' project.  

However recently I've been seeing anecdotal evidence that 1) many of the
people using CVSNT don't use or understand the extra capabilities, and
2) people who need/want those extra capabilities 're-invent the wheel'
rather than use CVSNT.  

It does make me wonder how effective the free software movement is if
noone looks for existing freely available source code before writing
their own solutions.

Can you offer any insight, from your own experience?

Regards,


Arthur

[Paul Sander]

On Aug 31, 2009, at 8:23 PM, Arthur Barrett wrote:

> Paul,
>
>>> I do not want the benefits of continuous integration to act as a
>>> disincentive to commit early and often
>>
>> I have still a different stance:  Never, ever discourage
>> someone from checking in their code
>
> Erm... I thought that was *exactly* my point.

Having re-read your post, I agree!

>
>> 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.
>
> Tony and I and March Hare Software and lots of other people have put a
> lot of effort and time into extended CVS to do these extra things for
> people who need it.  Since 'traditional' users of CVS have no
> desire/need for the overhead of these extra 'features' it got put in a
> separate 'CVSNT' project.
>
> However recently I've been seeing anecdotal evidence that 1) many of  
> the
> people using CVSNT don't use or understand the extra capabilities, and
> 2) people who need/want those extra capabilities 're-invent the wheel'
> rather than use CVSNT.
>
> It does make me wonder how effective the free software movement is if
> noone looks for existing freely available source code before writing
> their own solutions.
>
> Can you offer any insight, from your own experience?

More than likely it's because:
- These tools are aimed at programmers who like to invent things that  
they understand rather than learn about things they don't.  Certain  
value-add features like flow control are easy to understand whereas  
core version control oftentimes is not.  Or they write "something  
simple" without thinking about it, and it grows organically.
- People will prefer tools that they know over tools they don't.  With  
regard to version control, the tool they used in their prior job is  
almost always better than the current one, unless they happen to be  
the same tool with minimal refinement.  This plays a role if there's a  
conversion.
- People will prefer tools they've heard of over tools that are new to  
them.  The FSF and Gnu project have enormous name recognition, so  
people will look there first.  Also, I can go to any non-technical  
bookstore here in Silicon Valley and find 2 titles about CVS, 2 about  
SVN, and none about CVSNT.  People looking for version control tools  
will find CVS first for this reason, and will refine it themselves  
rather than convert to something else later (assuming it falls in  
their lap).
- Even if people have heard of both CVS and CVSNT, the similarity of  
the names (and in CVSNT's case its similarity to a well-known  
operating system), people draw the wrong conclusions about CVSNT and  
don't look at it seriously.
- The value-add features people need don't yet exist in software  
distributions and find no compelling reason to change when they  
eventually appear and stabilize.  This is what happened with submit/
assemble:  Nothing in the open source world fulfilled that function  
when I invented it in 1992.
- Sometimes custom software that solves 100% of a problem is more  
compelling than an 80% solution that can be refined to a 95%  
solution.  Even if the 80% solution can be refined to be a 100%  
solution, the nature of the hooks may make a refinement more  
cumbersome or fragile than custom programming.

[Arthur Barrett]

Paul,

> More than likely it's because:

Thanks for taking the time to make such a considered reply.  You raise
some interesting issues, but one very minor one I cannot resist
commenting further on.

> Also, I can go to any non-technical bookstore here in Silicon
> Valley and find 2 titles about CVS, 2 about  SVN, and none about
> CVSNT.  

I find it interesting that Tim O'Reilly, Founder and President of
O'Reilly & Associates, is also a founder of Collabnet - the people
behind funding SVN.

Regards,


Arthur Barrett