ウノウラボ Unoh Labs: Tracに QA(testing) のステータスを追加する方法
2次元より3次元のほうが好きな hide です。 昨日のmasatoさんのエントリへのコメントで、Tracの話が盛り上がっていたので引き続きTracネタを続けます。今さらTracについての説明は必要ないと思いますが、どんなものかひと言で説明すると、BTSとWikiとSubversionリポジトリビュアーを合体したようなものです。この組み合わせ具合が絶妙で、Tracは様々なソフトウェア開発現場で使われています。有名なところでは、Ruby on Railsの開発にも使われています。 しかし、ウノウではBTSに影舞を使っています。何故かというと、標準ではTracのワークフローは次のようになっていて、testingのステータスがないからです。 最近は、ベータ・クオリティでもいいから、とにかく早くサービスを公開することが重要だという考え方が一般的になってきています。しかし、バグだらけのシステム
記憶は削除の方向で - trac をプロジェクトのポータルサイトとして使うために
trac は標準でもかなり高機能なんだけど、使っているうちにそれなりに不満点は出てくる。 個人的に、標準では使いにくいと思うものがいくつかあって、今のところこれくらい。 ユーザ管理 -> 標準だとコマンドラインで trac-admin するしかない。 -> サーバまで移動する or リモートログイン。面倒。 ニュースの表示 -> 一番目立つ WikiStart を編集するとか？ -> ニュースであることが気付き難いし、過去のニュースが追えない。 関連する情報へのリンク ->手動で関連情報にリンク。 -> めんどくさいし、漏れが出るのは確実だろう。 あとは議論するための仕組み(-> DiscussionPlugin ？)とか、自分のタスク一覧確認(-> デフォルトのレポート7？)が必要かとも思うけど、標準でもなんとかなるように思う。 trac の場合、プラグインやマクロを使えばある程度はカバ
連載：Ruby on Railsで作られたプロジェクト管理ツールredMineを使ってみよう！｜gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
SubversionとTracでファイル管理の“迷宮”から脱出
SubversionとTracでファイル管理の“迷宮”から脱出：ユカイ、ツーカイ、カイハツ環境！（2）（1/4 ページ） プロジェクトで修正／仕様変更が“迷宮”入りする理由 ソフトウェア開発を行ううえで、設計書やソースコードのバージョンをきちんと管理することは非常に重要です。構成管理（ファイル管理）を行っていないプロジェクトでは、例えば次のような問題が発生します。 2人以上の開発者が同時に成果物を編集した場合、後に編集を始めた開発者がすでに編集を行った開発者の編集内容を上書きしてしまう。結果として、修正したはずのバグや変更したはずの仕様が、設計書やソースコードに反映漏れするという事態が発生 設計書やソースコードのレビューを行って修正したはいいが、どこをどう修正したのか分かりにくく、レビュー内容の反映の確認を行っても修正漏れや修正誤りに気が付かない ソースコードを変更すると、動かなくなってし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[Subversion][trac] trac の使い方 - まちゅダイアリー (2005-10-29)
