[Top][All Lists]

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

Re: best production practice?

From: bobby temper
Subject: Re: best production practice?
Date: Thu, 10 Feb 2005 16:16:30 +0000


Thanks for the answers.

I also agree with Jim, but it might be hard to convince content people that they have to go throught a staging first, for simple stuff. I will definitly do whatever i can, tho :).

Todd, what you're saying refers actually to what i'm asking: the production code is a checked out copy? (with the cvs folders, etc...). We already have a tag/branch procedure. The problem is, as now, we have a "cvs export" copy on production (and no cvs client on production either...). I'm wondering if it would be better to install a cvs client, and have the code being a "cvs checkout" copy. That way, we could do like you're proposing, with cvs diff. I'm actually just wondering if doing it that way has some drawbacks, vs doing a "cvs export/tar-gzip/scp" procedure.


From: Todd Denniston <address@hidden>
To: "Jim.Hyslop" <address@hidden>
CC: "'bobby temper'" <address@hidden>, address@hidden
Subject: Re: best production practice?
Date: Wed, 09 Feb 2005 17:18:36 -0500

"Jim.Hyslop" wrote:
> bobby temper wrote:
> > What i meant is that, we have the code running on a
> > production machine. Now
> > and then, that code gets changed, and sometimes, it's content
> > gets out of
> > sync with whats on production (ie. for example. someone edit
> > directly on
> > production, for a hotfix (i know this is bad, but fast for
> > changing a simple
> > text, link, etc...) and forget to do the changes in cvs.
> This practise *MUST* stop. Do whatever it takes to make it stop, otherwise
> one day you *will* get burned, and badly. "Changing a simple text" is no
> excuse.
> Problem solved.
I agree with Jim that you must stop the practice, as it "*will* get burned",
however Jim he still needs a method to DETECT violation of the integrity of
the production set, for as long as he is still working with his bosses to
get the policy fixed.

for detection, the following might do it.
if  you use tags to checkout for a release,
try `cd head/of/project/; cvs diff -rTagShownInThisSet`, if you get
anything, a violation has occurred, attempt to find the violator and use a
LART as necessary.

without tags just using `cvs diff ` might get you started, if you get
anything, a violation has occurred, attempt to find the violator and use a
LART as necessary.
Also without tags, it is time to talk to the boss and get the procedure
changed at least to indicate releases shall be made only from tags.

All Production releases should be if possible made by using your build
system, or a release build system, to do a checkout, tag if the checkout was
not of a tag, build & package, in this way you can be sure to be able to
recreate releases.
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
The opinions expressed here are not sanctioned by and do not necessarily
represent those of my employer.

FREE pop-up blocking with the new MSN Toolbar – get it now!

reply via email to

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