[thelist] Versioning best practices

[Scott Dexter]

> >  
> > We're considering using a development server, staging server and
> a
> > production server and moving new builds from staging to
> production once
> > a week.

Separating out the dev/staging/production is a Best Practice. Do it
and sleep well. However, moving code from staging to production
should be on the code's schedule, i.e. if there's nothing to move,
don't do an unnecessary push. (I hope that's obvious, but ya never
know). There are some schools of thought (XP) that advocate daily
builds (on DEV!), but I'd say that depends on the velocity of
development, and how secure you are in your developers to clean their
plates at the end of every day (and how well test-driven development
has taken hold). Just keep a watchful eye on the goings on, and tweak
as needed.

Separating the environments allows you to implement checks and
balances, audit trails, proper testing and release policies, etc etc.

But as someone else mentioned, the biggest item is consistency. From
how the three servers are built and maintained (shoot for
/identical/), to how the code pushes are done to who authorizes the
releases to how bugs are handled, etc etc. Release Management is a
/huge/ arena, and lots of companies (and people) make a living
expousing their flavor of "Best Practices," but if you hone a
consistent, repeatable process, and stick to it (and have your people
live by it and not hold it against you ;)), that's what works.

If you have MS products in house already, check into (though it has
its quirks) Visual SourceSafe. Along with the repository end of
things is a process to release ("deploy") code. There are also a
number of public license products: CVS, Bugzilla (not a repository,
but a tracking system), SourceForge even. 

Anyhoo, the message here is consistency. Process. Consistency. :)

Enjoy, and good luck--

sgd