Bill,
Sounds like you do exactly what we do for some of our software support
groups. We added a few new active status values and built some scrips to
add two new functional processes; “Review & Approval” and “QA WorkFlow”.
WE modified the tabs in the “Modify Ticket” pages to display these new
options. They work like this:
1) A ticket is received(email)/created in the "Requests" Queue. This
queue is used to collect requests that may/may not be approved and moved
to an appropriate support queue. A notification is sent to the Requestor.
2) Ticket Status is changed to “pending rv” (new “TAB” on page). The
ticket is evaluated and investigated and the result (upon completion of
evaluation) the Ticket Status is changed to “rejected” (not approved) or
“rq approvd” (approved. new “TAB” on page). If “rejected”, a comment is
required to explain why and that is included in the notification
tamplate. A notification is sent to the Requestor.
3) The ticket is moved to the appropriate support queue. the ticket can
now be opened and worked on. If several sub-tasks are required, they are
created as “Children” tickets. If other tasks are required from other
groups, “depending on” tickets are created in those queues. A
notification is sent to the Requestor AND new Queue Admin (AdminCc).
4) The new Queue Admin assigns the ticket to a developer/owner.
5) The ticket status is changed to “open”. The ticket is worked on from
“developing specs” to “system testing”. These steps are indicated using
a Custom Field called “Work-Status”. A notification is sent to the
Requestor.
6) The ticket status is changed to “pending qa” (new “TAB” on page).
Due to new scrips, RT automatically changes the new Custom Field “QA
Approved” value to “Not Started” and the CF “Work-Status” value to
“Acceptance Testing”. A notification scrip is sent to the Requestor AND
the QA Approval Group. The QA Test scripts are attached to the notification.
7) The QA Approval group tests the work product. When complete, anyone
in THAT group only (CF rights) changes the value in the CF “QA Approved”
to either “Yes” or “No”. Due toi new scrips, RT automatically change the
ticket status to “stalled” (if CF QA Approved is “No”) or to “qa
approvd” (if CF QA Approved is “Yes”). A notification scrip is sent to
the Requestor, Owner, AdminCc, AND the Migrator/Promoter. The
Migration/Promotion instructions are attached to the notification.
8) The Migrator/Promoter moves the product into production, and
possibly changes the ticket status to “resolved”, depending on how the
Queue Admin has setup his infrastructure permissions. Otherwise, the
Queue Admin “resolves” the ticket.
I am currently looking into having RT "automatically" execute the
version control migration when the ticket status is changed to
“resolved” via CF/scrips.
This entire process is documented in our User and Admin guides.
I'm sure you will want to do things a differently in some manner, but
this should give you an idea of how we handled it. We’d be more than
happy to help in any way we can. Hope this design concept helps.
Kenn
LBNLOn 7/25/2008 10:42 AM, Bill Moseley wrote:
I’ve been scanning the archives for ideas about release management.
Our specific sticking point is to better handle the testing (QA) and
release process in RT.
I’m hoping someone here can offer suggestions.
In a small organization we have a few different projects we manage.
We are currently using a number of RT queues to collect bug reports
and feature requests.
At any given time we have a pool of tickets. We would like to select
a subset of these tickets for our “next release”, which our goal is to
do every two weeks.
We then have about ten or so developers that work on implementing
these tickets. Then, once completed, pass the tickets off to the
testing team (one or two individuals). Tickets are then accepted or
rejected (and sent back to development).
Once all tickets are accepted (or delayed for another release) we need
to release. Ideally, all tickets should then be tagged to that
release so if we need to look back we can see what ticket was
associated with a given release.
Clearly, we will want a way to easily view and select tickets for each
phase of the process.
Is anyone working with a similar process? Could you describe how you
are supporting this workflow with RT?
I’m not clear, for example, if it makes sense to use separate queues
for the different phases, or custom fields to indicate that a ticket
has been selected for the next release, and if it’s in development,
QA, or pending release.
Our plan is to also tightly couple RT with subversion. The goal is to
not allow any subversion checkins that do not include an RT ticket
number (with the flexibility to allow creation of new RT tickets upon
checkin). The log message of the checking will be added to the ticket
and the check in will also create a link in the RT ticket back to the
subversion change set. I assume this will not be too difficult to
implement, but I assume it’s also not uncommon usage so suggestions or
pointers are very welcome, too.
Thanks very much,