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 [code4...@listserv.nd.edu] On Behalf Of Mark A.
Matienzo [m...@matienzo.org]
Sent: Thursday, February 11, 2010 5:47 AM
To: CODE4LIB@LISTSERV.ND.EDU
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
