[slightly OT] Re: best production practice?

[Matthew Herrmann]

Hi,

A pragmatic way to do it is to do put updates on the server using:

cvs co -rRELEASE_20 proj

Then, ... To make a quick fix, get the latest source code on your dev
environment, bump up the version number in your dev environment (even on
your local machine running apache/iis/whatever). Tag it using cvs rtag, then
do an rdiff to examine changes. Go through any change procedure (which for a
single textbox caption should not be too onerous).

Then, update the production server using:

cvs up -rRELEASE_21

It shouldn't be too hard. The key is to make sure there is an easy place to
edit the site in a dev environment. So, for a start -- don't version control
the database config files or you'll have pain where prod and dev are
fighting over which database connection to use. People can then go up and
fiddle with the labels in 5 seconds -- but it doesn't show up to customers
until you hit the big button.

If you make it easy for people they shouldn't complain. You definitely want
a release controlled environment, but at the same time, a system which
involves lots of work just to change a single line of code is problematic
and needs to be automated at some level (the grunt work, not the decisions,
that is).

Another thing -- don't be shy about creating versions: there's no problem
with making several hundred versions which include nothing more than minor
fixes to things here and there. Given that, no prob in making a script which
fetches all tags, gets the highest release number, tags the next increment,
and spits out a diff and patchset onto the desktop. People will love you for
it. :)

My 5 new/250 old francs,

Cheers,

Matthew Herrmann
---------------
Far Edge Pty Ltd
http://www.faredge.com.au/

Level 6, 35 Chandos Street
St Leonards 2065
Ph: +612 8425 1400 
 

-----Original Message-----
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=Se
arch
http://www.google.com/search?hl=en&lr=&q=%22release+management%22&btnG=Searc
h
http://www.google.com/search?hl=en&lr=&q=%22release+management%22+CVS&btnG=S
earch
http://www.google.com/search?hl=en&lr=&q=%22release+management%22+%22best+pr
actices%22&btnG=Search
http://www.google.com/search?hl=en&lr=&q=%22release+management%22+%22best+pr
actices%22+cvs+-pvcs&btnG=Search
http://www.w3.org/OOP/9606_Workshop/submissions/31-W3COMG.html
http://www.wipro.com/prodesign/focusareas/complatforms/complatpcasestudy8.ht
m
you get the picture right?
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter