 |
 |
Hi - it's primarily designed for things we develop. We have a Change Management ticketing system following ITIL principles that tracks change requests for anything in production, from working apps we've developed, to III, to the public infestations, and even account adds/moves/changes. Tickets from this system will sometimes be moved into JIRA when they ask for a change to something we've developed. D -----Original Message----- From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Walker, David Sent: Thursday, February 11, 2010 9:49 AM To: [log in to unmask] Subject: Re: [CODE4LIB] change management system Hey Declan, Does that process only apply to applications you develop yourselves? How about the Innovative system, or open source applications developed elsewhere? --Dave ================== David Walker Library Web Services Manager California State University http://xerxes.calstate.edu ________________________________________ From: Code for Libraries [[log in to unmask]] On Behalf Of Fleming, Declan [[log in to unmask]] Sent: Thursday, February 11, 2010 9:31 AM To: [log in to unmask] Subject: Re: [CODE4LIB] change management system Hey Dave! We need to go grab lunch sometime... We use JIRA for our bug tracking and tracking feature requests (to some extent). UCSD Libraries IT has a strict Development/Operations split, with a weak Test phase in the middle - weak because I don't have a QA or config manager, and I'm teaching academics the processes I learned while working in the software industry. We follow a 2 week deploy process where Dev can submit any packages to Ops every other Friday. On Monday or Tuesday (depending on what's on fire in Ops), these packages are then staged to a Test server that only Ops has admin privs on. If the project people have a test plan, they have the rest of the week to say whether the package passes or not. If yes, we roll the package to production on the next Monday or Tuesday. If not, we kick the package back to Dev and they do their fixes and unit tests and wait for the next cycle. This system keeps production (and thus, customers) from being thrashed with not-quite-ready builds. There is a lot of natural tension in our system, especially with the lack of a QA manager, and most of the config management being done by Ops. We require a high degree of communication between the Ops and Dev managers on dates, test pass/fail conditions, code quality, process mgt, etc. This can be a challenge as Ops and Dev have different missions at times. D -----Original Message----- From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Walker, David Sent: Thursday, February 11, 2010 8:55 AM To: [log in to unmask] Subject: Re: [CODE4LIB] change management system 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