JiraとGithubをシームレスに連携する

thumbnail

 

サントリーウエルネス DX推進部エンジニアリングGの青木です。Comadoのサーバーサイド(以下SS)チームでリーダーをしています。
今回はJiraとGithubを連携させる件について書いてみたいと思います。

経緯

Coamdoでは現在チケット管理でJiraを利用していますが、もともとSSチームとしてはGithub IssuesとMilestoneだけを使ってタスクとリリースの管理をしていました。
理由としてはGithubだけで完結できるのとIssueとMilestoneの相性が非常に良かったからです。また、どのMilestoneにどのIssueが紐づいているかを管理できたのでリリースごとに対象チケットをまとめる必要がありませんでした。加えて、Githubからリリースに何が含まれるかを確認できる点もとても魅力的でした。

他にも、Issueにはキーワードを使ってPull Requestとリンクさせる機能があります。これによりPull RequestがCloseするとIssueも自動的にCloseしてくれるなど開発者体験的にも良いと思いました。

ただ同時並行で色々な事が進むにつれて、Githubだけだと管理しにくくなりました。結果としてはJiraにチケット管理を寄せながらMilestoneの良いところは残す形で移行しましたので、どう移行したのか書いてみたいと思います。

なにが課題だったか

1️⃣ Issue単体で期日を管理できない/プロジェクト管理ができない

IssueはあくまでIssueを管理するものであり、期日まで管理するものではありません。期日まで管理したいならIssueだけではなく、Github Projectsを立ち上げ、そちらにリンクさせることで期日を管理できます。
なにが言いたいかというと、プロジェクト管理とIssue管理は別物であり、多数のステークホルダーがいる環境では期日管理が必須となります。そのため、Issue単体で管理することが難しいなと思う場面が非常に多かったです。

2️⃣ Milestoneはリリースの期日を管理するものであり、個別Issueの期日を管理するものではない

Milestoneがあれば期日の管理ができるのでは?についていうと、できないと思います。
Milestoneはその時点のリリースに紐づく変更管理が目的であり、個別Issueの管理を目的に設計されている機能ではありません。個別Issueの期日を管理したいならGithubではGithub Projectsを使うしかありません。

3️⃣ リポジトリに紐づかない課題もある

例えば調査依頼も課題としてチケット管理したい場面はプロジェクト運営上発生します。その場合、どのリポジトリにも紐づかない課題となってしまいます。Issueの特性上、必ずどこかのリポジトリ起点でIssueが切られる作りになっているので、Issueだけではプロジェクト全体で発生する課題管理は難しいです。

4️⃣ リポジトリが増えてくるとチームメンバーのタスク状況が見えにくくなる

すべてがモノレポで管理されていれば問題ありませんが、そういうわけにもいかないと思います。

このIssueはこのリポジトリ、別のIssueはこのリポジトリ…と管理していくと結果、今持っているIssue全量ってなんだっけ?となります。
Issue検索機能をうまく使えば全量を出すことはできますが、こういう運用は想定されてないだろうなと思いました。素直にプロジェクト管理ツールを使うべきだなと。

5️⃣ Githubだけでは他チームとの連携がしにくい

Githubはあくまで開発者目線では非常に良いサービスだと思います。ただし、企画チームや他チームから見るとそうでもないというか、実際に使っていないサービスなので何を見たら良いかわからないようでした。(私が使ったことのないサービスを見るときもわからないと思います)。また、Githubアカウントを持っていないのでIssueを参照できませんといった声を聞く場面が多くなっていました。1チームの課題を見ることだけのためにアカウントを作成してもらうのも微妙です。

たしかに開発者間での連携には優れているGithubですが、他チームから見ると必ずしもそうではないですし、開発者だけで回しているプロジェクトはほぼ存在しないと思います。できるだけチーム間で共通認識が取りやすいツールに寄せるべきだと思いました。

Github IssuesとMilestoneだけで運用して出てきた課題について書きましたが、
要するにIssueはプロジェクト管理ツールではないので、期限管理したいならちゃんとしたツールを使おうねって話です。

とはいえ、Github Milestoneは使いたい

Milestoneはそのリポジトリのバージョンに紐づく変更管理を容易にしてくれる機能です。
これがあるからこそ、リリースのたびに何が含まれているかを確認する手間を削減し、リリース頻度向上に寄与しているといっても過言ではないと思っています。
このMilestoneだけはリポジトリ単位で管理しておいたほうがいいなと思いましたのでうまく併用する方法はないものか…と漠然と考えていました。

改めてチームにおけるプロジェクト/チケット管理の要件を整理してみる

私が実際に運用していた感覚でいくと下記かなと思いました。

  • 調査系のチケット管理もできること
  • MilestoneはGithubのリポジトリに紐づく形で管理できること
  • 各チケットやMilestoneは期日管理ができること

ツール前提では決してありませんが、上記をGithub Issue+Milestoneでは満たせないことは挙げた課題感からも明白なので、ツールの再選定は必要でした。

ツール選定

既にサントリーウエルネスの他プロジェクトでも使っているものや今後使えそうなもので考えた結果2択になりました。

Jira

  • サントリーウエルネスのプロジェクト管理で導入しているツール
  • 他のチームも使っており、連携が取りやすい

Github Projects

  • Githubが提供しているプロジェクト管理機能
  • IssueやMilestoneとの連携が容易

これらの機能を含め、使用感などを諸々試してみました。結果が下記です。

  • Issueは結局リポジトリに紐付けないと調査系チケットが切れない
  • Issueが入れ子関係を持てない
  • 紐づき関係はlabelで管理することになる。このlabelがjsonで工夫しないと管理しにくい。そもそもプロジェクト単位ではなくリポジトリ単位でlabelを管理するため、中途半端に管理がリポジトリに寄る仕様となっている。

このような理由からIssue+Github Projectsで管理するコストかかります。そのため、管理ツールとして汎用性があるJiraに寄せることにしました。

うまいこといいとこ取りはできないか

Jiraだけに寄せると今度はGithub Milestoneが直接使えなかったりするなと思ったというのもあり、非常に悩みました。移行したは良いもののMilestoneやIssueのいいところもあるし、一概に悪いことはなかったなと思っていたからです。できれば両方のいいとこ取りをしつつ、シームレスに連携できれば解決するのになぁ…と。

色々調べていると、これが可能かもしれないとわかりました。ただ導入するだけではなく、紐づけの設計や運用フローを明確に定義してそれぞれの良いところを活かすことが鍵なのでは?と思ったので、Jiraを中心として活用しつつ、Githubと連携させたときの全体運用フローの設計をしてみました。

どのようにJiraとGithubを連携させるか

JiraにはGitHub for Jiraという便利なアプリがあるのでそちらを利用すれば連携できます。

これを使えばJiraでチケット管理とプロジェクト管理をしながら、Pull Requestと連携させて進捗管理、Milestone紐づけをシームレスに行うことができます。

運用フロー

Jiraを利用しながら最終的な変更管理は各リポジトリに収束させるとして、下記のような全体感で設計してみました。

基本的に縛られたフローで管理するのではなく、Issueを使いたければIssueを使ってもいいし、Pull Requestで完結できるものはPull Requestをあげてもいいよということにしました。
これは開発者自身で主体的に開発してほしいためです。ただし、最終的な砦としてMilestoneに紐づいていることが条件ではありますが、そこさえ守られていれば用途に沿って適切なツールを選択してもらえれば問題ないと思い、フローを設計しています。

運用フローパターン

1️⃣ Jira

  • 条件
    • 基本はJiraで管理するためこちらを選択する
    • 期限管理すべき課題
    • 1課題に対して複数リポジトリにIssueがまたがることが分かっている場合
    • 開発者だけでなく企画側にも連携すべき課題
      • GithubはアカウントおよびOrganizationを申請していないと利用できず、開発者以外への連携に弱いため
  • フロー
    • Jira作成 → Jiraの画面から{feature | horfix}/チケットIDで新規ブランチ作成 → PR作成 →Milestone紐づけ

2️⃣ Github Issue

  • 条件
    • チケット化する前に対象のリポジトリが1つに限定されることが分かっている場合
    • 開発者同士のコミュニケーションで解決するような軽微なタスク
    • とはいえ経緯は書いて残しておきたいタスク
    • Milestoneに紐づく課題
  • フロー
    • Issue作成 → {feature | horfix}/IssueIDで新規ブランチ作成 → PR作成 →Milestone紐づけ

3️⃣ Pull Request

  • 条件
    • 経緯を書くまでもない軽微な修正
    • 起票者単体で終わるような課題
  • フロー
    • {feature | horfix}/変更内容要約で新規ブランチ作成 → PR作成 → Milestone紐づけ or localラベル付与

このようなフローを踏めばGithubとJiraをシームレスに連携できるかつ期限管理や全体進捗の可視化はJiraを利用できるといういいとこ取りが可能です。

Issueの劣化版だよね?と言われないための対策

冒頭にIssueにはキーワードを使ってPull Requestとリンクさせる機能があると言いました。これがClose漏れに効き、運用コストを劇的に低下させてくれます。これがよかったのにJiraに移行したら手運用が増えて負担が増加した!なんて言われたくありませんよね…。

これはJiraのAutomationを活用すれば解決します。

JiraからBranchを作成後に作成したBranchを監視し、状態の遷移を確認したらチケットの状態も遷移させる。これにより、Github Issueでいうclosesやfixesのような動きを可能にし、チケットのclose漏れを防ぐことができます。Jiraに移行したからできなくなったよね、Issueのほうが良かったなぁ…なんて言わせない素晴らしい機能ですね。

設定しているAutomationルール一覧

  • Branchが作成されたら課題を「進行中」に移動
  • Pull Requestが作成されたら課題を「レビュー中」に移動
  • Pull Requestが却下されたとき、課題を「進行中」に差し戻す
  • Pull Requestがマージされたら課題を「完了」に移動

おわりに

色々課題感がありつつも最終的にはGithub MilestoneとJiraのいいとこ取りができるフローにできたと思います。 ただこのフローが必ずしも正解ではないと思いますし、もっといいフローや課題感があれば変えていこうと思っています。 プロジェクト/チケット管理を柔軟なフローで運用しているよ、両方のいいとこ取りは設計次第で可能だよ、ということが伝われば幸いです。