info-cvs
[Top][All Lists]
Advanced

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

[slightly OT] Re: best production practice?


From: Todd Denniston
Subject: [slightly OT] Re: best production practice?
Date: Thu, 10 Feb 2005 12:51:53 -0500

bobby temper wrote:
> 
> 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.

OUCH.
OK, I am sometimes considered an SOB by those that work with me when it
comes to releases, but it sounds like it is time for 
1) the production machine to have the number of user names reduced to
root+otherinstalleddefaultusers & projectadmin

or
2) the production area locked down so only root & project admin can make
modifications. 

If I was the person who had to answer "what is in the production machine
today?", I would make three documents 
document 1) I, [my name], have permission to [insert lock down method] the
production [machine|area], and anyone who subverts that gets [insert
appropriate punishment]. This will be implementing an industry best practice
[site sources (besides/in addition to Jim & me)][1]
________boss_signature_here____Date.

document 2) I, [my name], am not responsible for the content of the
production machine even though it has been suggested to customers we have
someone in that job. ________boss_signature_here____Date.

document 3) I, [my name], have informed [boss's name] that the production
[machine|area], is out of control, and anyone with [insert level of access]
can modify it at will and the changes will not be recorded in version
control, so we can not track who or when a change was made. I, [my name],
have informed [boss's name] of the following method for correcting the
situation and been denied. [insert method(s) here]
________boss_signature_here____Date.

I would then take them to my boss, and indicate s/he should pick one and
sign it. BTW I am camping as physically close to my boss's person as is
possible during working hours until one is signed. :)

1 gets you the ability to fix the problem.
2 indicates it should not be your butt that is the one to kick if there is a
problem with what is on the production machine/area.
3 indicates the boss's butt is the one to kick _if/WHEN_ there is a problem
with what is on the production machine/area.
If the boss refuses to sign any of them... 
1) email the concerns and fixes to the boss, and print a copy.
2) keep a note book recording the documents, the email & when they were
presented.  
3) consider if it is worth going to the boss's boss with the notebook.

Sometimes you just have to drop back to these kind of strong arm tactics to
get what is needed, and keep your own head.
if the boss picks #1 (this is what you hope for), you can implement the
corrective change ... tell the complaining people "the boss indicated it
should be done", and (to relieve some of the stress you just applied to
his/her arm) tell the boss to tell them "we are implementing industry best
practices...(pause to see if they complain more, if so finish with) you will
work with it. If you do not feel it is best practice, document why, and site
your sources." before they show up in the bosses office.

> 
> Regards,
> Bobby
> 
<SNIP>

[1] you could start by searching the mailing list for other people dealing
with release management
http://www.cmcrossroads.com/bradapp/acme/
http://www.cmcrossroads.com/bradapp/acme/#BuildRepro
http://www.cmcrossroads.com/bradapp/acme/repro/SoftwareReconstruction.html
http://lists.gnu.org/pipermail/info-cvs
http://www.google.com/search?hl=en&q=release+managment&btnG=Google+Search
http://www.google.com/search?hl=en&lr=&q=%22release+managment%22+CVS&btnG=Search
http://www.google.com/search?hl=en&lr=&q=%22release+management%22&btnG=Search
http://www.google.com/search?hl=en&lr=&q=%22release+management%22+CVS&btnG=Search
http://www.google.com/search?hl=en&lr=&q=%22release+management%22+%22best+practices%22&btnG=Search
http://www.google.com/search?hl=en&lr=&q=%22release+management%22+%22best+practices%22+cvs+-pvcs&btnG=Search
http://www.w3.org/OOP/9606_Workshop/submissions/31-W3COMG.html
http://www.wipro.com/prodesign/focusareas/complatforms/complatpcasestudy8.htm
you get the picture right?
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter




reply via email to

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