What are you using for that ticketing system?
--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 11:52 AM
To: [log in to unmask]
Subject: Re: [CODE4LIB] change management system
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
|