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だとさらにマイ
RedmineとTracの機能比較part2～ポータビリティ、プラグインなど - プログラマの思索
あるTracユーザの話を聞いて、RedmineとTracの機能の違いを感じたので、考えたことをメモ。 【1】ポータビリティ(環境の持ち運び)はTracが勝る TracLightningでは、SQLLite＋SVNが一つのフォルダに存在するから、バックアップが簡単。 Tracはそもそも１プロジェクトしか扱えないので、1プロジェクトのTracDB(SQLLite)を持ち運んで同期を取ればいい。 しかし、Redmineでは、DBはMySQLが普通だから、バックアップや持ち運びはOracleのような操作が必要になる。 また、複数プロジェクトを扱っているから、1個のプロジェクトだけ持ち運んでも同期がとりにくい。 特に、客先と自社で受託開発のタスク管理をする場合、USBメモリでSQLLiteのDBを持ち運びできればすごく簡単だなと思った。 RedmineでもSQLLiteを扱うことはできるが、チケット
Redmineを使って気付いたことpart7～イテレーションで追跡する - プログラマの思索
チケット駆動開発でアジャイルに開発しながら、「チケットではなくイテレーションで進捗やリスクを追跡する」意味が何となく分かってきた。 それについてメモ。 【1】チケット駆動開発の基本は、チケットファースト。 チケットがXPのタスクカードに相当する。 担当者は、チケットへ作業内容を記入してから、作業を開始する。 開発者は実際、チケットをToDoカードのように用いている。 SW開発のタスクは単にプログラミングだけではない。 お客様へ納品する設計書を作ることも必要だし、テスト仕様書を作ることも必要。 更には、ビルド環境を作ることも必要だし、テストデータを準備することも必要。 すると、チケットは終了するペースよりも登録する方がどんどん増える。 何もしなければ、チケットは乱発されて、放置状態になり、収拾が付かなくなる。 僕が初めてTracを運用した時、マイルストーンやバージョンが曖昧なままチケットを登
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20080313/p01/
