仕様書をTracのWikiに記載する - rabbit2goのブログ
「仕様書をSubversionとTracで管理する」に続いて、今回は仕様書をTracのWikiで作成する話。 Tracの登場以前に、仕様をPukiwikiで書き始めたのがそもそも発端だけど、Wikiを使うメリットとして下記が挙げられると思う。 仕様同士のリンク 経験的に言って、仕様書は一つだけでは収まらないことが多い。関連する仕様として、仕方なくたくさんのファイルを作っていく事になるのだけど、数が増えると相互参照が大変な作業になる。この点、WikiならWebのリンクを辿るだけなので、情報へのアクセスが容易だ。 仕様の一意性確保 （社内サーバにて）一意のURLと仕様が紐づけられるので、仕様として意味するところを明確に指定できる。ファイルだとファイル名に整理用の数字を入れたり、最新版の資料の置き場所を常に意識しておく必要があった。 ファイルよりも更新が簡単 気分的なものが大きいかも知れないけど
ウノウラボ 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 の場合、プラグインやマクロを使えばある程度はカバ
ソフト/Bug Tracking/trac/WebAdminPlugin - discypus
(2006-01-30 ソフト/Bug Tracking/trac/plugin より移動。) WebAdminプラグインは、trac-admin コマンドが提供している操作を、代わりにWebブラウザ経由で行えるようにするもの。 注意: Trac 0.11ではTrac本体に統合されたので不要。(Milestone 0.11 によると「Integration of WebAdmin into core」とのこと)。既存の環境をTrac 0.11にアップグレードするときは無効化 (trac.iniの[Components]セクションで)、あるいはプラグインを削除しておくこと。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
