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...
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? 
>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.
>Library Web Services Manager
>California State University
>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