こんにちは！日々のCI/CDパイプラインの運用、お疲れ様です。
「Jenkinsのビルド履歴、見づらいな…」「どのジョブがよく失敗するのか、パッと全体像を把握したいな…」そんな風に悩んだことはありませんか？
標準の機能や「Build Statistics」プラグインも便利ですが、複雑な集計や「特定のブランチごとの失敗傾向」などを深く分析しようとすると、どうしても限界がやってきます。
そこで今回は、Jenkinsの実行履歴を外部のRDB（リレーショナルデータベース）にブチ込み、SQLを使ってCI/CDのパフォーマンスを多角的に分析するデータパイプラインの作り方を解説します！
これをマスターすれば、感覚ではなく「データ」に基づいた説得力のあるインフラ改善ができるようになり、チームからの信頼もグッと上がりますよ。さあ、一緒にモダンなデータドリブン・CI/CDの世界へ踏み出しましょう！
—
1. なぜJenkinsのデータをRDBに集約するのか？
まず、「なぜわざわざそんな面倒なことを？」と思うかもしれません。理由はシンプルです。Jenkinsはデータベースではないからです。
Jenkinsのビルド履歴は、基本的にはマスターノードのファイルシステム（XMLなど）に保存されます。そのため、以下のような分析をしようとすると苦労します。
- 「過去3ヶ月間で、最もビルド時間が長かった上位10個のジョブは？」
- 「曜日別・時間帯別のビルド失敗率はどうなっているか？」
- 「特定のテストが頻繁にコケ始める前兆はあるか？」
これらをSQL（PostgreSQLやMySQLなど）で一発叩けるようにしておくと、Grafanaなどの可視化ツールと連携するのも容易になり、CI/CDの健康状態をいつでも手に入れた状態にできます。
—
2. 全体像：データパイプラインのアーキテクチャ
今回構築する仕組みの全体像はこうです。
1. Jenkins：ビルドが完了する（成功・失敗問わず）。
2. Post-build Action / Webhook：ビルド直後にGroovyスクリプトやプラグインを使ってビルドデータを抽出。
3. 転送スクリプト / API：抽出したJSONなどのデータを外部RDBに送信。
4. RDB：データを蓄積する。
5. SQL / 外部BI（Grafana等）：分析・可視化。
今回は、初心者の方でも最も手軽に、かつ確実にデータを流し込める「Jenkins Pipelineの`post`ブロックからPython経由（または直接）でRDBに書き込むアプローチ」の基礎を優しく解説します。
—
3. 基礎セットアップ：データを格納するRDBの準備
まずは、ビルド履歴を受け止める器（データベース）を作りましょう。今回は定番の PostgreSQL を例に進めます。
以下のSQLを実行して、ビルド履歴を保存するためのテーブルを作成してください。
— ビルド履歴を格納するテーブル
CREATE TABLE jenkins_build_history (
id SERIAL PRIMARY KEY,
job_name VARCHAR(255) NOT NULL, — ジョブ名
build_number INT NOT NULL, — ビルド番号
result VARCHAR(50), — 結果 (SUCCESS, FAILURE, ABORTEDなど)
duration_ms BIGINT, — 実行時間（ミリ秒）
start_time TIMESTAMP WITH TIME ZONE, — 開始時刻
node_name VARCHAR(100), — 実行されたエージェント名
created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);
— 検索を高速化するためのインデックス
CREATE INDEX idx_job_name ON jenkins_build_history(job_name);
CREATE INDEX idx_result ON jenkins_build_history(result);
CREATE INDEX idx_start_time ON jenkins_build_history(start_time);
これだけで、データを保存する準備は完了です！
—
4. HelloWorld的な動作確認：ジョブからRDBへデータを送ってみよう
それでは、実際にJenkinsのパイプラインからデータをDBに送る「Hello World」的なスクリプトを書いてみましょう。
今回は、Jenkinsのパイプライン（Declarative Pipeline）の中で、ビルド結果を取得し、簡易的にデータベースにインサートする流れを作ります。
実際の現場では、DBへの接続情報を安全に扱うためにJenkinsの「認証情報（Credentials）」機能を使いますが、今回は分かりやすさを優先して概念に集中しましょう。
サンプルJenkinsfile
pipeline {
agent any
// ビルド結果を保持する変数を定義
stages {
stage(‘Hello’) {
steps {
echo “CI/CD パフォーマンス分析のテスト中…”
// わざと成功させるジョブ
sh ‘echo “Build Success!”‘
}
}
}
post {
always {
script {
// 1. Jenkinsのビルド変数から必要なデータを収集
def jobName = env.JOB_NAME
def buildNum = env.BUILD_NUMBER
def buildResult = currentBuild.result ?: ‘SUCCESS’ // まだnullならSUCCESSとみなす
def duration = currentBuild.duration
def startTime = currentBuild.startTimeInMillis
// 2. ログに出力してみる（まずはここで値が取れていることを確認！）
echo “— BUILD METRICS —”
echo “Job: ${jobName}”
echo “Build: ${buildNum}”
echo “Result: ${buildResult}”
echo “Duration: ${duration} ms”
/
【実践のヒント】
ここから先で、Pythonスクリプトを呼び出したり、
HTTP API経由でRDBにデータを送信するリクエストを投げます。
例: sh “python3 send_to_db.py ‘${jobName}’ ‘${buildNum}’ ‘${buildResult}’ ${duration}”
/
}
}
}
}
まずはこのJenkinsfileをJenkinsに登録し、ビルドを1回流してみてください。コンソール出力にジョブ名や実行時間が表示されれば、データ収集の第一歩は大成功です！
—
5. SQLで実践！CI/CDパフォーマンスを多角的に分析する
データをRDBに蓄積し始めたら、いよいよお楽しみのSQL分析です。現場で即座に使える「役立つクエリ」をいくつかご紹介します。これを叩けば、あなたのチームのボトルネックが丸裸になります。
① 失敗率が高い「問題児」ジョブを見つける
どのジョブが一番チームの足を引っ張っているか（失敗が多いか）を特定します。
SELECT
job_name,
COUNT() AS total_builds,
SUM(CASE WHEN result = ‘FAILURE’ THEN 1 ELSE 0 END) as failure_count,
ROUND(
SUM(CASE WHEN result = ‘FAILURE’ THEN 1 ELSE 0 END)::numeric / COUNT() 100,
2
) AS failure_rate_percent
FROM
jenkins_build_history
GROUP BY
job_name
ORDER BY
failure_rate_percent DESC
LIMIT 10;
- ここがポイント：単純な失敗回数ではなく「失敗率（%）」で見るのが、ジョブの規模違いによる偏りを防ぐコツです。
② 曜日別・時間帯別の負荷（ビルド集中時間）を暴く
「いつサーバーが一番ビジーなのか」を把握し、メンテナンスやリソース増強のタイミングを科学します。
SELECT
EXTRACT(DOW FROM start_time) AS day_of_week, — 0(日曜)から6(土曜)
EXTRACT(HOUR FROM start_time) AS hour_of_day,
COUNT() AS build_count
FROM
jenkins_build_history
GROUP BY
day_of_week,
hour_of_day
ORDER BY
day_of_week,
hour_of_day;
- ここがポイント：月曜日の朝にビルドが集中していれば、トリガーのタイミングを分散させるなどの対策（分散デプロイの導入）が打てますね。
③ ビルド時間の「じわじわ遅くなっている現象（パフォーマンス劣化）」を検知する
「最近、なんかビルドが遅い気がする…」を感覚ではなく数字で暴きます。
SELECT
job_name,
build_number,
duration_ms / 1000 AS duration_sec,
start_time
FROM
jenkins_build_history
WHERE
job_name = ‘your-core-microservice’ — 調べたいジョブ名
ORDER BY
build_number DESC
LIMIT 20;
- ここがポイント：これをGrafanaなどの折れ線グラフに繋げば、依存関係のアップデートでどのバージョンからビルドが重くなったのかが一目瞭然になります。
—
6. おわりに：データドリブンなインフラエンジニアへ
お疲れ様でした！今回は「Jenkinsの実行履歴をDB化し、SQLでCI/CDパフォーマンスを分析するデータパイプライン」の基本と実装アプローチをご紹介しました。
これをマスターすれば、単に「ジョブを動かすだけのオペレーター」から、「データに基づいて開発体験を最適化するDevOpsエンジニア」へとステップアップできます。
最初は小さなジョブ1つからデータを送るだけでも構いません。ぜひ今日から試して、あなたのチームのCI/CDを次のレベルへ引き上げてくださいね。あなたの毎日の開発運用が、少しでも楽でエキサイティングなものになりますように！