はじめに
この記事は 株式会社SUPER STUDIO Advent Calendar 2024 13日目の記事です。
SREグループの atsakiです。
今回は、SREグループでのコードレビューをSlackのリストという機能を活用して効率化した話を紹介します。
これまでのコードレビューの流れと課題
これまで、SREグループではコードレビューを以下のようにSlackのメッセージでレビュー依頼やコメントをすることにより行っていました。
- コードを書いてPRを作成
- Slackでチームのメンバーにレビュー依頼をする
- チームのメンバーがレビューをする
- PRのコメントやSlackのレビュー依頼のメッセージのスレッド上でやり取り
- 特に問題がなければ、PRをapprove
- レビュー依頼のメッセージにapproveしたことを示す絵文字リアクション()をつける
- 2人以上のapproveがもらえたらPRをマージ
- レビュー依頼のメッセージにマージ済みであることを示す絵文字リアクションをつける
Slackのメッセージは時とともに流れていってしまうため、過去のメッセージを探すのに手間がかかったり、approve/マージ済みで見る必要のなくなったメッセージが画面に残ってしまうことを不満に思っていました。
一方で、課題を感じてはいましたが、それほどレビュー依頼の数も多くなかったので、コードレビューの流れを大きく変えたり、新しいツールを導入したりすることを検討するほどではありませんでした。
そんなタイミングで見つけたのがSlackのリストという機能でした。
Slackのリストについて
Slackのリストは、Slack上でタスク等を管理することができる機能です。
(全ての有料プランで利用できます。)
より具体的には次のような表でタスク等のアイテムを管理することができる機能です。
フィールド(列)やフィールドの種類(テキスト、数値、チェックボックスなど)はカスタマイズ可能です。
各フィールドの表示・非表示を切り替えたり、次のようにアイテムをボード状に表示することもできます。
また、画面には写っていませんが各アイテムに対してコメントをつけることも可能です。使い勝手としては通常のメッセージの返信のスレッドとほぼ同じでメンションによる通知なども同じように動きます。
実装
リストのフィールドを設計
これまでのレビュー依頼のメッセージの内容から次のようなフィールドを持つリストを作成しました。
フィールドの名前 | フィールドのタイプ | 説明 |
---|---|---|
PRタイトル | テキスト | PRのタイトル |
概要 | テキスト | PRの概要。作成者やレビュアーにしようしているメンバーのフィールドではグループを指定できないため、グループに依頼するときには、ここでメンションをつけています。 |
PRリンク | テキスト | GitHubのPRへのリンク |
チケットリンク | テキスト | JIRAへのリンク |
作成者 | メンバー | PRを作成したメンバー |
レビュアー | メンバー(複数指定を許可) | PRをレビュー中のメンバー |
ステータス | 選択 | レビューのステータス(対応待ち、レビュー中、Approved、マージ済み) |
approve | 投票 | レビュアーがapproveしたら投票し、誰がapproveしているかわかるようにする |
メッセージ | メッセージ | レビュー依頼のSlackメッセージ |
レビュー依頼用のワークフローを作成
次に考えたのはリストへのアイテムの追加方法です。
リストの画面からアイテムを追加することはできるのですが、レビュー依頼方法が大きく変わっているように見えてしまいメンバーに受け入れられにくいかもしれないと考え、フォームで必要な項目を入力してもらいワークフローでアイテムを追加することしました。
ワークフローにはリストにアイテムを追加するステップが用意されているため、次のようにシンプルなワークフローでアイテムを追加できます。
リストにアイテムを追加するだけであれば2までで良かったのですが、メンバーの反応をみながら徐々に移行できるように従来のようにレビュー依頼のメッセージも送信しておくことにしました。
最後にリストアイテムを更新しているのは、送信したメッセージをリストのアイテムと紐づけるためです。
ワークフローの起動方法については、「ワークフローを目立たせる」ことで、メッセージフィールドをワークフローを起動するボタンに置き換え、直感的に依頼方法が分かるようにしました。
これで、レビュー依頼のボタンを押すと、レビュー依頼用のフォームが開きレビュー依頼を出せるようになりました!
リスト導入後のレビューの流れ
リスト導入後のレビューの流れは以下のようになります。
ステータスの変更などは自動でできればよかったのですが現在は人の手で変更しています。
- コードを書いてPRを作成
- ワークフローでレビューを依頼
- チームのメンバーがレビューをする
- レビューを開始する際にステータスを
対応待ち
からレビュー中
に変更し、自分をレビュアーに追加 - PRのコメントやSlack上でやり取り
- 特に問題がなければ、PRをapprove
- レビュー依頼のアイテムのapproveに投票
- レビューを開始する際にステータスを
- 2人以上のapproveがもらえたらPRをマージ
- アイテムのステータスをApproved/マージ済みにする
従来の流れと比較して複雑になっていると思われるかもしれませんが、実際はそれほど面倒には感じられません。
私だけでなく他のチームのメンバーも特に問題なく使っているので、多少面倒ではあってもリストを導入することによるメリットのほうが大きいのではないかと思っています。
導入してみて
リストを使用することで、レビューされずに放置されている依頼がないか、マージされずに残ってしまっている依頼がないかなど、現在の状況を一画面のボードで簡単に把握し対応することができるようになりました。
以前はレビュー依頼がたまってしまい週一くらいでチームのメンバーで整理していたのですが、最近は整理の時間をとらなくても依頼がたまらなくなったように感じています。
今回の取り組みを通してSlackのように普段使っているツールにも様々な知らない機能があることに気付かされたので、他の普段触れている技術等についてもよりよいやり方がないか見直していくようにしたいと思いました。