これから使うならTracとRedmineどちらがよいか？ - プチ技術メモ
Tracを約一年、その後Redmineを約一年使った経験から言うと、これから使うならRedmineの方が断然いいと思います。 機能面では、それぞれに一長一短があるので、どちらが優れているかは人それぞれかと思います。一番の問題は、Trac本家のバージョンアップが、ここ数年停滞していることです。 とりあえず、直近３件のメジャーバージョンアップのリリース日を比べてみると次のようになります。なお、リリース日は、それぞれの本家リポジトリにタグが打たれた日としています。 Redmine Trac 0.9.0 2010-01-10 0.11 2008-06-22 0.8.0 2008-12-30 0.10 2006-09-28 0.7.0 2008-04-30 0.9 2005-10-31 ちなみに、Tracの0.12のリリース予定は2009-12-01となっていますが、大量の未解決チケットが残っていて
【公開】第4.5回Shibuya.trac発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」 - プログラマの思索
第4.5回Shibuya.trac に参加して発表してきた。 スタッフの皆さん、ありがとうございました。 その発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」をCC Attribution ライセンスで公開します。 今回の発表は、昨年のKOFで発表したRedmine＋TiDDから続く一連のチケット駆動開発のまとめになります。 SQIP2009では、大手SIの経営者や管理職が多いせいか、チケット駆動開発の発表はプロセス改善というよりもツールに依存した運用改善と捉えられがちで、あまり反響がなかった。 でも、第4.5回Shibuya.tracはまるでホームのような雰囲気で、聴衆はTrac使用者がRedmine使用者よりもやや多かったけれど、チケット駆動開発に興味のある人達ばかりだったので、熱く語ることができた。 関西から八朔さんや小枝さんも来てくれて心強かった。 最後のパ
チケット駆動開発のベストプラクティスを収集したい - プログラマの思索
チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。 理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。 僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。 但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。 １・チケット・ファースト(Ticket First) 【説明】 基本は、プロジェクトの作業はチケットを受け取ってから始める。 チケット無しで作業はしない。 また、SVNコミット時に、チケット無しのコミットも不可。 【効用】 チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。 進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアル
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を扱うことはできるが、チケット
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
