導入
開発現場において、プルリクエスト（PR）のレビューで「記述が不足している」「依存関係の更新漏れがある」といった形式的な指摘を繰り返してはいませんか？こうした機械的なチェックにエンジニアの時間を割くのは非効率です。今回紹介する「Danger」は、PRのメタデータを解析し、あらかじめ定義したルールに従って自動でコメントを行うツールです。これをCI/CDパイプラインに組み込むことで、人間はロジックや設計といった「本質的なレビュー」に集中できるようになります。
基礎知識
Dangerは、PRの差分やファイル構成、説明文などを解析してコメントを投稿するツールです。特にNode.js環境では「danger-js」が一般的に利用されます。仕組みは非常にシンプルで、CI環境（GitHub ActionsやCircleCIなど）でテスト実行時にDangerを呼び出し、設定ファイル（dangerfile）に基づいた判定結果をPRにフィードバックします。これにより、「PRテンプレートの未記入」や「テストコードの追加忘れ」といったミスを、マージ前に即座に検知可能です。
実装/解決策
導入手順は大きく3ステップです。
1. パッケージのインストール: プロジェクトのdevDependenciesに追加します。
2. Dangerfileの作成: ルールを定義するファイルを作成します。
3. CI設定: GitHub Actions等のパイプラインにDanger実行コマンドを追加します。
CIで実行する際は、GitHubのアクセストークンを環境変数として渡す必要がある点に注意してください。
サンプルプログラム
以下は、プロジェクトのルートディレクトリに配置する「dangerfile.ts」の例です。
// dangerfile.ts
import { danger, warn, fail } from “danger”;
// 1. PRのディスクリプションが短すぎないかチェック
const prDescription = danger.github.pr.body || “”;
if (prDescription.length < 10) {
warn("PRの説明文が短すぎます。変更内容を具体的に記述してください。");
}
// 2. package.jsonが変更されているのにlockファイルがない場合を指摘
const packageChanged = danger.git.modified_files.includes("package.json");
const lockfileChanged = danger.git.modified_files.includes("package-lock.json");
if (packageChanged && !lockfileChanged) {
fail("package.jsonが変更されていますが、package-lock.jsonが更新されていません。");
}
// 3. テストコードが含まれているか（簡易チェック）
const hasTestFiles = danger.git.modified_files.some(path => path.includes(“test”));
if (!hasTestFiles) {
warn(“テストファイルが変更されていません。影響範囲を確認してください。”);
}
応用・注意点
現場で運用する際の注意点は、「警告の出しすぎ」です。全てのルールをfail（エラー）にしてしまうと、CIが通りづらくなり開発者のモチベーションを下げます。必須のガードレール以外はwarn（警告）に留め、PRの品質向上を促すアドバイザー的な立ち位置で運用するのがコツです。また、Dangerの実行にはGitHubのAPI制限がかかる場合があるため、大規模なリポジトリで運用する際は、実行間隔やトリガー条件を適切に設定してください。
コメント