Automation for Jiraで課題ステータス変更を自動化する

Jiraには数多くのアドオンがありますが、その中でもJira運用における効率化や自動化をしたい場合に有名なのが
[Automation for Jira](https://marketplace.atlassian.com/apps/1215460/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では「どんな時に」「何を」「どのように変更するか」をルールとして作成します。

最初に出来上がったルールを見せると、今回の場合はこのようなルールになります。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/2bf8eaac-db7a-c1ba-70ce-cf11474fdfba.png" height=500>

順々に説明していきましょう。
まずは「どんな時に」を定義します。トリガーとして`Issue transitioned`(課題のステータスを変更した時)を選択し、
`To status`で`Done`を入力します。
`From status`にステータスを入力すれば「レビュー中から完了になった時だけ」など、より厳しい条件を指定することもできますが、今回はシンプルなルールとするため指定しません。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/7b07490a-8076-1c1a-8aca-43488287c5a1.png" width=800>

次にフィルターとしてJQL conditionで`status = "Done"`を入力し、完了になった課題だけを該当とするようにします。
`Issue transitioned`で課題のステータスが完了になった時を条件としてるんだからいらないのでは・・と思いますが、この条件が無いとうまく動きませんでした汗
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/8f0f6190-ddc0-1065-43a0-874f121ec617.png" width=800>

何をどのように変更するかの「何を」の部分です。
新しいコンポーネントとして`Branch rule / related issues`を選択し、
`Type of related issues`で`Sub-tasks`にします。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/cdcb3e87-08d9-4d9b-a9b5-db03a6eb4c8a.png" width=800>

まだ完了していないサブタスクを抽出する為に`status != "Done"`のJQL Conditionを指定しています。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/21399bbe-ad56-c811-ad83-6e0f1917d04c.png" width=800>

最後に「どのように変更するか」です。
単純に完了にするだけなら`Transition the issue by:`で`Selecting the destination status`(変更するステータス)を選択し、`Destination status`で`Done`を選択します。
`Selecting a specific transition`だと `Review → Done`といったステータスフローを指定することになりますが、フローによっては適用されないこともありますのであまりおすすめはしません。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/9451016d-8f93-6b30-63c7-5129ae59a8c2.png" width=800>

条件を一通り指定したらルール名をつけて保存し、ルールを有効にすれば完成です。

##2.サブタスクが全て完了した時に親の課題を完了する
これは上記のルールとは逆のパターンですね。
例えばある課題に3つのサブタスクがあったとして、2つのサブタスクはすでに完了しており、残る1つのサブタスクを完了にした時に親の課題も自動的に完了させたい場合に使います。

ルールはこのようになります。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/a2cf460c-4aea-030d-bebe-49ff3258213a.png" height=600>

2つ目の条件までは最初のルールと変わりません。
3つ目の条件としてコンポーネント追加で`Branch rule / related issues`を選択し、
`Type of related issues`で`Parent`にします。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/926601a6-3c2f-3671-5d99-429f3ff54257.png" width=800>

まだ完了していない親の課題を抽出する為、JQL conditionで`status != "Done"`を指定します。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/a30e52f8-b1ec-922e-a7a5-2e448af204fa.png" width=800>

このルールにおいて大事な箇所となります。
`Related issues condition`で以下のように指定することで、親課題が持つ全てのサブタスクが完了した場合に処理が行われるようにします。
この条件が無いと残りのサブタスクが完了していない場合も親の課題を完了してしまうので注意してください。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/a5b085f7-f013-5c52-9b45-b64d86b1de78.png" width=800>

最初のルールと同じように課題のステータスを`Done`に移行するように設定します。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/d56eeaad-b0be-5af0-af2b-6d6c9c942c1e.png" width=800>


##3.リリースした時に紐づく課題のステータスを全て変更する
僕のプロジェクトで困っていたのは、Jiraでリリースバージョンを作成してリリースした時に紐づく課題を手動でステータス変更しなければならなかったことです。
というのも`Done`はあくまで課題に対応したブランチをdevelopブランチへのマージ完了と定義していたので、リリースしたかどうかはまた別の`Completed`というリリース済みを表す独自のステータスとして扱っていたからです。

このような場合も実は以下のようにルールを定義すれば自動化できます。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/1107ef99-6cc8-067a-55a7-5845e55826d2.png" height=400>

僕達のプロジェクトでは一般的なセマンティックバージョニングに沿ってJiraのリリースバージョンをつけています。
例. 1.0.0, 2.1.10....

「Jiraであるバージョンをリリースした時」を定義する必要があるので、`Version Released`を選択し、`Version name filter`では
`(\d+).(\d+).(\d+)`といった正規表現を用いて適用するバージョンをフィルタします。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/91eb7571-6b18-2478-eb8a-006baf9713fb.png" width=800>

正規表現の詳細についてはテキストボックスの下にある以下のリンクをご覧ください。
[regular expression documentation](https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html)

ポイントとしては「何を」を定義する為に、前のトリガーでフィルタしたバージョンを変数としてJQL conditionで用います。
それが`fixVersion = {{version.name}}`というJQLになります。
つまり1.0.0というバージョンをJiraでリリースすれば、まずトリガーの正規表現にあてはまり次に`version.name`の値として実際に`fixVersion = "1.0.0"`のJQLで検索されたリリースに紐づく全ての課題を抽出することになります。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/9cd20a96-5c23-23bc-52f3-1a04dc9e6f10.png" width=800>


最後に課題のステータス変更先を設定したら完了です。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/71113/ea1775a0-ed28-8043-9a1f-907cb76d85ef.png" width=800>


いかがでしょうか？ この3つのルールを作成するだけでも、だいぶ手動での変更の手間と漏れが無くせるかと思います。
もし「こういうルールも便利だよ」「〜の場合どうルールを作ればいいの？」等意見や疑問があれば気軽にコメントをください。