ルーティング ルールのセットアップ

Issue Manager では、定義済みのルーティング ルール、各問題の現在の状態、および対応する状態所有者に基づいて、問題のライフサイクルにおける問題の送信先となる受信箱を決定します。 この高度なルーティング メカニズムにより、面倒な作業であった問題のディスパッチを代行できます。

問題の状態とは、その問題の現況です。 Issue Manager のデフォルト ワークフローには多数の状態が用意されています。 状態の所有者とは組織内のロールの 1 つで、与えられた状態にある問題の対処を担当する人のことです。

次に、デフォルト ワークフローの問題の状態と所有者の例を示します。
レビュー未完了
この問題が本当にバグやドキュメントの誤りなのかどうかを誰かが決定する必要があります。 通常、この状態は QA エンジニアが所有します。
開発準備完了
いつでもコードの作成に取りかかることができます。 この状態は通常、開発者が所有します。
QA 準備完了
バグが本当に修正されているかどうかを誰かが確かめる必要があります。 通常、この状態は QA エンジニアが所有します。

問題を誰が提起するかによって、同じタイプの異なる問題を異なる状態でワークフローに入れることができます。 ルーティングはそれに応じて変わります。 たとえば、開発者によって提起された問題は開発準備完了の状態でワークフローに入るため、開発者の受信箱に送られます。 一方、社内ユーザーによって提起された問題はレビュー未完了の状態でワークフローに入るため、QA エンジニアの受信箱に送られます。 いわゆる問題の初期状態は、グループ設定を通じて割り当てられます。

ユーザーが問題に対してアクションを取ると、その問題はワークフローの中である状態から次の状態に移行します。 たとえば、報告されたままでまだレビューされていない問題が確かにバグであると QA エンジニアが確認すると、その問題はレビュー未完了の状態から開発準備完了の状態に移行します。 ここでルーティング ロジックを用いる主な目的は、問題がバグであるといったん QA エンジニアが判断すると、その問題が自動的にそのエンジニアの受信箱から適切な開発者の受信箱に必ず移動するようにすることです。