Re: best production practice?

[bobby temper]

Hello,

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.

Regards,
Bobby

> 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! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/