[ Redmine index ]
RedmineとTracとの比較
主にソフトウェア・プロダクトに対する障害管理（Bug Tracking）、課題管理（Issue Tracking）、および開発管理（Project Support）に使用するツールとして、RedmineとTracが候補に挙がる。しかし、このどちらを選択するかとなると、なかなか判断基準がないのが現状である。そこで、選択にあたっての判断材料を提供するために、双方の機能及び性能を比較する。
2012年4月〜5月執筆のため、対象バージョンはTracが0.12.3ja、Redmineが1.4.1である。
もともとBTS（Bug Tracking System）と呼ばれるバグ（障害）管理ツールから出発しているが、チケット管理機能はかなり汎用的な機能であることから、障害だけではなく、問題／課題管理（Issue Tracking System）にも応用した使い方をされるようになり、さらに、チケット駆動開発のように開発作業（タスク）を管理するように発展している。
障害発生毎にチケット（障害票・バグ票・不具合票などとも云う）を起票し、以後障害に対する処置状況を管理する。管理にあたって、発生件数、解決件数を定量的に表す。
障害の修正については、障害管理とバージョン管理とを連携し、ある修正がどのバージョンで反映されたか、および、どのモジュール（プログラム）が修正されたかを紐づけることが望ましい。
障害のチケット管理を進めていると、障害だけでなく、解決すべき課題（問題）をチケットとして管理できないか、との思いが湧いてくる。チケットで管理することにより、担当・期限・進捗が明確になる。
課題（問題）の場合、チケットの状態遷移（ワークフロー）が障害修正とは違うことが多い。例えば、客先への仕様問い合わせ確認、物品の調達、など。
課題管理をさらに進めると、開発作業（タスク）をチケットとして管理できそうに思えてくる。チケット駆動開発として提唱されている手法で開発管理を進める場合、チケットの状態遷移（ワークフロー）がさらに多様となる。例えば、調査、実験、作業、資料作成、設計、試験、会議、などである。
また、チケット化した作業の結果をチケットから辿ること、チケットの進行を周知する、作業結果のレビューなどの開発行為を支援することも必要となるため、Wiki、掲示板、メールとの連携などが必要になる。
著者は、TracよりもRedmineに習熟している。TracはLinux上での構築、チケット駆動開発に用いようとして数か月で頓挫、後日障害管理として数か月使用した経験がある。RedmineはLinux上での構築、障害管理として1年使用、チケット駆動開発で1年半使用した経験がある。そのため、Redmine寄りの観点となる点は否めない。
RedmineもTracもプラグイン機構を備えているため、プラグインを導入すればできなかった機能がいくつもできるようになる。そのため、「Redmineには△△機能があるがTracにはない」と言うと、「いや、Tracに△△△プラグインを入れれば△△機能が実現できる」というコメントが付く。プラグインまで含めた機能比較になると際限がなくなる事態となる。
本記事において、プラグインについての観点は、プラグインを複数組み込むとプラグイン同士の干渉による問題のリスク、バージョンアップ時の追随遅れ（追随なし）の問題のリスクがあるとの立場とする。プラグインについては、拡張性という機能に一括りにし、標準機能についての比較とする。
Tracについては不利だとのコメントが付くだろう。Windows OS用にはTracLightningのようにプラグイン込みでリリースされるTracもある。しかし、それはTracLightningとしての比較であり、本記事の比較対象にはTracLightningは含まない。
多数の開発者がいるソフトウェア開発プロジェクトにおいて使用することを踏まえ、Linuxプラットフォームでの稼働を想定する。
Windows OSについては、Windows XP/Vista/7の使用許諾書における同時接続最大数／最大デバイス数の制限とApache等サーバーアプリケーションの関係がグレーであることから、Windows
Server OSでの稼働が望ましい。しかし、Windows Serverは費用がCALを含めてそれなりに必要となる。
Redmineはほとんどの管理作業をRedmine上で（ブラウザ上で）操作できる。
Tracはほとんどの管理作業をTracを動かしているOSのコマンドライン上で操作する。つまりブラウザ上での管理操作はほとんど用意されていない。
管理者がUNIXに長けていれば、コマンドラインが充実していることで自動化のスクリプトなどの作成が可能になるTracは便利である。しかし、UNIX／コマンドライン環境を扱えない管理者にとってはWebからの操作で完結するRedmineが便利である。RedmineかTracかの比較において、特にTracを選択したい場合に、この点を銘記せねばなるまい。
Redmineは、管理機能からプロジェクトを複数作成し、プロジェクト間の階層を定義しチケット等の共有を制御する。
つまり、同じデータベース上に複数のプロジェクトを定義し、プロジェクト間で互いに情報を共有することができる。共有する範囲を階層に対して指定可能である。
例えば、開発全体の管理をするプロジェクトと、その子プロジェクトにコンポーネント別プロジェクトを作成するといった活用が考えられる。
Tracは、コマンドラインからプロジェクトを別ディレクトリに作成し、Apacheのエイリアスでアクセスを振り分けたものとなる。
つまり、プロジェクト毎にデータベースは分離され、プロジェクト間で情報共有はできないと思われる。
障害チケットのチケット番号が1番から始まっていないことにケチをつける組織風土ではTracの方がよいかもしれない、と思ったが、手間を考えるとRedmineを複数立てるのと差はあまりないかもしれない。
障害管理／課題管理として運用する場合、プロジェクトは全体で1つでないと困る。
一方、開発管理として運用する場合は、開発チームが複数ある大きなプロジェクトで他のチームの詳細な作業チケットがタイムラインに入ってくるとノイズになるので、チームごとにプロジェクトを分割したくなる（ただし全体共通も必要）。
Redmineは、ツール上でWeb画面を通してユーザー管理を行う。
Tracは、ApacheのBASIC認証またはDigest認証ユーザーを作成し、Trac側ではそのユーザーに対する権限を指定するという管理方法である。
Tracの場合、Webサーバー（通常Apache）のユーザー認証設定を行う必要があり、管理者がUNIX管理技術を持っていないと実質管理不可能である。
Redmineは、チケットの種類（トラッカー）に対して別々なワークフローを定義できる。
Tracは、ワークフローは1つだけ定義できる。
どちらもワークフローのカスタマイズが可能である。
障害管理だけに使用するなら、ワークフローは1つで運用できるが、課題管理、開発管理に使う場合、ワークフローは複数必要となる。例えば、顧客への照会、などは「問い合わせ中」、「回答済み」といったステータスがほしくなる。ワークフローが1つしかない場合、ステータスを読み替えるか、チケット本文へのコメント記述でカバーするなど運用で回避する手段が必要になる。
Redmineには開始日、期限、進捗率のフィールドがデフォルトで用意されている。進捗率は自由記述のほか、チケットのステータスで所定の数値を自動で設定することも可能である。
Tracでは、カスタムフィールドでこれらを作成することになる。
Redmineでは、日付をカレンダーからGUIで指定できる。
Tracでは、キー入力する。
Redmineでは、チケットに対して他のチケットとの関連（関係、ブロック、重複、先行、後続など）を設定できる。設定すると、相互リンクとなる。
Tracでは、チケット間の関連付け機能はないので、チケットのコメントにリンクを記述することになる。相互リンクの場合、2つのチケットに手動で設定する必要があるので、メンテナンスが厳しい。
障害管理において、類似した障害、重複した障害などは多数発生するので、相互リンク機能はあると重宝する。
Redmineは、チケットを階層化する機能があり、子チケットの情報を集計して親チケットに反映する。例えば、子チケットの進捗率を自動集計して親チケットの進捗率とする、などである。ガントチャート上にもWBSの階層のように表示される。
Tracは、階層化機能はない。
障害管理／課題管理として使用する場合、チケットの階層化（親子チケット）はなくてもよい。
開発管理では、作業のブレークダウンが欠かせないので、チケットの階層化は必要となる。
Redmineでは、チケットのサマリーで、トラッカー／優先度／担当者／作成者／バージョン／カテゴリ別に、未完了・管理用の集計をみることができる。
Tracでは、Wチケットのレポート、たとえばあるコンポーネントの総チケット数、終了数を集計し表示するのに便利なクエリ機能が用意され、Wikiページ中に任意の場所（例えば表の中）に挿入できる。
RedmineもTracも独自記法（正確には、Redmineはtextile記法）であり、他のWikiに馴染んでいると移行に抵抗があると思われる。
日本語で記述するときの改行の扱いについては、Redmineは改行はそのまま改行されて表示されるが、Tracは１つの改行は空白に置き換えられ文が継続する（HTMLの記述に近い振る舞い）ので、Redmineの方が自然かもしれない。
Trac Wikiで当初ソースコードを記述しても文法による色づけができなかった。PythonのSilverCityモジュールPygmentsモジュールを別途インストール（CentOS 6の標準パッケージ python-pygments）することで色づけされるようになった。
Redmineは、ページの属性に親ページがあり、親ページを指定すると階層構造をとることができる。階層構造とすると、パンくずリストが生成される。Wikiページ名は何でもよい。Pukiwikiなどのように階層構造をページ名（スラッシュ区切り）で表現しているわけではないので、階層を変更した際にページ名を変更する必要はなく、そのページへの既存リンクの変更も不要である。
Tracは、Wikiページ名で階層構造を表現する。Wikiページへのリンクは、階層構造を含めた名前になるので、階層を変更したらリンクも変える必要がある。（古いページをリンクのために残すオプションはあるが・・・）
開発管理で用いる場合、Wikiを開発情報共有のために多用するが、情報を整理するため階層構造を積極的に使いたい。ただし、開発途中では階層の見直しも頻繁に行うことになる。
Redmineは、日付入力をカレンダー上から選択することができる。
Tracは、yyyy/MM/dd形式で入力する必要がある。
大した手間ではないが、期限などのスケジュールをにらんだ日付を入力するときは、カレンダーを見ながら入れるので、Redmineの方がうれしい。
RedmineもTracも、リポジトリに修正をコミットする際、コミットログにチケット番号を所定の書式で記述しておくと、リポジトリとチケットの紐づけができる。
Redmineは、リポジトリへのコミットログにチケット番号が所定の書式で記述されていたら、そのチケットにリポジトリの対象コミットへのリンクが自動で追加される。
Tracは、この機能はない。
Redmineは、ネットワーク上のリモートにあるリポジトリを使用可能である。
Tracは、同じマシン上にあるリポジトリを使用可能である。
Subversionは開発終盤になるにつれ負荷が高くなるので、場合によってはTracとSubversionサーバーが稼働するマシンを分離したいということもある。それが採れない場合、マシンスペック向上しかなくなる。Tracの場合、初期に十分性能のよいマシンを確保するのがよさそうである。
Redmineは、Subversionの他、CVS、Mercurial、Bazaar、Gitにも対応している。
Tracは、Subversionが対象である。
Redmineは、ニュース機能があり、プロジェクトの連絡事項などに活用できる。
Tracは、この機能はない。
Redmineは、オンラインで議論するための機能がある。
Tracは、この機能はない。
Redmineは、メール通知の条件を設定できるので、チケットの状態が変わった時に通知する対象を柔軟に制御できる。チケットに対してウォッチャーを指定し、ウォッチャーにメール通知を行うことや、自分が変更したチケットは自分へのメール通知をしない、あるいはプロジェクトのすべての変更をメール通知されたい、といったことも可能である。
Tracは、メール通知を有効にすれば（デフォルト無効）、チケットの状態が変わった時に担当者、関係者、報告者にメール通知される。
環境はどちらもLinux上とする。今回は、AMDの4コア・プロセッサ上で、ホストOS CentOS 6 KVM上にゲストOS CentOS 6を複数立て、そこにRedmineとTracとを稼働させる。そこに同ホスト上の別ゲストOSからApache Benchmarkツール ab を使用する。
CPUは、AMD Phenom x4 ９７５０、メモリはDDR2-800 6GB
プロジェクトで使用するツールでは、多数の開発者が頻繁に使用するため、同時アクセス下における応答性能を計測して比較する。比較にあたっては、Apache Benchmarkツール（ab）を使用する。
既存チケットを表示する場合の性能計測例
| Redmine | Trac | 備考 | |
|---|---|---|---|
| Document Length | 10625 | 9961 | |
| Time taken for tests | 14.932 秒 | 33.148 秒 | |
| Connection Times (mean) | 1429 ms | 3280 ms | |
Redmineは、基本MySQLを推奨しており、インストール手順でもMySQLを使用する記載となっている。Sqliteでは性能がでないためである。
Tracは、SQLiteをデフォルトとしている。PostgreSQLを使用可能。
RedmineもTracも、ソフトウェア・プロダクトを開発する／保守するという主ミッションを効率よくサポートすることに価値がある。
今回比較したのは、RedmineとTracのそれぞれ本体（追加プラグイン・カスタマイズ未実施）での持つ機能に過ぎない。ツールを導入して運用をはじめて、以後一切ツールに手を入れないのであれば最初に持つ機能によって主ミッションへのサポート力が変わってくる。しかし、ツールを導入しただけでうまくいくことは稀で、多かれ少なかれ使い勝手が悪い箇所が出てくる。
導入したツールの不都合な点を我慢して使っていては「効率よくサポート」とは言えず、主ミッションを阻害する方向に行きかねない。これはマイナスの価値となる。導入したツールの不都合を改善していくことができるか、が実は機能比較より重要ではないかと考える。
そのためには、ツールの使い方を熟知し、改善方法を研究し適用するツールマスターの存在が欠かせない。と言ってもツールマスターを探すのではなく、ツール導入以降徐々にツールマスターに育っていけばよい。誰もが最初から熟達しているわけではない。
また、ツールマスターは改善だけでなく、むしろそれより重要なのがツールの使い方を浸透させる役割である。どんなに高機能で優れたツールでも、使いこなせなければただのガラクタである。（ソフトウェアツールのいいところはガラクタとなってもHDD上の数mmしか場所を食わない点）
TracやRedmineの場合、ツールマスターは、チケットやWikiの使い方に長け、分からない人に教え、使い勝手・不都合があった場合に、プラグインを探して追加したり、あるいはプラグイン自体を作成したり、あるいは本体に手を入れて、あるいは周辺ツールを作成して改善する、といった具合に、開発インフラとなるツールを熟成させていくことで主ミッションの効率を最大限改善することが大事となる。
したがって、ツールの選択にあたって最大の要因は、ツールマスターが存在する（または育つ）かどうかと考える。そこで、機能よりもなによりも、使い手が一番モチベーションの湧くツールを選ぶというのがよいかと思う。モチベーションが湧くツールは、いじりたい、改善したい、ということにつながる。最初は知識ゼロでも、運用しながらPython/Rubyを覚えたり、と。
そこで、機能比較の使い方は、実際に使うことになる人たちに紹介し、その中からめぼしいものを２，３つ選ぶために使い、あとは実際にその２，３の「ファイナリスト」を実際の運用に沿った状況を模して使ってもらい、その中で気に入ったツールを採用する、というのがよいと考える。皆で選んだ、という記憶が残るような選び方がいい。
なお、この選択の考え方と真逆なケースは、組織標準ツールが決められており、そのツールの使用を強要され、ツールには一切手出し不可、要望を上げても対応はされないか、「予算に計上しておいたから、来年度予算が付いたら対応します」的な対応だろう。
本記事執筆にあたって調査した後、RedmineもTracもバージョンアップが実施されている。新機能の中で、本記事の比較に影響のあるものを次にメモする。
This page is written by Toru Takahashi.