Tracの使い方 -TracBurndownインストール- | A Day In The Boy's Life

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

<はじめに>


私の環境では、TracのDBとしてPostgreSQLを採用していますが、TracBurndown+PostgreSQLの組み合わせは棘の道です。。。

元々、TracBurndownプラグイン自体がSQLiteとかを想定しているからでしょうか。。。


</はじめに>



Tracの使い方 -Timing and Estimationプラグイン- 」続編。


前回書いてから随分と時間がたってしまった・・・。

本当は、TracBurndownプラグインを入れたかったからTiming and Estimationプラグインを入れたのに・・・。


TracBurndown(scrum Burndown in Trac)は、Timing and Estimationプラグインにより入力可能になったTracのチケットに対する作業時間を集計し、バーンダウンチャートを作成する為のプラグインです。

バーンダウンチャートとは、横軸を時間、縦軸を残作業(量)として計画と実績の差を一目で分かるようにグラフ化したものです。

左上を基点にして、作業量を入力する事でグラフは右肩下がりになって行き最終的に0(時間軸にぶつかる)になったらプロジェクトが完了したということを表します。
バーンダウンチャートの詳しい解説は、こちらが参考になるかと思います。


第12回 バーンダウン・チャートで「終わるかどうか」を見える化する


第13回 バーンダウン・チャートによるプロジェクト管理の進め方


そのバーンダウンチャートでプロジェクトを管理する為のプラグインがTracBurndownです。

TracBurndownをインストールする為には、Trac0.10以上のバージョンが必要です。

要件を満たしていない場合は、事前にアップグレードしておきましょう。

なお、プラグインを追加するにあたりTracWebAdminをインストールしておけば楽に作業できます。

TracWebAdminのインストール方法については、下記参照。


Tracの使い方 - TracWebAdminインストール -


※ プラグインのインストールにTracWebAdminは必須ではありません。



では、早速インストールしてみたいと思います。

インストールしたTracの環境については、前回の「バグトラッキングシステム「Trac」インストール 」を参照してください。



1. TracBurndownプラグインインストールの事前準備


TracBurndownプラグインを追加する前に「PYTHON_EGG_CACHE」と言う環境変数の定義と、そのキャッシュ用のディレクトリを作成しておきます。

これは、Python eggで利用されるキャッシュ用のディレクトリでプラグインは通常、それらをユーザーのホームディレクトリを利用しますが、権限などの問題でエラーになる事もあるので明確に定義しておきます。

(TracWebAdminプラグインをインストールした時は必要なかったんだが・・・)


※ 「Tracの使い方 -Timing and Estimationプラグイン- 」を参考にした場合は、既に設定されているかと思います

  のでスキップしてください。


まず、キャッシュ用のディレクトリを作成します。ディレクトリの場所は何処でもかまいません。


# mkdir /home/python_egg_cache

次に、Apacheの設定ファイル(httpd.conf)に、PYTHON_EGG_CACHEの環境変数を定義(追記)します。


<Location "/trac">
PythonOption PYTHON_EGG_CACHE /var/trac/python_egg_cache

※ Tracのバージョン0.11.1以前ではSetEnvでPYTHON_EGG_CACHEの環境変数をセットしていましたが、0.11.2以降

  では、PythonOptionで指定するように変更されています。


参考: [Trac] PYTHON_EGG_CACHEの設定方法が変わった?


編集後は、Apacheを再起動します。


※ PYTHON_EGG_CASHEを設定しておかないとTracBurndownプラグインを有効化した際にエラーが出ます。

  エラーの詳細は、後述の「TracBurndownプラグイン追加時のエラー対処方」を参照してください。



2. Timing and Estimationプラグインを追加する


TracBurndownプラグインは、内部でTiming and Estimationプラグインの機能を利用しているため、まずはこのプラグインを追加する必要があります。


Timing and Estimationプラグインのインストール、有効化の方法は、下記参照


Tracの使い方 -Timing and Estimationプラグイン-



3. TracBurndownプラグインを追加する


これでTracBurndownプラグインがインストール可能になりました。

TracBurndownプラグインは、こちら からダウンロード可能です。

今回インストールしたバージョンは、01.08.10です。
ダウンロード後は、サーバーにファイルを転送しておきます。



3.1 TracBurndownプラグインのインストール


インストール方法は単純で、ダウンロードしたzipファイルをeggファイルへリネーム後に、site-packagesディレクトリへコピーするだけです。


# cp TracBurndown-01.08.10-py2.3.egg.zip TracBurndown-01.08.10-py2.3.egg

# cp TracBurndown-01.08.10-py2.3.egg /usr/lib/python2.3/site-packages/

インストール後は、Apacheを再起動します。



3.2 TracBurndownプラグインの有効化


Timing and Estimationプラグインの有効化と同様に、TracWebAdmin上からプラグインを有効にします。



TracBurndown


これもTracWebAdminをインストールしていない場合は、tracの設定ファイル(trac.ini)を編集する事で有効化できます。


trac.iniファイルに以下を追記(又は編集)


[components]
burndown.burndown.burndowncomponent = enabled

有効化の後は、trac-adminコマンドでアップグレードを実行します。


# trac-admin /home/trac/project1 upgrade --no-backup

※ --no-backupオプションを付ける、付けないはTiming and Estimationプラグインの際と同様です。



4. ユーザー権限の付与


TracBurndownを利用するためには、その利用するユーザーに権限を付与する必要があります。

権限付与の方法は、TracWebAdminを利用するかtrac-adminで付与します。

付与する権限は


BURNDOWN_VIEW : バーンダウンチャートを見せたいユーザーに付与

BURNDOWN_ADMIN : TracBurndownの管理権限を利用させたいユーザーに付与


trac-adminを利用した場合の権限付与方法の例は


# trac-admin /home/trac/project1 permission add demo BURNDOWN_VIEW

となります。

trac-adminの詳しい使い方については


Tracの使い方 - trac-adminの使い方、チケットの管理とロードマップの確認 -


を参照してください。


最後に、Apacheを再起動させます。



5. Cronの設定


これまでの作業で、TracBurndownは一応利用できるのですが、このままだとバーンダウンチャートが更新されていきません。

最後に、その更新用バッチをCronにセットして日次で動かすようにします。

更新用バッチは、下記にありますのでそれをpythonの実行ディレクトリにコピーしておきます。


ScrumBurndownPlugin: burndown_job.py


例えば、上記のバッチファイルをサーバーに転送して


# cp burndown_job.py /usr/lib/python2.3/


後は、上記のバッチファイルを日次で動かすようにCronに登録しましょう。


# crontab -e

0 3 * * * /usr/bin/python /usr/lib/python2.3/burndown_job.py /home/trac/project1

※ burndown_job.pyの後には、TracBurndownを利用するプロジェクトのディレクトリを指定します。


TracBurndownが利用できるのは、上記のCronが実行されてからになります。

すぐに利用を開始したい場合は、コマンドラインから実行すればよいです。


# /usr/bin/python /usr/lib/python2.3/burndown_job.py /home/trac/project1

※ DBにPostgreSQLを利用した場合は、エラーがでます。その場合は、さらに次の作業を進めてください。


TracのDBにPostgreSQLを利用していない場合は、これでTracBurndownを利用できるはずです。

PostgreSQLを利用している場合は、さらに続きが・・・。



6. PostgreSQLを利用する場合の独自の作業


さて、棘の道へ入ってきました。

ここまでの作業でも、TracBurndownのメニューが見えたり、一見利用できるような感じなのですがチケットを登録した際にエラーが出力されます。

エラーの詳細は、「番外編 - プラグイン追加時のエラー対処 - (エラーメッセージ4)」を参照してください。


エラーを回避する為には、burndown_job.pyファイルの編集、シーケンスの作成、テーブルの再作成が必要になります。


なお、今回の対応にあたり下記のサイトの情報を参考にさせていただきました。


[trac] Timing and Estimation Plugin @ より良い環境をもとめて



6.1 burndown_job.pyファイルの編集


「5. Cronの設定」で登録する「burndown_job.py」ファイルを実行した場合、エラーメッセージ4と同様のエラーが出力されます。


この原因は、先ほど紹介したn314さん のエントリによればburndown_job.pyファイルの75行、76行目のSQLに問題があるようです。


cursor.execute("INSERT INTO burndown(id, component_name, milestone_name, date, hours_remaining) "\
" VALUES(NULL, '%s','%s','%s',%f)" % (comp[0], mile[0], today, hours)) 

上記のSQLを下記のように変更します。


cursor.execute("INSERT INTO burndown(component_name, milestone_name, date, hours_remaining) "\
" VALUES('%s','%s','%s',%f)" % (comp[0], mile[0], today, hours))

理由は、後述するシーケンスの作成を行った後に、burndownテーブルのidカラムには、そのシーケンスからの番号を取得するようにデフォルト値をセットさせる為です。
PostgreSQLで、カラムにセットしているデフォルト値を採用させるには、INSERT時に該当のカラムを指定しなければよいので。



6.2 シーケンスの作成


元々、このburndownテーブルのカラム「id」にはシーケンスの番号をセットする事を想定しているのでそのシーケンスを作成してあげます。

SQLiteだとINSERT時に該当のカラムにNULLを指定するだけで、シーケンスから値が取ってきてくれるらしい・・・。


$ psql -U trac_user trac-db

trac-db>create sequence burndown_id_seq;

※ Tracのインストール時に指定したDB接続ユーザーでログインしてシーケンスを作成します。



6.3 burndownテーブルの再作成


最後に、burndownテーブルを再作成します。

再作成する理由は、burndownテーブルのhours_remainingカラムがinteger型になっており、このままだとチケット登録時に、エラーが表示されるからです。

エラーの詳細は、「番外編 - プラグイン追加時のエラー対処 - (エラーメッセージ5)」参照


そこで、burndownテーブルのhours_remainingカラムをinteger型からreal型に変更します。

そのついでに、idカラムのデフォルト値を先ほど作成したシーケンスから取得した番号がセットされるように作ります。


まずは、burndownテーブルを削除します。


trac-test> drop table burndown;

次に、テーブル再作成用ののCREATE文を実行します。


CREATE TABLE burndown (id integer PRIMARY KEY DEFAULT nextval('burndown_id_seq') NOT NULL,
component_name text NOT NULL,
milestone_name text NOT NULL,
date text,
week text,
year text,
hours_remaining real NOT NULL
);

最後に、burndown_job.pyを実行してみます。

# /usr/bin/python /usr/lib/python2.3/burndown_job.py /home/trac/project1

これで、ようやくTracBurndownが利用できるようになりました。



TracBurndownの利用方法


利用方法は、前回の「Tracの使い方 -Timing and Estimationプラグイン- 」で説明したチケット登録時に、そのチケットの完了までの見積もり時間(Estimated Number Estimated Number)を入力し、あとはそのチケットが完了するまで日々実績(Add Hours to Ticket)を入力(チケットを更新)していくだけです。

Cronでセットしたburndown_job.pyがそれらの値を日次で集計してバーンダウンチャート図を描いていきます。

バーンダウンチャート図は、Tracの上部メニュー「Burndown」から見れます。


使ってみた感想として、レポートのような数値だけを並べたものより視覚として見れますので進捗度合いは分かりやすいと思います。

ただ、バーンダウンチャートを表示する切り口として、「マイルストン」と「コンポーネント」をキーにしてしか見れないようです。

チケットの登録で、そのチケットに着手してから完了するまでの見積り時間、そして日々の作業時間を入力するのに、バーンダウンチャートで見れるのは、そのチケットが属するマイルストンやコンポーネントごとにまとめられての表示となります。



TracBurndown


チケットごとにバーンダウンチャートを見れたら良いのにとか思うのですが・・・。

Trac自体の設計として、マイルストンがあり、そこにチケットが付随しており、それらのチケットはコンポーネントによってカテゴライズされるという扱いなっているからなんでしょうけど。


こうなってくると、チケットに登録する粒をある低細かく設定しておく必要があります。

「××システム構築」なんてチケットを登録するのではなく、その「××システム構築」をマイルストンにセットしておき、チケットではその「××システム構築」にあたっての各タスクをセットしていく必要があります。

例えば、プログラム単位とか。



TracBurndownプラグインの削除


プラグインの削除方法は、下記の通りです。



1. site-packagesディレクトリ内にある、プラグインファイルを削除


# rm /usr/lib/python2.3/site-packages/TracBurndown-01.08.10-py2.3.egg 


2. Trac設定ファイル(trac.ini)ファイルの編集


1.だけでもプラグインは削除(無効)できていますが、trac.iniファイル内のプラグインに関連する記述も削除しておきましょう。

削除する前に念のためにtrac.iniファイルのバックアップを取っておきましょう。


tra.ini設定ファイル内の[components]の項目にある


burndown.burndown.burndowncomponent = enabled

を削除します。



3. DBの削除


ここまでやる必要はないかと思いますが、TracBurndownプラグインから作成されたテーブルを削除します。


trac-db> drop table burndown;

※ 「6. PostgreSQLを利用する場合の独自の作業」を行った場合は、作成したシーケンスも削除します。


trac-db> drop sequence burndown_id_seq;


TracBurndownプラグイン追加時のエラー対処方


- エラーメッセージ1


Trac detected an internal error: 
IOError: [Errno 13] Permission denied: '/home/trac/project1/conf/trac.ini'


プラグインをTracWebAdminから有効化しようとするとエラー発生。

原因は、TracWebAdminがtraci.iniファイルを編集しようとしてその権限が無いためです。

対処方法としては、Apacheのユーザへ書き込み権限を扶養してあげれば解消されます。



- エラーメッセージ2


Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 406, in dispatch_request
dispatcher.dispatch(req)
File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 206, in dispatch
req.hdf = HDFWrapper(loadpaths=chrome.get_all_templates_dirs())
File "/usr/lib/python2.3/site-packages/trac/web/chrome.py", line 263, in get_all_templates_dirs
dirs += provider.get_templates_dirs()
File "build/bdist.linux-i686/egg/timingandestimationplugin/webui.py", line 140, in get_templates_dirs
File "/usr/lib/python2.3/site-packages/setuptools-0.6c6-py2.3.egg/pkg_resources.py", line 840, in resource_filename
return get_provider(package_or_requirement).get_resource_filename(
File "/usr/lib/python2.3/site-packages/setuptools-0.6c6-py2.3.egg/pkg_resources.py", line 1311, in get_resource_filename
return self._extract_resource(manager, zip_path)
File "/usr/lib/python2.3/site-packages/setuptools-0.6c6-py2.3.egg/pkg_resources.py", line 1317, in _extract_resource
last = self._extract_resource(
File "/usr/lib/python2.3/site-packages/setuptools-0.6c6-py2.3.egg/pkg_resources.py", line 1331, in _extract_resource
real_path = manager.get_cache_path(
File "/usr/lib/python2.3/site-packages/setuptools-0.6c6-py2.3.egg/pkg_resources.py", line 921, in get_cache_path
self.extraction_error()
File "/usr/lib/python2.3/site-packages/setuptools-0.6c6-py2.3.egg/pkg_resources.py", line 887, in extraction_error
raise err
ExtractionError: Can't extract file(s) to egg cache
The following error occurred while trying to extract file(s) to the Python egg
cache:
[Errno 13] Permission denied: '/root/.python-eggs'
The Python egg cache directory is currently set to:
/root/.python-eggs
Perhaps your account does not have write access to this directory? You can
change the cache directory by setting the PYTHON_EGG_CACHE environment
variable to point to an accessible directory.


メッセージ最後に出ているように環境変数「PYTHON_EGG_CACHE」を設定せずにプラグインをインストールした場合にブラウザ上に表示されたエラー。

対処方法は、このページの「1. TracBurndownプラグインインストールの事前準備」を参照



- エラーメッセージ3


The Trac Environment needs to be upgraded. Run trac-admin /home/trac/project1 upgrade"


プラグインを有効化した直後にブラウザに表示されたエラーメッセージ。

書かれているようにtrac-adminコマンドを実行する必要があります。

ただし、先にも書いたとおりDBにPostgreSQLを使用している場合は、「--no-backup」オプションが必要。

なので、


# trac-admin /home/trac/project1 upgrade --no-backup

を実行。



- エラーメッセージ4


Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 406, in dispatch_request
dispatcher.dispatch(req)
File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 237, in dispatch
resp = chosen_handler.process_request(req)
File "/usr/lib/python2.3/site-packages/trac/ticket/web_ui.py", line 290, in process_request
self._do_save(req, db, ticket)
File "/usr/lib/python2.3/site-packages/trac/ticket/web_ui.py", line 557, in _do_save
cnum=internal_cnum):
File "/usr/lib/python2.3/site-packages/trac/ticket/model.py", line 262, in save_changes
listener.ticket_changed(self, comment, author, old_values)
File "/usr/lib/python2.3/site-packages/TracBurndown-01.08.10-py2.3.egg/burndown/burndown.py", line 128, in ticket_changed
File "/usr/lib/python2.3/site-packages/TracBurndown-01.08.10-py2.3.egg/burndown/burndown.py", line 330, in update_burndown_data
File "/usr/lib/python2.3/site-packages/trac/db/util.py", line 51, in execute
return self.cursor.execute(sql)
File "/usr/lib/python2.3/site-packages/trac/db/util.py", line 51, in execute
return self.cursor.execute(sql)
File "/usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py", line 3111, in execute
raise OperationalError, msg
OperationalError: ERROR: null value in column "id" violates not-null constraint


burndown_job.pyを実行した場合、またTracBurndownプラグインを追加後に、チケットを登録しようとした際に出たエラーです。

対処方法は、「6. PostgreSQLを利用する場合の独自の作業」を参考に対処してください。


- エラーメッセージ5

File "/usr/lib/python2.3/burndown_job.py", line 81, in ?
main()
File "/usr/lib/python2.3/burndown_job.py", line 72, in main
cursor.execute("UPDATE burndown SET hours_remaining = '%f' WHERE date = '%s' AND milestone_name = '%s'"\
File "/usr/lib/python2.3/site-packages/trac/db/util.py", line 51, in execute
return self.cursor.execute(sql)
File "/usr/lib/python2.3/site-packages/trac/db/util.py", line 51, in execute
return self.cursor.execute(sql)
File "/usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py", line 3111, in execute
raise OperationalError, msg
libpq.OperationalError: ERROR: invalid input syntax for integer: "0.000000"

エラーメッセージ4と同じく、burndown_job.pyの実行時、チケット登録時に出たエラーです。

対処方法も同じく、「6.PostgreSQLを利用する場合の独自の作業」を参考に対処します。