GitHub Actionsでレビュー依頼を効率化!レビューする時間がない人を自動で除外する仕組み
株式会社アドウェイズ / 高木義基
テックリード / バックエンドエンジニア
利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|---|
GitHub Enterprise | CI / CD | 101名〜300名 | 2022年9月 | B to B B to C |
利用プラン | GitHub Enterprise |
---|---|
利用機能 | CI / CD |
ツールの利用規模 | 101名〜300名 |
ツールの利用開始時期 | 2022年9月 |
事業形態 | B to B B to C |
アーキテクチャ
アーキテクチャの意図・工夫
当初、GitHubの機能やGitHub Actionsでレビュワーの有効/無効を切り替えるような仕組みは見つけられませんでした(もしかしたら今はもっと良い方法があるかもしれません)。そこで、GitHubのIssueを使ってこの状態を管理するアイデアを思いつきました。
具体的なフローは以下の通りです。
- 「レビュワー自動アサイン除外用」のIssueを1つ作成しておく。
- レビュー対応が難しいメンバーは、そのIssueに自分をAssignee(担当者)として登録する。
- PRが作成されるとGitHub Actionsが起動し、除外用IssueのAssigneeを除いたメンバーの中から、ランダムでレビュワーをアサインする。
- レビュー対応が可能になったら、IssueのAssigneeから自分を外す。
これにより、口頭での宣言や手動での再アサインといった手間をなくし、各自が都合の良いタイミングでアサイン対象から抜けたり戻ったりできるようになります。
実装の詳細
この仕組みは、GitHub Actionsのワークフローと、それを実行するためのRubyスクリプトで実現しました。
ワークフローファイル (.github/workflows/assign_reviewers.yml)
まず、PRが作成されたり、「Ready for review」になったタイミングで処理が実行されるようにワークフローを定義します。ドラフトPRの場合は実行されないようにif条件で制御しています。
name: Assign reviewers
on:
pull_request:
types: [opened, ready_for_review]
jobs:
assign_reviewers:
if: github.event.pull_request.draft == false
name: Assign reviewers to PR
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- name: Assign reviewers to PR
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
PULL_REQUEST_NUMBER: ${{ github.event.pull_request.number }}
run: ruby .github/workflows/assign_reviewers/assign_reviewers.rb ${PULL_REQUEST_NUMBER}
Rubyスクリプト (.github/workflows/assign_reviewers/assign_reviewers.rb)
こちらが、実際のレビュワー選定とアサインを行うスクリプトです。GitHub CLI (gh) を使って、GitHub APIを簡単に呼び出しています。
require 'json'
ORGANIZATION_NAME = 'Organization名'
TEAM_NAME = 'チーム名'
REPOSITORY_NAME = 'リポジトリ名'
EXCLUDED_REVIEWERS_ISSUE_NUMBER = レビュワー自動アサイン除外用のIssue番号
NUMBER_OF_REVIEWERS = 2
# タイトルに 'WIP' が含まれている場合は処理をスキップ
def wip?(title)
title.upcase.include?('WIP')
end
# PRの情報を取得(タイトルと作成者)
def fetch_pull_request(pull_request_number)
JSON.parse(`gh pr view #{pull_request_number} --json title,author`, symbolize_names: true)
end
# レビュワーを設定
def choice_reviewers(pull_request_author)
target_reviewers = fetch_target_reviewers
excluded_reviewers = fetch_excluded_reviewers(pull_request_author)
(target_reviewers - excluded_reviewers).sample(NUMBER_OF_REVIEWERS)
end
# アサイン対象となるチームメンバー全員を取得
def fetch_target_reviewers
JSON.parse(`gh api /orgs/#{ORGANIZATION_NAME}/teams/#{TEAM_NAME}/members`, symbolize_names: true).map { |member| member[:login] }
end
# 除外対象のレビュワー(Issueのアサイン者 + PR作成者)を取得
def fetch_excluded_reviewers(pull_request_author)
assignees = JSON.parse(`gh issue view #{EXCLUDED_REVIEWERS_ISSUE_NUMBER} --json assignees`, symbolize_names: true)[:assignees]
assignees.map { |assignee| assignee[:login] }.push(pull_request_author)
end
# 選定されたレビュワーをPRにアサイン
def assign_reviewers(pull_request_number, reviewers)
endpoint = "/repos/#{ORGANIZATION_NAME}/#{REPOSITORY_NAME}/pulls/#{pull_request_number}/requested_reviewers"
system("gh api --method POST #{endpoint} #{reviewers.map { |reviewer| %(-f 'reviewers[]=#{reviewer}') }.join(' ')}")
end
# メイン処理
def main
pull_request_number = ARGV[0]
pull_request = fetch_pull_request(pull_request_number)
exit if wip?(pull_request[:title])
reviewers = choice_reviewers(pull_request[:author][:login])
assign_reviewers(pull_request_number, reviewers)
end
main
導入の背景・解決したかった問題
導入背景
前提
開発プロセスにおいて、コードレビューは品質を担保するために不可欠な工程です。 私たちのチームでは、プルリクエスト(以下、PR)が作成されると、レビュワーが自動でアサインされる仕組みを導入していました。
ツール導入前の課題
- 週の初めの定例会議で「今週は他の業務で忙しいので、レビュー対応が難しいです」と口頭で宣言するメンバーがいた。
- 自動アサインの仕組みは、その宣言を汲み取ってはくれないため、レビューが難しいメンバーにもお構いなしにアサインしてしまう。
- 結果として、PR作成者が手動で別の人にレビュワーを再アサインする必要があった。
この「レビュー厳しい宣言」も「手動での再アサイン」も、地味ながら双方にとって手間であり、小さなストレスの種でした。
どのような状態を目指していたか
「レビューが難しい期間だけ、自動アサインの対象から自分を外せる」仕組みを導入することで、口頭での宣言や手動での再アサインといった手間をなくし、各自が都合の良いタイミングでアサイン対象から抜けたり戻ったりできる状態を目指していました。
導入の成果
この仕組みを導入したことで、チームの開発プロセスはよりスムーズになりました。
- メンバーはレビュー対応が難しいことを口頭で伝える必要がなくなり、自分のタイミングでIssueのAssigneeになるだけでよくなった。
- PR作成者は、アサインされたレビュワーが対応可能であると信頼できるため、再アサインの手間がなくなった。
- レビューができないのにアサインされてしまう罪悪感や、再アサインを依頼する手間といった、小さなストレスから解放された。
導入に向けた社内への説明
上長・チームへの説明
チームではすでにGitHub Actionsを日常的に活用していたため、導入に関する説明は不要でした。
活用方法
よく使う機能
私たちのチームではGitHub Actionsを以下の用途でも使用しています。
- 自動テスト、リンター、フォーマッターの実行
- レビュー済みPRのSlack通知
- メインブランチへのマージによる、自動デプロイ
ツールの良い点
- GitHubを利用していれば、.github/workflows以下にワークフローファイル(YAMLファイル)を配置するだけで利用可能。
- YAMLファイルを記述するだけで、どのようなイベント(PR作成など)をトリガーに、どのような手順(スクリプト実行など)で処理を行うかを簡単にワークフローとして構築できる。
ツールの課題点
- ワークフローの動作確認をローカルで容易に行えないので、デバッグが大変。
- ワークフローの内容によっては、メインブランチにマージしないとワークフローの動作確認ができない場合がある。
株式会社アドウェイズ / 高木義基
テックリード / バックエンドエンジニア
よく見られているレビュー
株式会社アドウェイズ / 高木義基
テックリード / バックエンドエンジニア
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法