Trac Ticket レシピとかあったらいいな
Trac の ticket システムは結構ステキな仕組みで、milestone 管理の際に出てくるあの進捗度合いを示すバーが伸びていくのを見たいがために、積極的に ticket を発行してタスクをやっつけてやるぞという気にさせてくれる。
あれだ。テストドリブンでオールグリーンを目指すのとおんなじ。
でだ。これって実は割と応用範囲が広くて、いろんな仕事をこの ticket システムで運用できそうな気がする。近頃流行りの lifehack だの GTD だのという単語そのものにはそれほど興味はないが、いちいち Excel や Wiki でうんうんと表を書いて管理するより ticket をほいっと発行してしまえば一覧は [ View Tickets ] の report 機能や custom query（このインターフェイスも親切でイカす）であれこれ眺めることができるので、圧倒的にこっちのやり方の方が冴えてると思う。1
ただ問題は ticket のカスタマイズをどうしようってところで。デフォルトの ticket と Web から設定できない現在2の Trac の標準状態では面倒くさくなってしまいやすいので、これを放置して単なる ViewCVS 代わり + Wiki みたいに使ってしまうケースって、実は多いんじゃないかという気がしている。というかうちはまさにそうでした。
最近やっと時間がとれたので WebAdmin plugin を入れて ticket のカスタマイズをしてみているんだけど、component と milestone の設定次第で結構やれそうという感触を得つつある。逆に言うと難しいのもここなんだけど。
今ほしいのはシステム管理向けの Ticket の雛形。開発であればプロダクトによって milestone も component もマチマチになってくるとは思うんだけど、システム管理であれば利用しているクライアント OS や提供しているサービスが component に該当して、あとは細かいハードウェアとか、そういう感じで整理できるような気がしないでもない。
例えばネットワークサービスであれば
- smtp
- pop
- http
- dbms
- dns
とか。あーでも分けない方がいいかもなぁ。とか悩んじゃってる。まぁこれも管理するシステムによって違うか。
小規模で個々のサーバが別々のサービスを担当している場合はサーバ単位に component を切り出すのがいいだろうけど、大量のサーバが同じサービスを受け持っている場合はサービス単位で component を作っておいた方が見通しよさそう。
業務支援系のツールを作り込んでいる場合も悩ましくて、これは本来システム管理のプロジェクトに入れるべきだと思うんだけど、数が多くなってくると component がゴチャゴチャし過ぎちゃうかなという気もしないでもない。ただ、Trac 0.10 から InterTrac という仕組みが用意されているので、とりあえず丸ごと突っ込んでごちゃごちゃしてきたら分割も視野に入れましょう、というアプローチでもよいような気がしている。
そこまで分かってんならダラダラ日記書かずに仕事しろよというご指摘はごもっとも。でもこういうノウハウってどこかで共有できないかしらん。とか思ったりもしてます。
ひとつ分かった。
ticket の component を考え始めたら svn の repository の分け方を変えた方がよいと思った。今の分け方は細か過ぎる。もっと一緒にしておくべきだ。
なるほどな。こういう風に別な視点で全体を眺めると、今まで見えてなかったことが見えてくるんだな。