RedmineとTracの比較 - wyukawa's diary

これまた今更感のあるネタですが少し調べてみたので書いておきます。比較対象バージョンはRedmine 0.9.4とTrac 0.11.7です。
あと僕は基本的にTracユーザです。といっても使い倒しているわけではありません。Redmineに関しては実戦投入したことはありません。

1. インストール
これは前提条件を明確にしておかないと比較にならないので、OSはLinuxでtracdやMongrelのような開発サーバではなくApahceに連携させるという前提にします。なのでTracLightningはのぞきます。あとSubversion使う前提にします。
この前提にたつとインストールはどっちも面倒だと思います。結局本体とは別にTracならmod_pythonやmod_wsgiと連携させますし、Redmineならpassengerに連携させるのでその辺が面倒だなと。
Redmineだとさらにマイグレーションもしないといけないですしね。まあTracは認証が面倒か。

2. 設定
これはRedmineのほうがwebベースでできるので上かな。Tracの場合はプロジェクト作るにもsshでログインしてtrac-adminコマンドたたく必要があるので面倒といえば面倒。
もっともSVN リポジトリの作成に関してはどっちもsvnadminコマンドで作る必要があるでしょう。コミットフックの仕込みもか。
Redmineの管理画面のUIがイケてないという声もあるようですが、Tracのほうがイケてるかといわれるとちょっとわかりません。Tracのほうが機能が少ないのでシンプルだとは思いますがこの辺は人によって違いそう。

3. 複数プロジェクトの扱い
これはRedmineのほうが上。webベースでプロジェクトを作成できるし階層化もできる。Tracユーザでもこの機能が欲しいと思っているひとは多いでしょう。
基本的にRedmineはTracと比べて高機能です。でもTracもプラグインを使えばたいてい同等のことはできます。でもこれに関してはできない。後述のTraMを使えば近いことはできるけどちょっと違う。というか階層化はできない。ものすごく乱暴に言うとこの機能以外はRedmineもTracも大差ないw

でもこの機能をうまく使うにはノウハウが必要な気がします。

まずどうしてこの機能が欲しいかということを掘り下げてみます。

大規模開発ではチームごとにコンポーネントを開発することが多いでしょう。その場合１つのプロジェクトしかない場合はチケットやタイムラインが追えない。これがまず問題。Tracの場合はてきめんにそう。

SVN リポジトリ構成はたいていは

http://.../svn/ProjectA/
    |
    |--------trunk/
                 |--------ComponentA/
                 |--------ComponentB/

だからhttp://.../svn/ProjectA/trunk/ComponentAを１つのチームが管理するプロジェクトとして扱いたい。
http://.../svn/ProjectA/trunk/ComponentBは別チーム管理なので別プロジェクトにしたい。ただし相互を統合して見えるようにもしたいわけです。

SVN リポジトリ構成が

http://.../svn/ProjectA/
    |
    |--------ComponentA/
                            |--------trunk/
                            |--------branches/
                            |--------tags/
    |--------ComponentB/
                            |--------trunk/
                            |--------branches/
                            |--------tags/

だとしたらhttp://.../svn/ProjectA/ComponentA/を１つのプロジェクトとして扱いたいわけです。

RedmineはTracと違ってSubversionとの関連が疎なので柔軟にプロジェクトを構成することができます。
Tracの場合は0.11まではプロジェクト(Trac Environment)とSVN リポジトリの関連が１対１なのでRedmineのようにはいきません。
やるとすればTraMを使いますが、この場合複数のプロジェクト(Trac Environment)を作ることになるので複数のSVN リポジトリも作ることになります。
Redmineのように１つのSVN リポジトリに対して複数のプロジェクトという構成にはできない。

しかし5月末にでると噂のTrac 0.12にはマルチリポジトリという機能があります。これはRedmineには無い。これは１つのプロジェクト(Trac Environment)に対して複数のSVN リポジトリを持てるという機能です。

つまりSVN リポジトリ構成を

http://.../svn/ComponentA/
    |
    |--------trunk/
    |--------branches/
    |--------tags/

http://.../svn/ComponentB/
    |
    |--------trunk/
    |--------branches/
    |--------tags/

として２つのリポジトリに対して１つのプロジェクト(Trac Environment)を作ることができます。リポジトリ単位でタイムラインも絞り込めます。チケットもコンポーネント単位で絞り込めば大規模になった場合にチケットやタイムラインが追えない問題は解消するような気がします。

現場に求められているのが複数プロジェクトなのか複数リポジトリなのかを見極めるのが大事でしょう。難しいけど。複数プロジェクトのデメリットはプロジェクト間の関連が薄くなることだと思います。かといって１つにちゃったら振り出しにもどってしまう。その中間に位置するのが複数リポジトリなのかなと。
リポジトリを分割するとメンテが面倒になりますけどね。ただ柔軟性は増す。この辺のバランスが大事。

3. ワークフロー管理
Tracはnew → accepted → assigned → closedというフローなので解決済みとかレビュー待ちといったステータスがなく、それをやるために管理者以外はチケットをクローズしないという運用ルールを定めるか、難しいと評判の？ワークフローのカスタマイズをするしか無かったわけです。

Redmineの場合はweb上のUIlからワークフローをカスタマイズできるのでそこは上。もっとも現状のTracのワークフローでいいじゃんという僕のようなものぐさな人にとってはあまり興味がわかない話ではあるw

4. チケット機能
Remineの場合はデフォルトでガントチャートや工数管理機能が含まれている。
Tracの場合はGanttCalendarPluginとTimingAndEstimationPluginを使う。
どちらにせよ進捗率で計るのならタスクを分割せよがベストプラクティスのような気がするので進捗率80%とかは入力しないのがいいみたいです。てか僕なら入力しない。だって面倒だもんw　

もっと言ってしまうとガントチャートはBTSにはいらなくてMSProjectでよくねって最近思ってる。なんでかっていうとそっちのほうが鉛筆なめやすいでしょってこと。
顧客や上司に見せるであろうガントチャートってあまり細かいタスクは不要なのでチケット単位で出してもしょうがない。7月ごろ出ると噂のRedmine 1.0にはチケットの親子関係が定義できるSubtaskingが導入されるため親チケットだけを表示したガントチャートと子チケットも含めたガントチャートは作れると思うけどそれをメンテするのって大変だと思うんだよね。コストメリットがあわない気がしている。だからガントチャートはMSProjectで鉛筆なめなめしたやつでエイやで作って、チケットと連動させる必要は無いかなと。

5. バージョン、マイルストーン

Tracにはバージョンとマイルストーンという概念がある。１つのバージョンに複数のマイルストーンを割り当てることが多いだろう。バージョン1.0に対してマイルストーンが結合テストとか総合テストとかね。
Redmineにはバージョンしかない。これはどっちが上とかいうよりも好みとか現場の状況次第かな。

6. レポート出力
TracはSQLを駆使すればいろんなレポートを作れるけど、まあそこまでしないんならTracもRedmineも変わらないかなと。

7. ボータビリティ
TracはプロジェクトごとにSQLiteのDBファイルが１つなのでボータビリティは高い。Redmineはプロジェクト毎にDBが分かれているわけではないのでそこはちょっと面倒。

8. Wiki機能
Tracも0.11まではテーブルヘッダが無いなどWikiが貧弱といわれていましたが、5月末にでると噂のTrac 0.12ではその辺強化されています。ただ改行するのにいちいちBRを書かないといけないのは面倒だと思います。

RedmineもWiki以外に文書があって使い分けに困るかなと。

違いは
ニュース・文書・Wiki・フォーラム - バリケンのRuby日記 - Rubyist
ということらしいです。文書はSVNかファイルサーバに置く気がしますけどねえ。

あと階層を
tetu-blog: Redmine Wikiで親子階層表示を試す
とやらないといけないのは面倒な気がします。

8. Hudsonとの連携、コードレビュー

RedmineとTracの機能比較〜コードレビュー、Hudson連携 - wyukawa’s blog
に書いたけどRedmineのほうが上かな。

9. 日本語の情報

これはTracのほうが最初に出たこともあって情報量が豊富だと思います。
Shibuya.tracというコミュニティもありますしね。

RedmineもRedmine.JP — Redmine日本語情報サイトやGoogle グループがあるのでそんなに困ることは無いでしょう。

日本語書籍でいうとRedmine、Tracとも２冊ずつでてますね。

入門Redmine Linux/Windows対応

作者: 前田剛
出版社/メーカー: 秀和システム
発売日: 2008/11/26
メディア: 単行本
購入: 4人クリック: 129回
この商品を含むブログ (48件) を見る

Redmine -もっと手軽にプロジェクト管理!

作者: 倉貫義人,栗栖義臣,並河祐貴,前田直樹
出版社/メーカー: インプレス
発売日: 2009/07/24
メディア: 単行本
購入: 6人クリック: 245回
この商品を含むブログ (31件) を見る

入門Trac第2版Linux/Windows対応

作者: 高山恭介
出版社/メーカー: 秀和システム
発売日: 2009/08/25
メディア: 単行本
購入: 1人クリック: 53回
この商品を含むブログ (12件) を見る

Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイド

作者: 菅野裕,今田忠博,近藤正裕,杉本琢磨
出版社/メーカー: 技術評論社
発売日: 2008/09/18
メディア: 大型本
購入: 23人クリック: 233回
この商品を含むブログ (88件) を見る

Redmineの紫本とTracの赤本は使い方を中心に書かれた同じ位置づけの本で、Redmineのぶどう本はAmazon EC2での動かし方やプラグインの作り方などが書かれたちょっと特殊な本。Tracの白本は運用方法についても書かれた良書でこれに対応するRedmine本は無いです。

10. アーキテクチャ、ソース
RedmineはRailsで作られているわけですがソースはそんなに奇麗ではないようですw　まあ実際に見たわけではないので正確なことはいえません。今度見てみたいと思います。
Tracはフレームワークを使わないで独自に作っているわけですが、アーキテクチャが一貫しているためかソースは読みやすいです。ただしコンポーネントアーキテクチャを実現しているメタクラス全開なcore.pyはのぞく。
例えば管理画面ならtrac/admin/web_ui.pyのAdminModuleというプラグインで、Wikiならtrac/wiki/web_ui.pyのWikiModuleというプラグインで実現されています。プラグインの作り方のおまじないを覚えればなんとなくわかるかなと。

11. リポジトリブラウザ
Tracのほうが上という声があるようですが、svn mergeinfoを表示できる以外はRedmineとそんなに大差ないかなという気がします。

12. デザイン
これはRedmineのほうがクールな気がしますね。コンテキストメニューでチケットをいじれるのもなんかかっこいい。

13. 本体の開発スピード
ま、これはRedmineが上だな。Tracは停滞している感が否めない気がします。

ええと、いろいろ書いてきて読み返す気力もなくなってきましたがw　無理矢理まとめると

複数プロジェクトが扱えるなど高機能でガントチャート、工数管理がデフォルトであってPM受けがいい、きっちり管理したい人に向いている、でもマメじゃないと厳しいかもっていうのがRedmineです。
一方プラグインが充実していて（これは本体のバージョンアップに追随できない可能性があるというデメリットもある）、ルーズに管理したいというガサツな人に向いているというのがTracです。

ああなんか全然まとまってないけどまあいいやw

参考

RedmineとTracの機能比較: プログラマの思索
 RedmineとTracの機能比較part2～ポータビリティ、プラグインなど: プログラマの思索
 なげやり日記: TracとRedmineの比較
 Redmineはもっと評価されていい - 謀跡地
 Trac vs Redmine - Global Wiki