サントリーウエルネス DX推進部の青木です。
以前、JiraとGithubをシームレスに連携する記事を執筆しました。
ただそこでは設定しているAutomationルール一覧についての具体は記載していなかったので、改めてこちらでまとめてみようと思います。
Jira Automationとはなにか
Jira Automationとは、Jiraが用意しているあらゆるトリガーから柔軟にワークフローを組むことができる機能です。
テンプレートも多数用意されていますので簡単に組むことができますし、割と自由度が効くので幅広い処理をJiraに任せることが可能です。
ソースコードが不要なのも非エンジニアからしたら嬉しいポイントだとは思います。個人的には結局やってることはあまりかわらないのでソース化されていない恩恵はそこまで感じませんが、ビジュアライズされている部分は嬉しいポイントかなと思います。
詳しくはこちら
最初から下記のようにテンプレートが用意されているので、テンプレートからカスタマイズすることもそのままつかうことも可能です。便利ですね。
設定しているルール
ここではJiraとGithubをシームレスに連携するで紹介したルールを中心に実際にプロジェクトで利用しているルールについていくつか紹介したいと思います。
全体のステータス遷移図はこんなイメージです。
Branchが作成されたらチケットを「進行中」に移動
前提としてJiraにはGitHub for Jiraというアプリがあり、これを利用することでGithubとの連携が可能になります。その場合はJiraのステータスとGithubのBranchを同期させるような動きをJira Automationを使って組むことが可能です。
※連携時は管理者権限が必要になりますので、ICT担当者と相談の上導入するようにしてください。
その中でBranchが作成されたらチケットを進行中に移動するワークフローが下記です。
Branchの作成時をトリガーにしてStatusを移動させます。
BranchはJiraのチケットの画面からでも作成可能ですし、ローカルで作成したブランチをあとで紐づけることも可能なので、お好きな方で進めると良いと思います。最終的にはチケットとBranchが紐づいて管理されていれば何でもよいと思います。
Pull Requestが作成されたらチケットを「レビュー中」に移動
これもタイトル通りですが下記です。
Githubをトリガーにしてワークフローを組めます。
Pull Requestが却下されたとき、課題を「進行中」に差し戻す
Pull Requestが却下されたのにずっとレビュー中になっているのは微妙なので、進行中に差し戻すようにしています。却下されたのはPull Request作り直しかその対応自体が不要になったかですが、そこは却下のみでは判断つかないのでルール上は進行中に落としています。
Pull Requestがマージされたら課題を「完了」に移動
Merge＝チケット完了と判断してステータスを遷移させています。
ただここで注意しなければならないのは、親チケットからGithubのBranchを紐づけてしまうと、親チケットがCloseされてしまうことです。なのでJiraのチケットの切り方も1タスク＝1Branch単位で切ることを意識しましょう。
逆にこの制約をかけておくとチケットの切り方の粒度も自然とあっていきます。
子チケットを作成したとき、子チケットに担当者設定、期限設定をする
上記のようにPull RequestがMergeされたときに親チケットがCloseされないように、親チケットから子チケットを作成して子チケット＝1タスク＝1Branchの粒度になるような運用にしています。
そうすると、必然的に子チケットを作成する機会が増えるのですが、デフォルトだと担当者や期限が入らなくていちいち設定しなければなりません。これが非常に面倒かつ、設定していないと期限が迫っている通知のためにJQLで引っ掛っかからなくなったり、担当者のチケットで一覧化するときにも担当者不在の謎チケットが誕生してしまうことになります。これはそのような曖昧なチケットを撲滅したいと考えて生み出したワークフローです。
これをすることで親チケット担当者に一旦は振られてしまうようなつくりになってしまうのですが、担当者不在になっているよりはいいだろうという考えでいます。（担当者の方にはご迷惑おかけします。）
このワークフローでは、親チケットの担当者、期限を子チケットのフィールドにそのまま設定するようにしています。
例えば親チケットの期限は{{issue.parent.dueDate}}のように取得できます。
このあたりはスマートバリューというものがJiraでは使えるので、うまく使えると良いと思います。Jiraが事前に用意している変数から色々取得できますよーのような機能です。
期限が迫っているチケット一覧をSlackに通知する
最後にSlackへ通知するワークフローを紹介します。
スケジュールをトリガーにしてJQLを発行し、チケットが引っかかればSlackに通知するワークフローを定義しています。
JQL
JQLは下記のようにしています。
assignee in ("担当者のアカウントID")
AND status not in (Done, CANCEL, Closed, Resolved, "won't fix")
AND resolution = Unresolved
AND duedate <= endOfDay(1)
注意点は2点あります。
1点目、Jira Automationがプロジェクトごとの設定になるので、プロジェクトを跨いでのJQLは発行できません。
こちらでJQLを設定してもJira側でJQLを発行するときにprojectを指定するような取得の仕方をしてしまいます。詳しくはクエリを有効化するを押下して実際に発行されているJQLを見に行けばわかるのですが、下記のようにワークフロー内のJQLで定義しなくても発行されているJQLにはprojectの要件が追加されていることがわかると思います。
(
project in (projectId)
)
AND (
assignee in ("担当者のアカウントID")
AND status not in (Done, CANCEL, Closed, Resolved, "won't fix")
AND resolution = Unresolved
AND duedate <= endOfDay(1)
)
Automationがprojectに紐づいている機能なので、プロジェクト横断で検索をかけて通知したい場合はAutomationではなく別の方法を考える必要がありそうです。
2点目、ダッシュボードなどで利用できるフィルターはここのJQLでは設定できないため、個別設定になります。
本来的な話をすると、JQLは使い回せたほうが色々良いと思ってます。フィルターに設定しておけば適宜フィルタリングもできますし、ダッシュボードにも使えます。同じJQLを使っているのでメンテナンス性も◎です。
ただしAutomationに設定しているJQLは個別設定なので、個別メンテナンスが必要になります。例えばAsigneeで絞り込む場合はメンバーが変更されるたびにJQLのメンテが必要ですし、横展開でJQLを利用したい場合にも対応できません。ここのメンテナンス性が非常に悪いのでどうにかしてほしいな…と思いながら利用していますが、個別メンテが必要だよということだけ注意してもらえれば良いかなと思います。
lookupIssuesを利用する
これもJiraで使えるスマートバリューの一種ですが、JQLで引っかけたチケットをリストで扱える変数です。
件数の確認も{{lookupIssues.size}}が0より大きいで判定します。リストの使い方そのままのイメージですね。
次に通知するメッセージですが、lookupIssuesを使う大きなメリットだと感じているのが複数件チケットがあったとしても1メッセージで出力できる点です。lookupIssuesを使わなくてもJQLで引っ掛けたチケットを通知する仕組みは構築できますが、その場合は複数件メッセージを送信してしまう作りになってしまうのでノイズになってしまいます。その点、lookupIssuesを使えばメッセージを作成仕切ったあとにSlackにメッセージを送信できるので1メッセージ送ることが可能になります。
@グループメンション
明日に期限を迎えるチケットが{{lookupIssues.size}}件あります。
担当者はハンドリングをお願いします。
{{#lookupIssues}}
■ *{{key}}：{{summary}}*
担当者：{{assignee.displayName}}
期限：{{duedate}}
URL：{{url}}
{{/}}
これを事前に構築しておいたSlackアプリのWebhookURLにメッセージを飛ばすように設定しておけばOKです。Slackアプリを利用したWebhookの方法については過去記事で紹介していますので、そちらをご参照ください。POSTして特定のチャンネルに流すだけのアプリとして作成できていればOKです。
おわりに
紹介したワークフロー以外にも子チケットがすべて閉じたら親チケットを閉じるワークフローであったり、親が完了したら子もすべて閉じるようなワークフローも設定しています。このあたりはテンプレートを活用しながら色々組めると思いますので、ぜひ設定してみてください。間違いなく言えるのは、Jiraを使う以上、Automationを使わないのはもったいないということですね。今回は以上になります。