Jenkinsでプロジェクトの状況をウォッチするRedmineMetricsPlugin
Jenkinsでプロジェクトの状況をウォッチするRedmineMetricsPluginが公開されていたのでメモ。
【元ネタ】
Jenkinsでプロジェクトの状況をウォッチする - mitoma_ryoの日記
RedmineMetricsPluginはJenkinsのプラグインで、Redmineのチケット情報を元にバージョン単位にステータスごとのチケット推移を表示してくれるらしい。
このプラグインを有効活用するには、バージョンをフィーチャないしビジネス要求単位に作る方がグラフが意味あるものになるだろう。
似たようなメトリクスとしてパーキングロットチャートがある。
パーキングロットチャートはバージョンをビジネス要求に対応付けて、バージョン単位にざっくり集計したメトリクスを出してくれる。
それに対して、RedmineMetricsPluginは同じビジネス要求単位だが、ステータスごとの遷移を出力するのでより詳細なメトリクスを表示してくれることになる。
TiDD初心者によく聞かれる質問part2~チケットの粒度はどれくらいが妥当ですか?: プログラマの思索
@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を解読してみる #RxtStudy #47redmine: プログラマの思索
RedmineMetricsPluginプラグインを作成した背景は以下のように書かれている。
(引用開始)
システムの開発現場では「プロジェクトのタスクがどのように推移していて、どのようなフローで消化される傾向にあるか。今どれぐらいのタスクが残っているのか、それらのチケットのステータスはどうなっているか」が知りたい場面が多いです。
特にリリース直前のリリース判定会などでは「今、残不具合はN件でM日で修正できる予定です」という報告をもらっても「M日で修正できるならリリースに間に合う」という判断を行うには材料が足りません。
「不具合は今日までにどのような勢いで発生しているのか、日々不具合が報告されているのか、既に報告される数は落ち着いているのか」が分からないと、現在のチケット数だけでは正しい判断ができないのです。(それが分かったから正しい判断ができるかというとそういう訳でもないのですが。)
で、なぜJenkinsのプラグインになったかというとアイデア元は「Jenkinsをメトリクス収集ツールとして使うアイデア」です。
<JenkinsはSVN・Mercurial・GitのようなSCMリポジトリをインプットにするが、RedmineやTracのようなITSのDBもインプットに入れれば、ITSのDBからデータをロードしてバッチ処理を行うことも可能のはずだ。
ITSのチケット集計機能はリアルタイムな集計しかできないけれども、そのようなアイデアを実現出来れば、バッチ処理を行う集計結果も可能になる。>
ITSの機能でチケット数の推移やそのOpen/Closeの割合まではグラフ化することができるものもありますが、チケットのステータスの推移を見るにはバッチ的に集計する必要があるので、高機能なCronであるJenkinsの方がいいということです。
(引用終了)
僕のアイデアが役立ったのなら、とても嬉しいことだ。
個人的には、JenkinsはRedmine以上に色んな可能性を秘めていると思っている。
| 固定リンク
「ソフトウェア」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること(2022.02.09)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
「Redmine」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
コメント