[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Best practises for Configuration Management before build

From: Paul Sander
Subject: Re: Best practises for Configuration Management before build
Date: Mon, 31 Aug 2009 18:40:35 -0700

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:


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

After you have implemented your SCCM utilising CVS and other tools you
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: 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

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.


Arthur Barrett

reply via email to

[Prev in Thread] Current Thread [Next in Thread]