Redmineを業務システム化するアイデア～メトリクス集計の本質は集計バッチ処理

IPAの定量的プロジェクト管理ツール概要やさかばさんの記事を読みながら考えたことをメモ。
ラフなメモ書き。
間違っていたら後で直す。

【元ネタ】
Jenkinsの特長 - メトリクス収集サーバの視点から -: ソフトウェアさかば

InfoQ: 継続的デリバリのパターン

定量的プロジェクト管理ツール概要 Lt 20110730

View more presentations from hiroetoh

マネージャから以前、ベースライン単位にタスクの進捗や課題の状況を履歴表示できないか、という問合せを受けた。
彼の意図としては、ベースライン(プロジェクトのマイルストーン)単位に集計して、予定と実績の差を見たいということだった。
僕は、現状のRedmineでは力不足です、と答えた。

その理由は、Redmineのチケット集計機能はユーザが画面表示した時点のチケットの状態を集計表示する機能だけであり、集計結果を履歴表示する機能はないからだ。
バーンダウンチャート、チケットの登録・完了の累積数、ロードマップスなどのプラグインはあるが、マネージャが欲しい機能はもっと複雑な集計結果の履歴が欲しいのだ。
しかも、その集計結果の履歴をExcelで出力できるようにしたい、とのことだった。

Redmineによるチケット駆動開発を単なるAgile開発ではなく、ソフトウェア開発の業務システムへ拡張しようとすると、もっと複雑な集計処理が必要になる。
IPAは定量的メトリクス収集ツールをRedmineの一機能として作ろうとしているが、その背後にはそういう動機があるのだろうと思う。

だが、集計結果の履歴を保持する機能を実装するのはとても難しいのが現状だろう。
その理由は、業務システムのバッチ処理のように、日次・月次などのようなタイミング(マイルストーン)でフロントで入力されたデータをバッチ処理で集計する処理が必要だからだと思う。

Jenkinsの特長 - メトリクス収集サーバの視点から -: ソフトウェアさかばにもその理由が一部書かれている。

業務システム開発で最も難しいのは、Webフロント側よりもバッチ処理の設計と開発だ。
バッチ処理はアーキテクチャ設計がほぼ全てなので、設計がまずいといくら開発しても無意味。
しかも大量データを集計するから、処理の負荷やシステム運用も考慮しなければ、使い物にならない。

Redmineをソフトウェア開発の業務システムにするには、最終的には集計処理をバッチ化する機能が必要だろうと思う。
そのイメージは下記の通り。

Redmineを業務システム化するアイデア

View more presentations from akipii Oga

チケット入力などのように集計の元ネタとなるデータは、PGがWeb画面から入力する。
その入力データを定期的(日次・月次)に集計バッチ処理が一括処理して、集計用データを作る。
その集計用データをPLがWeb画面から一覧表示して見れるようにするイメージ。

この時のポイントは、幾つかある。
バッチ処理をキックする処理はCIツールで代用した方がいいこと。
バッチ処理そのものはストアドでもいいし、Perl/Rubyなどのスクリプト言語で作ってもいいが、CIツールでキックできるようにしておけば、いろんな操作が可能だし、拡張もしやすい。

また、集計バッチ処理もJenkinsのプラグイン、そして一覧表示処理はRedmineのプラグインにしてしまった方がいい。
変にカスタマイズしたフレームワークを作るよりも、JenkinsやRedmineのプラグインにした方がインストールも簡単だし、別の開発者にも流用しやすい。
特にRedmineはRailsで作られているから、Redmine本体のテーブルはそのまま変更せず、集計バッチ用のテーブルを新規に追加する設計にすればいいだろう。
そうすれば、Redmine本体がバージョンアップしても、集計バッチとRedmineのインターフェイス部分だけ修正すればいいので保守コストは大きくないはず。

【元ネタ2】
「リポジトリ」を開くまでSubversion等のリポジトリへのコミットが「活動」に表示されません | Redmine.JP

小技(0.9): コミットと同時にリポジトリの情報を取得する | Redmine.JP Blog

Subversion Plugin - Jenkins - Jenkins Wiki

Twitter / @akipii: @haru_iida @yando @daipresentsさんが書かれているように、Redmineを大規模組織で使う場合、Redmineが業務システムになるが故にWebサーバーやSCMリポジトリなどのインフラ管理がボトルネックになってきます。TiDDの今後の課題ですね。

Twitter / @akipii: JenkinsのSubversion PluginでPost-commit hookを設定できるのか。この運用はTiDDにおけるNo Ticket No Commitをサポートしてくれるから非常に重要。

post-commit-hookはチケット駆動開発の発端となった機能だけにとても重要だが、post-commit-hook後にチケットとリビジョン連携の実装方法はいくつかある。
最も簡単な方法は、SCMコミット後に、ユーザがRedmineのリポジトリ画面をリフレッシュするタイミングで、SCM連携すること。
この方法では、開発者が逐一画面を開かないといけないので、運用が面倒な弱点がある。

もう一つの方法は、RedmineのWebサービス機能を使って、SCMコミットをトリガーとしてHTTP経由でSCM連携させること。
この方法なら、開発者がリポジトリ画面をリフレッシュする動作は不要になる。
しかし、SCMコミットの量が大きすぎたりすると、Redmine本体がダウンしてしまう可能性もある。

三つ目の方法は、JenkinsのSVNプラグインのように、CIツールでpost-commit-hookの機能を実施すること。
CIツールを使う利点は、SCM連携させるタイミング(トリガー)をイベントフックにしたり、定期的なタイミング(例えば5分おき)に変えたりできること。
また、バッチ処理化することで、大量データの処理も可能になること。

今後実現して欲しい機能は、RedmineにあるSCM関連のテーブルへデータ移行させるバッチ処理を作って、CIツールでキックするようにしたいこと。
そうすれば、例えば、プロジェクトの途中からRedmineと既存SCMリポジトリを組み合わせて運用したい場合、CIツールでSCMデータをRedmineへあらかじめデータ移行すれば、問題なく運用を開始できる。
また、もしSCMコミットの量が多い場合でも、例えば夜間にCIツールでSCMデータ移行のバッチ処理を実施すればいいだろう。

Redmineでソフトウェア開発のプロジェクト管理を運用していくと、運用対象が大規模組織になるほど、多分、集計バッチ処理のような機能が必要になってくると思う。
集計バッチ処理はとても複雑だが、我々SIが受託開発でやっているバッチ設計と所詮同じだ。
プロジェクト管理の問題をどこまでソフトウェアで解決できるのか、試してみたい。

【追記】
CIツールでSCM連携する場合、トリガーはpost-commit-hookのようなユーザのイベントだけでなく、ポーリングのようにCIツールがイベントを探して検知する方法もある。
CIツールをCron(定期的なタイマー(例：日次・月次))のように扱うだけでなく、ポーリングのように賢いツールが自動検知してくれる方が運用は楽。

ポーリングとは【polling】 - 意味/解説/説明/定義 ： IT用語辞典