Jiraには数多くのアドオンがありますが、その中でもJira運用における効率化や自動化をしたい場合に有名なのが
Automation for Jiraというアドオンです。
例えばある条件にもとづいて
- チケットを作成
- ステータスを変更
- コメントを作成
- フィールドに特定の値を設定
- Slackやその他のサービスに通知
などなど、アイデアによって様々な自動化を行うことが可能です。
Automation for Jiraの基本的な説明についてはこのスライドが分かりやすいのでご参照ください
https://www.slideshare.net/kajinari/automation-for-jira
自分のプロジェクトでもこのAutomation for Jiraを活用しています。
今回は特に便利な課題のステータスを自動的に変更する3つの方法をご紹介します。
1.親の課題が完了した時にサブタスクも全て完了する
Jiraを利用していてサブタスクを作り親子関係の課題が生まれることは日常的にあると思います。
しかしありがちなのが親の課題のステータスを完了(Done)に変更した時に全てのサブタスクのステータスも完了に変更するのを忘れてしまうことですね。
これこそ自動化してしまいましょう。
Automation for Jiraでは「どんな時に」「何を」「どのように変更するか」をルールとして作成します。
最初に出来上がったルールを見せると、今回の場合はこのようなルールになります。
順々に説明していきましょう。
まずは「どんな時に」を定義します。トリガーとしてIssue transitioned(課題のステータスを変更した時)を選択し、
To statusでDoneを入力します。
From statusにステータスを入力すれば「レビュー中から完了になった時だけ」など、より厳しい条件を指定することもできますが、今回はシンプルなルールとするため指定しません。
次にフィルターとしてJQL conditionでstatus = "Done"を入力し、完了になった課題だけを該当とするようにします。
Issue transitionedで課題のステータスが完了になった時を条件としてるんだからいらないのでは・・と思いますが、この条件が無いとうまく動きませんでした汗
何をどのように変更するかの「何を」の部分です。
新しいコンポーネントとしてBranch rule / related issuesを選択し、
Type of related issuesでSub-tasksにします。
まだ完了していないサブタスクを抽出する為にstatus != "Done"のJQL Conditionを指定しています。
最後に「どのように変更するか」です。
単純に完了にするだけならTransition the issue by:でSelecting the destination status(変更するステータス)を選択し、Destination statusでDoneを選択します。
Selecting a specific transitionだと Review → Doneといったステータスフローを指定することになりますが、フローによっては適用されないこともありますのであまりおすすめはしません。
条件を一通り指定したらルール名をつけて保存し、ルールを有効にすれば完成です。
2.サブタスクが全て完了した時に親の課題を完了する
これは上記のルールとは逆のパターンですね。
例えばある課題に3つのサブタスクがあったとして、2つのサブタスクはすでに完了しており、残る1つのサブタスクを完了にした時に親の課題も自動的に完了させたい場合に使います。
ルールはこのようになります。
2つ目の条件までは最初のルールと変わりません。
3つ目の条件としてコンポーネント追加でBranch rule / related issuesを選択し、
Type of related issuesでParentにします。
まだ完了していない親の課題を抽出する為、JQL conditionでstatus != "Done"を指定します。
このルールにおいて大事な箇所となります。
Related issues conditionで以下のように指定することで、親課題が持つ全てのサブタスクが完了した場合に処理が行われるようにします。
この条件が無いと残りのサブタスクが完了していない場合も親の課題を完了してしまうので注意してください。
最初のルールと同じように課題のステータスをDoneに移行するように設定します。
3.リリースした時に紐づく課題のステータスを全て変更する
僕のプロジェクトで困っていたのは、Jiraでリリースバージョンを作成してリリースした時に紐づく課題を手動でステータス変更しなければならなかったことです。
というのもDoneはあくまで課題に対応したブランチをdevelopブランチへのマージ完了と定義していたので、リリースしたかどうかはまた別のCompletedというリリース済みを表す独自のステータスとして扱っていたからです。
このような場合も実は以下のようにルールを定義すれば自動化できます。
僕達のプロジェクトでは一般的なセマンティックバージョニングに沿ってJiraのリリースバージョンをつけています。
例. 1.0.0, 2.1.10....
「Jiraであるバージョンをリリースした時」を定義する必要があるので、Version Releasedを選択し、Version name filterでは
(\d+).(\d+).(\d+)といった正規表現を用いて適用するバージョンをフィルタします。
正規表現の詳細についてはテキストボックスの下にある以下のリンクをご覧ください。
regular expression documentation
ポイントとしては「何を」を定義する為に、前のトリガーでフィルタしたバージョンを変数としてJQL conditionで用います。
それがfixVersion = {{version.name}}というJQLになります。
つまり1.0.0というバージョンをJiraでリリースすれば、まずトリガーの正規表現にあてはまり次にversion.nameの値として実際にfixVersion = "1.0.0"のJQLで検索されたリリースに紐づく全ての課題を抽出することになります。
最後に課題のステータス変更先を設定したら完了です。
いかがでしょうか？ この3つのルールを作成するだけでも、だいぶ手動での変更の手間と漏れが無くせるかと思います。
もし「こういうルールも便利だよ」「〜の場合どうルールを作ればいいの？」等意見や疑問があれば気軽にコメントをください。