初めに。 Timing and Estimationプラグインをインストールするにあたっては下記のサイトを参考にさせていただきました。 trac + TracBurndownプラグインでスクラム開発のすすめ Timing and Estimationプラグインは、Tracのチケットに対する作業時間を入力し、その作業実績を管理する為のプラグインです。 チケットに着手する際に、そのチケット解決までの見積り時間を設定し、それに対して日々どれだけの作業をしたかを入力する事で、チケットの作業割合が確認できます。 まぁ、この辺はプラグイン利用の際のルールをきちんと整備し、そのルールを如何にメンバーに守らせるかなど運用の方が重要になってくると思いますが・・・。 Timing and Estimationプラグインをインストールする為には、Trac0.10以上のバージョンが必要です。 要件を満たしていない
Trac上でプロジェクトを管理する上での基本操作は、Wikiによるページの編集と、チケットの登録、そのチケットの受取り（確認）・ステータス変更などが主なものです。 Wikiの編集作業と、「Browse Source」メニューでソースを確認する方法は、ここでは触れません。 Trac上のチケットとは、作業依頼書や報告書のようなものです。 チケットをTrac上に登録し、そのチケットを担当する人（チケット登録時に指定可能）がそのチケットを受け取って作業をします。 チケットを登録する前に、まずはTracにログインして見ましょう。 ログインは、右上の「Login」メニューから行えます。 Loginメニューをクリックするとエラーが出る場合は、ログイン方法の設定が正しく出来ていない可能性がありますので、前回のTracインストール編 を参照してみてください。 Basic認証でログインする場合は、Loginメ
Trac is distributed with a powerful command-line configuration tool. This tool can be used to configure and customize your Trac installation to better fit your needs. Some of the configurations can also be performed via the web administration module. Usage For nearly every trac-admin command, the first argument must be the path to the TracEnvironment: The only exception is for the help command, bu
B787の翼の接合部分の過重テストです。これを見ていると、ソフトウェアのテスト工程なんか楽な仕事な気がします。 ソフトウェアの製作方法だが、特にウェブ方面はここ15年間で進化した気がする。統合開発環境、バージョン管理システム、バグ管理システムなどのツール群もかなり整備されたし、MVCやO/Rマッピングやテスト等のフレームワークも積極的に採用されるようになってきた。しかしながら、RDBの正規形やデザインパターン等のソフトウェア構築技法的な点は、重要性が認識されている一方で、あまり一般化していない気がする。2000年問題のときに将来のことを考えないシステム構築が問題になっていたが、今でも便利なものは取り入れつつも、将来性や拡張性を考えたプログラミングが十分に普及していないのが現実か。 確かにツール群は、それを取りれる事で得られるメリットは明確なのだが、技法的な点は、それを学習するコストの大きさ
以前から個人的にLDAPを導入しているのですが、意外と忘れがちなので備忘をかねてメモります。 昔のメモなので今と挙動が違うかもしれませんがご了承ください。OSはCentOS 5です。 まずはOpen LDAPのインストールと設定をします。 関連パッケージのインストール $ yum -y install openldap openldap-servers openldap-clients openldap-devel ディレクトリマネージャのパスワードを生成する $ /usr/sbin/slappasswd -h {SSHA} New password: Re-enter new password: slapd.confの設定 /etc/openldap/slapd.conf ...snip... access to attrs=userPassword by self write by a
The Trac Ticket Workflow System よく見たら、TracのTicket Workflowって、0.10の場合と0.11のデフォルトは若干異なっているんですね（acceptedの状態が増えている）。まぁ、それはそれとして、Tracのワークフローのカスタマイズを試してみました。 設定方法に関しては、上記URLに詳細が記載されていますが、今後のためにも簡単にまとめてみました。0.11b1での内容となりますが、おそらく0.11正式版でも同様ではないかと（ただし、将来的にはさらに機能が追加されるかもしれません）。 trac.iniの [ticket-workflow] セクションにて定義します。 (key) = (value)とのみ記載されている行 (key)の部分がAction名、(value)の部分が「変更前のステータス -> 新しいステータス」。 Ticketのステ
Trac導入前に、何年かSVNが運用されていました。そして、リポジトリはプロジェクトごとに分割していましたとさ。現在20ぐらいリポジトリがあったりしています。 サーバーが古くて、OSがMiracle3.0で、Tracとか入れられなくて悔しい思いを。 やっと新しいサーバーをGetしてリポジトリ移行して、それで後からTrac入れましたよ。やったー。やっぱりTracいいな。 けれどさ、なんかたくさんのTracプロジェクトがあって見通し悪いなぁ。 みんなはどうしているのだろう。ググる。 ・・・ん。 TraMとか、便利そうなものがあるみたいですけど、プロジェクトのURLを開いても真っ白。 あらら。 うーん。とりあえず、TracのTimeLineのRSSをまとめて、時系列で見れるようにしておけば、直近の動きは、まあまあ見えるのかなぁ。個別のRSSだと全体のタイムラインの把握は無理だぁ。あのライブラリの
Importing ticket data Bugzilla Ticket data can be imported from Bugzilla using the bugzilla2trac.py script, available in the contrib/ directory of the Trac distribution. $ bugzilla2trac.py bugzilla2trac - Imports a bug database from Bugzilla into Trac. Usage: bugzilla2trac.py [options] Available Options: --db <MySQL dbname> - Bugzilla's database --tracenv /path/to/trac/env - full path to Trac db
結論から言うと、タイムラインで確認できる。。。 デフォルトだと、タイムラインにはチケットの情報は新規に作られた場合と、「解決にする」の属性を変更（fixedやinvaliedなど）された場合にしか、表示されません。 このままだと、あるチケットにコメントを追記した場合にその変化に気づく事がなかなかできません。 チケットの数が多くなればなお更。 レポートから一つ一つチケットの内容を確認するのもかなり面倒ですし。 メールを送信する設定にしておけば追えるようですが、あまりメールで更新情報を貰うのも好きではありませんし、メールの送信自体が環境により大きく左右される（可能か否か）ので、その他の方法で何とか確認できる方法は無いか探していました。 予断ですが、チケットごとに発行されているRSSフィードをRSSリーダーに登録しておけば、そのチケットに対する細かな変化を追跡する事は可能です。 ただ、チケットご
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く