Fog Creek Software
Discussion Board

Best practices

What are the best practices for updating code on the production server?


Jim Dandy
Thursday, February 20, 2003

Gnaw on your nails?

flamebait sr.
Thursday, February 20, 2003

Um, this is sort of like asking "What's the best way to write code?"  It's way too broad for any reasonable answer.

What sort of application are you developing?  How many people are on the development team?  Are you using automated testing?  What software's running on the production server (CVS?  RCCS?)?

Brent P. Newhall
Thursday, February 20, 2003

Have three stages (it doesn't necessitate 3
servers--think about VMWare) In the case of
a webserver:
1. Develop on a development site,

1.1. The site should point to a development
webserver, that acts as much as possible as
like the production server
1.2. It should have archives of production
source code checked out of a source-revision
system.. they should be organized and dated

1.3. You should make a copy of the
production code, communicate your intended
change, and ensure no one changes that code
in that folder (source revsion will help you
in this regard)
1.4. Give the links or executables for
testing to test
1.5. When testing gives you the okay, you
should copy the latest stuff into a "staging
2. Have a staging server.. this server
should be very much like the production
server.. it is not unusual for everyone in
development or web team to have access to
this server.. to drop in the code expected
to go on production without problem.

The staging server maybe just a place to
place files.. but a more advanced staging
server should practically ACT EXACTLY LIKE
PRODUCTION.. only no one knows about it
except your client and you.
2.1. Invite your clients to play around with
it.. check out new features before they go
production.. the same can work if your
clients have access to the public ip of your
development site.
3. Hey here's what pays the bill: The
Production Server
3.1 Only copy stuff approved and placed on
the staging server. Simple copy and paste.

-- David
Thursday, February 20, 2003

Here's what I found works for me....

1) Developer machines
Software-wise as close to production as you can make them.  This is where your work happens and your unit testing.

2) Development Build Environment.
Again, software-wise, as close to the production env as you can make it.  Builds and automated testing cycles should happen regulary and frequently ("frequent" means different things to different teams).  All developers should have access to this. 

3) Pre-production.
An identical environment to the production environment.  Code is installed here over the existing live version by the production staff (if you have them).  They follow the instructions on how to load version x+1 over version x.  This is the set of instructions they will follow when moving to production.  If something goes wrong, developers are asked to fix the instructions and/or code.  Start over each time that happens.  You should be able to revert this environment to any previous version without too much trouble.

4) Production.
Follow your Pre-production instructions to the letter.  Ideally, you'll do this at a non-peak time and hopefully have a developer there to help the production staff.  If anything goes wrong, revert back.  Come up with some kind of rules about when it is ok to publish.  For instance, we never published on Fridays or Mondays.

This can get expensive, but for a couple of places I've worked at, this is gone well.  Again, this is only what I have done, I'm not saying this fits for everybody. 

I think the goal here is to make the build and promotion process as regular and methodical as is possible.

Joe Blandy
Thursday, February 20, 2003

I think crossing your fingers is a better technique than gnawing your nails.

Having said that, the approach above looks pretty good to me, i've worked with a number of variations on this theme.

14 year contractor
Thursday, February 20, 2003

We recently adopted a set up similar to Joe's and were currently reaping the benefits.

The only problem is that while my work used to be high pressure fixing of last minute problems promotion through the various stages is not becoming a rather dull administrative task.

Sure the customers are a lot happier (they don't loose a days work every time we do a release like they used to) but I'm getting bored.  Who's more important here?

Ged Byrne
Friday, February 21, 2003

You might outsource the drag and drop to a

Li-fan Chen
Friday, February 21, 2003

Make that

Li-fan Chen
Friday, February 21, 2003

just overwrite whatever is there

Saturday, February 22, 2003

I've seen some people adapted other peoples schemes; so I came up with this simple 3 step scheme, from combining what others have said here:

1) cross your fingers
2) just overwrite whatever is there
3) Gnaw on your nails

This is pretty close to what it feels like doing your first go-live in a new environment :)

Saturday, February 22, 2003

*  Recent Topics

*  Fog Creek Home