Redmineのマイクロコア化は可能か~Redmineを開発基盤にして追加機能は着脱可能コンポーネントにできるか
Redmineへの機能改善の要望への対処、保守コスト増に対する対処について、色々考えている。
以下、ラフなメモ書き。
特に主張なし。
【1】下記2点について考えてみる。
2)機能改善の要望への対処
3)保守コスト増に対する対処
大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響: プログラマの思索
【2】Redmineの機能改善の要望は、ガントチャートとメトリクス集計が多い。
普通、マネージャやPMO、品質保証の立場の人から、下記の要望がよく出る。
ガントチャートでWBSをExcelやMSProjectのように綺麗に表示したい。
ガントチャートをもっと分かりやすく表示できないか。
毎月の部長向け報告で、各案件の作業実績、障害件数、QA件数をサマリで報告したい。
Redmineにある情報を一発で上手く取得できないか?
個人的には、都度対応している。
【2-1】ガントチャートはパッチで対応している。
ガントチャートの日付表示パッチ(但し、Ver3.2からデフォルト機能なので不要)、ガントチャートの左欄の枠の幅を広げるパッチを直接ソースにパッチを当てたりする。
vividtone/redmine_gantt_with_date: replace cweek with day on the gannt chart.
Redmineでガントチャートの幅を広げるパッチ: プログラマの思索
他にも、ガントチャートの左欄の枠に担当者を表示したい、ガントチャート画面上で編集したい、などたくさんの要望もある。
このレベルになると、パッチ当ては不可能。
既に有償プラグインがいくつか公開されているので、プラグインを入れる方が早いし、安定するだろう。
Redmine Lychee Enterpriseシリーズの解剖part1~Redmineの本来あるべきガントチャート機能 Lychee Gantt Chart: プログラマの思索
Redmineのもう一つのガントチャートプラグインEasyGanttのリンク: プログラマの思索
もう一つのRedmine製パッケージ製品ANKO REDMINE: プログラマの思索
Redmine本家にも以前から、ガントチャート上の編集機能の要望チケットはあるので、いつかは取り込んで欲しい。
Feature #2024: gantt chart editing - Redmine
【2-2】メトリクス集計は、二つやり方があると思う。
一つは、サーバーサイドで、REST APIを使ったスクリプトで集計処理を行うこと。
松谷さんのやり方のように、Redmineサーバー上でREST APIでチケット情報を取得、集計するシェルスクリプトを買いて、gnuplotでビジュアルに表示するやり方が上手いと思う。
サーバーでCSVを出力できれば、gnuplotで色んなグラフで描画できるし、外部サーバーのBIツールにCSVを食わせてビジュアル表示させることもできる。
Mattani/MetricsTools_for_Redmine: Perl and gnuplot scripts for calculating Metrics for Redmine
第10回redmine.tokyoの感想~Redmineユーザはメトリクスがお好き #redmineT: プログラマの思索
RedmineのチケットデータをRedmine外部のBIツールで表現するアイデア: プログラマの思索
もう一つは、全チケットをCSV出力して、Excelマクロで加工すること。
プロジェクトリーダーは、自分の管理作業を楽にするために、自作のExcelマクロを持っている人が多い。
例えば、ガントチャートを表示したり、EVMを出力したり、工数管理する集計マクロを持っている。
そういうツールを持っているから、彼らはプロジェクト管理を効率化するノウハウを自分なりに蓄積しているのだ。
特に、週次・月次レベルで、障害件数やタスクの消化率を報告する場合が多いので、Excel上でvlookupを使ったり、ピボット集計する場合が多い。
すると、彼らに元ネタとなるCSVを渡せば、好きなようにいくらでも集計してくれる。
そのような運用でカバーした方が早いと思うし、Redmineシステム管理者の保守の作業負荷も下がると思う。
【2-3】つまり、メトリクス集計のような機能は、Redmineの外部で実装した方がいいと思う。
その方が、Redmine本体のVerUp、Redmineの性能悪化などの影響を受けにくいからだ。
たとえば、RedmineのチケットデータをCSVで出力し、外部のBIツールに食わせて、ビジュアルに表示させる方法も一つの手段として実現できる。
しかも、RedmineのREST APIでデータをやり取りするように、Redmineとメトリクス集計機能を疎結合な設計にしておけば、カスタマイズもやりやすいはずだ。
【3】他に、Redmineの保守コストが大きくなっている、という指摘も多い。
【3-1】実際、一つのチームで10人以下でRedmineを運用しているなら、保守コストは、一つの案件の管理作業の中に含められるだろう。
しかし、Redmineを長く使っていくと、普通のWebサーバーの保守作業が必要になってくる。
例えば、バックアップ、リストア、VerUp、移行作業など。
なお、バックアップ作業は下記が参考になる。
Redmineなど汎用的に使えるバックアップ処理(shellscript+cron+rsync) - Qiita
特に、VerUp作業のコスト増が大きな問題になってくるだろう。
なぜなら、Redmine本体のVerUpが頻繁にあるものの、プラグインを入れているとそう簡単にVerUpできなくなるからだ。
本当は、VerUPによって、数多くの機能改善がなされているから、その恩恵を受けたいのに。
また、VerUp作業を行うには、Redmine自体を一時的に停止する必要が出てくる。
すると、Redmineが開発業務の基幹系システムと同じような重要性になってしまった場合、そう簡単にサービスを停止することも出来ない。
Redmine以外にも、RubyやRailsのVerUpも激しいために、RedmineのVerUpはそれなりに難しいかもしれない。
【3-2】Redmineの保守コストが大きいと感じられてくると、Redmineの保守作業を専門化するチームを設けたり、外部に委託したくなってくる。
その時に、Redmineを捨てて、他のパッケージ製品に切り替える判断も出てくるだろう。
BacklogやJiraの製品では、Redmineからの移行ツールも用意しているみたい。
「JIRA Redmine Importer」プラグインで Redmine からインポート - Atlassian Japan
Backlogへの移行ツール作るためにScalaとAkkaを使ったら便利すぎた! - ヌーラボ [Nulab Inc.]
【3-3】Redmineがこれらのパッケージ製品よりも保守作業が楽である、という特徴を出すには、何が必要なのか?
RedmineのVerUp作業を楽にするには、昨今の継続的デリバリに関するノウハウを生かして、「ブルーグリーン・デプロイメント」「Immutable Infrastructure」の仕組みを導入するとか、色々あるだろうと思う。
継続的デプロイ&ダウンタイムなしのデプロイのために - Qiita
DevOps時代の開発者のための構成管理入門(終):継続的デリバリ/デプロイを実現する手法・ツールまとめ (2/2) - @IT
【4】メトリクス集計の機能追加、保守作業の効率化などを考えると、Redmine本体を一つのマイクロコアないし開発基盤として独立させて、カスタマイズしたい機能はRedmineの外部で実装できるような仕組みが必要ではないか、と思う。
つまり、Redmineを開発基盤にして、追加機能は着脱可能コンポーネントにしてしまいたいのだ。
u6k_yu1さんのツイート: "@u6k_yu1 思うにRedmineてマイクロコア化して構造を安定化して、プラグインで色々実現してくれた方が良いのではないかな。"
Redmine本体を一つの開発基盤を見なす考え方は、以前発表したことがあったけど、もう少し深く考えてみたい。
Redmineを電源コンセントやUSBポートみたいに、簡単にプラグインを抜き差しできるような仕組みとして考えてみたいのだ。
Redmineの裏の顔~開発基盤としてのRedmine: プログラマの思索
【公開】第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine~Redmineをカスタマイズするポイント」 #47redmine: プログラマの思索
| 固定リンク
「Redmine」カテゴリの記事
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- Redmineで持ち株管理する事例(2024.04.21)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
「ソフトウェア工学」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
コメント