Harvard University Library does separate OPS and DEV.

Only OPS have write permissions on production boxes, and we have a "change 
control" procedure that is implemented through a series of scripts.

In addition to Development and QA instances of applications, we have 
implemented a Staging server for releases. The staging server is configured 
identically to the production servers, with access to production databases. 
By release I mean deployment of a software update that has already been 
QA'ed in a QA environment writable by developers (QA'ed by library project 
staff who play that role, we do not have a formal QA group).

Developers run a "stage" script to check code out of source control and 
build on the staging server. After a stage, limited testing is done, by the 
developer usually, on the staging server to confirm that the QA'ed software 
seems to operate properly with production database and file system mounts. 
Once that is done, the developer runs a "publish" script to let the 
operations staff know that the release is ready for deployment. Operations 
runs a "move2prod" script to deploy the software, typically to multiple 
production servers. They have a "rollback" script available should 
something go wrong in the deployment.

For tracking of this process, and for software bug tracking, we use good 
'ol bugzilla. Before a publish, a bug is entered in an Operations instance 
of bugzilla, for the "change control" product. All steps in the release are 
tracked as updates to the bug. A little bit of a distortion of what 
bugzilla was designed for, but its working well for us...

- Randy


At 08:55 AM 2/11/2010 -0800, Walker, David wrote:
>Thanks to everyone who responded.  The comments have been very helpful!
>
>Is anyone using RT? [1]
>
>Also, I'm curious how many academic libraries are following a formal 
>change management process?
>
>By that, I mean: Do you maintain a strict separation between developers 
>and operations staff (the people who put the changes into 
>production)?  And do you have something like a Change Advisory Board that 
>reviews changes before they can be put into production?
>
>Just as background to these questions:
>
>We've been asked to come-up with a change management procedure/system for 
>a variety of academic technology groups here that have not previously had 
>such (at least nothing formal).  But find the process that the "business" 
>(i.e., PeopleSoft ) folks here follow to be a bit too elaborate for our 
>purposes.  They use Remedy.
>
>--Dave
>
>[1] http://bestpractical.com/rt
>
>==================
>David Walker
>Library Web Services Manager
>California State University
>http://xerxes.calstate.edu
>________________________________________
>From: Code for Libraries [[log in to unmask]] On Behalf Of Mark A. 
>Matienzo [[log in to unmask]]
>Sent: Thursday, February 11, 2010 5:47 AM
>To: [log in to unmask]
>Subject: Re: [CODE4LIB] change management system
>
>I'm inclined to say that any sort of tracking software could be used
>for this - it's mostly an issue of creating sticking with policy
>decisions about what the various workflow states are, how things
>become triaged, etc. I believe if you define that up front, you could
>find Trac or any other tracking/issue system adaptable to what you
>want to do.
>
>Mark A. Matienzo
>Digital Archivist, Manuscripts and Archives
>Yale University Library