 |
 |
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