Lifeとあるエンジニアのとある1日のつぶやき。-TracBurndownインストール-<はじめに>私の環境では、TracのDBとしてPostgreSQLを採用していますが、TracBurndown+PostgreSQLの組み合わせは棘の道です。TracBurndownプラグイン自体がSQLiteとかを想定しているからでしょうか。前回書いてから随分と時間がたってしまった・・・。Estimationプラグインを入れたのに・・・。Estimationプラグインにより入力可能になったTracのチケットに対する作業時間を集計し、バーンダウンチャートを作成する為のプラグインです。ダウンチャートとは、横軸を時間、縦軸を残作業(量)として計画と実績の差を一目で分かるようにグラフ化したものです。左上を基点にして、作業量を入力する事でグラフは右肩下がりになって行き最終的に0(時間軸にぶつかる)になったらプロジェクトが完了したということを表します。ダウンチャートの詳しい解説は、こちらが参考になるかと思います。ダウン・チャートによるプロジェクト管理の進め方そのバーンダウンチャートでプロジェクトを管理する為のプラグインがTracBurndownです。TracBurndownをインストールする為には、Trac0.10以上のバージョンが必要です。要件を満たしていない場合は、事前にアップグレードしておきましょう。プラグインを追加するにあたりTracWebAdminをインストールしておけば楽に作業できます。TracWebAdminのインストール方法については、下記参照。プラグインのインストールにTracWebAdminは必須ではありません。インストールしてみたいと思います。」を参照してください。TracBurndownプラグインインストールの事前準備TracBurndownプラグインを追加する前に「PYTHON_EGG_CACHE」と言う環境変数の定義と、そのキャッシュ用のディレクトリを作成しておきます。eggで利用されるキャッシュ用のディレクトリでプラグインは通常、それらをユーザーのホームディレクトリを利用しますが、権限などの問題でエラーになる事もあるので明確に定義しておきます。」を参考にした場合は、既に設定されているかと思いますのでスキップしてください。キャッシュ用のディレクトリを作成します。ディレクトリの場所は何処でもかまいません。/home/python_egg_cache次に、Apacheの設定ファイル(httpd.conf)に、PYTHON_EGG_CACHEの環境変数を定義(追記)します。Tracのバージョン0.11.1以前ではSetEnvでPYTHON_EGG_CACHEの環境変数をセットしていましたが、0.11.2以降では、PythonOptionで指定するように変更されています。PYTHON_EGG_CACHEの設定方法が変わった?編集後は、Apacheを再起動します。PYTHON_EGG_CASHEを設定しておかないとTracBurndownプラグインを有効化した際にエラーが出ます。エラーの詳細は、後述の「TracBurndownプラグイン追加時のエラー対処方」を参照してください。Estimationプラグインの機能を利用しているため、まずはこのプラグインを追加する必要があります。TracBurndownプラグインを追加するこれでTracBurndownプラグインがインストール可能になりました。ダウンロード可能です。今回インストールしたバージョンは、01.08.10です。ダウンロード後は、サーバーにファイルを転送しておきます。TracBurndownプラグインのインストールインストール方法は単純で、ダウンロードしたzipファイルをeggファイルへリネーム後に、site-packagesディレクトリへコピーするだけです。/usr/lib/python2.3/site-packages/インストール後は、Apacheを再起動します。Estimationプラグインの有効化と同様に、TracWebAdmin上からプラグインを有効にします。これもTracWebAdminをインストールしていない場合は、tracの設定ファイル(trac.ini)を編集する事で有効化できます。enabled有効化の後は、trac-adminコマンドでアップグレードを実行します。Estimationプラグインの際と同様です。ユーザー権限の付与TracBurndownを利用するためには、その利用するユーザーに権限を付与する必要があります。権限付与の方法は、TracWebAdminを利用するかtrac-adminで付与します。BURNDOWN_VIEWとなります。-を参照してください。最後に、Apacheを再起動させます。Cronの設定これまでの作業で、TracBurndownは一応利用できるのですが、このままだとバーンダウンチャートが更新されていきません。最後に、その更新用バッチをCronにセットして日次で動かすようにします。更新用バッチは、下記にありますのでそれをpythonの実行ディレクトリにコピーしておきます。/usr/lib/python2.3/後は、上記のバッチファイルを日次で動かすようにCronに登録しましょう。burndown_job.pyの後には、TracBurndownを利用するプロジェクトのディレクトリを指定します。TracBurndownが利用できるのは、上記のCronが実行されてからになります。利用を開始したい場合は、コマンドラインから実行すればよいです。DBにPostgreSQLを利用した場合は、エラーがでます。その場合は、さらに次の作業を進めてください。TracのDBにPostgreSQLを利用していない場合は、これでTracBurndownを利用できるはずです。PostgreSQLを利用している場合は、さらに続きが・・・。PostgreSQLを利用する場合の独自の作業さて、棘の道へ入ってきました。ここまでの作業でも、TracBurndownのメニューが見えたり、一見利用できるような感じなのですがチケットを登録した際にエラーが出力されます。(エラーメッセージ4)」を参照してください。エラーを回避する為には、burndown_job.pyファイルの編集、シーケンスの作成、テーブルの再作成が必要になります。今回の対応にあたり下記のサイトの情報を参考にさせていただきました。Cronの設定」で登録する「burndown_job.py」ファイルを実行した場合、エラーメッセージ4と同様のエラーが出力されます。エントリによればburndown_job.pyファイルの75行、76行目のSQLに問題があるようです。hours))上記のSQLを下記のように変更します。hours))理由は、後述するシーケンスの作成を行った後に、burndownテーブルのidカラムには、そのシーケンスからの番号を取得するようにデフォルト値をセットさせる為です。PostgreSQLで、カラムにセットしているデフォルト値を採用させるには、INSERT時に該当のカラムを指定しなければよいので。このburndownテーブルのカラム「id」にはシーケンスの番号をセットする事を想定しているのでそのシーケンスを作成してあげます。SQLiteだとINSERT時に該当のカラムにNULLを指定するだけで、シーケンスから値が取ってきてくれるらしい・・・。Tracのインストール時に指定したDB接続ユーザーでログインしてシーケンスを作成します。最後に、burndownテーブルを再作成します。再作成する理由は、burndownテーブルのhours_remainingカラムがinteger型になっており、このままだとチケット登録時に、エラーが表示されるからです。(エラーメッセージ5)」参照そこで、burndownテーブルのhours_remainingカラムをinteger型からreal型に変更します。そのついでに、idカラムのデフォルト値を先ほど作成したシーケンスから取得した番号がセットされるように作ります。burndownテーブルを削除します。burndown;次に、テーブル再作成用ののCREATE文を実行します。NULL);最後に、burndown_job.pyを実行してみます。/home/trac/project1これで、ようやくTracBurndownが利用できるようになりました。Ticket)を入力(チケットを更新)していくだけです。Cronでセットしたburndown_job.pyがそれらの値を日次で集計してバーンダウンチャート図を描いていきます。ダウンチャート図は、Tracの上部メニュー「Burndown」から見れます。使ってみた感想として、レポートのような数値だけを並べたものより視覚として見れますので進捗度合いは分かりやすいと思います。ダウンチャートを表示する切り口として、「マイルストン」と「コンポーネント」をキーにしてしか見れないようです。チケットの登録で、そのチケットに着手してから完了するまでの見積り時間、そして日々の作業時間を入力するのに、バーンダウンチャートで見れるのは、そのチケットが属するマイルストンやコンポーネントごとにまとめられての表示となります。チケットごとにバーンダウンチャートを見れたら良いのにとか思うのですが・・・。Trac自体の設計として、マイルストンがあり、そこにチケットが付随しており、それらのチケットはコンポーネントによってカテゴライズされるという扱いなっているからなんでしょうけど。なってくると、チケットに登録する粒をある低細かく設定しておく必要があります。「××システム構築」なんてチケットを登録するのではなく、その「××システム構築」をマイルストンにセットしておき、チケットではその「××システム構築」にあたっての各タスクをセットしていく必要があります。TracBurndownプラグインの削除プラグインの削除方法は、下記の通りです。Trac設定ファイル(trac.ini)ファイルの編集1.だけでもプラグインは削除(無効)できていますが、trac.iniファイル内のプラグインに関連する記述も削除しておきましょう。削除する前に念のためにtrac.iniファイルのバックアップを取っておきましょう。enabledを削除します。DBの削除ここまでやる必要はないかと思いますが、TracBurndownプラグインから作成されたテーブルを削除します。PostgreSQLを利用する場合の独自の作業」を行った場合は、作成したシーケンスも削除します。'/home/trac/project1/conf/trac.ini'プラグインをTracWebAdminから有効化しようとするとエラー発生。原因は、TracWebAdminがtraci.iniファイルを編集しようとしてその権限が無いためです。対処方法としては、Apacheのユーザへ書き込み権限を扶養してあげれば解消されます。directory.メッセージ最後に出ているように環境変数「PYTHON_EGG_CACHE」を設定せずにプラグインをインストールした場合にブラウザ上に表示されたエラー。upgrade"プラグインを有効化した直後にブラウザに表示されたエラーメッセージ。書かれているようにtrac-adminコマンドを実行する必要があります。先にも書いたとおりDBにPostgreSQLを使用している場合は、「--no-backup」オプションが必要。--no-backupを実行。constraintburndown_job.pyを実行した場合、またTracBurndownプラグインを追加後に、チケットを登録しようとした際に出たエラーです。PostgreSQLを利用する場合の独自の作業」を参考に対処してください。"0.000000"エラーメッセージ4と同じく、burndown_job.pyの実行時、チケット登録時に出たエラーです。対処方法も同じく、「6.PostgreSQLを利用する場合の独自の作業」を参考に対処します。Reserved.スパムを報告お問い合わせ利用規約ヘルプ。