[rt-users] Workflow for release management

[Bill Moseley]

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,


-- 
Bill Moseley
moseley at hank.org