[rt-users] Workflow for release management

[Kenneth Crocker]

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
LBNL

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