info-cvs
[Top][All Lists]
Advanced

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

Re: Best practises for Configuration Management before build


From: Jim Hyslop
Subject: Re: Best practises for Configuration Management before build
Date: Mon, 31 Aug 2009 08:11:06 -0400
User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812)

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




reply via email to

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