kiwamu日記

Redmine の ERD を描いてみました

Rails

ちょっと前に Redmine を調べていたので載せておきます。機能としての特徴は書籍もいくつか出ているので、それらを参考にしながら触ってみればよしとして、書籍にないもう少し実装よりのところが気になるものです。

バージョンは以下のとおり。

% svn info

URL: http://redmine.rubyforge.org/svn/trunk

リポジトリ UUID: e93f8b46-1217-0410-a6f0-8f06a7374b81

リビジョン: 2819

まずは全体感を把握しようと、RailRoad を試してみました。Graphviz も忘れずにインストールしておきます。

% gem install railload
% cd redmine_home
% railroad -o controller.dot -C
% railroad -o model.dot -M
% neato -Tpng controller.dot > controller.png
% neato -Tpng model.dot > model.png

できあがった図はこんな感じです。RailRoad のオプションを変えるとラベルを追加できたり、他にもいろいろできますが、まぁこんな感じ。

• controller.png

• model.png

コントローラはともかくとして、モデルはもうちょっと見やすくしたいです。

ひとまず MySQL 向けに migrate しておいて、DB Designer でリバースエンジニアリングしてみました。で、これだけだと関連が何も描かれないので、モデルの has_many や has_one、belongs_to なんかを見ながら関連を加えてみます。そしてできあがったのが、以下の ERD。エンティティの位置も適当に動かして、少しすっきりさせてみました。

• ERD

あとは、Redmine を適当に動かしながら、レコードの生成具合いを見てみます。(まぁ、直接コードだけを追ってもいいのかもしれませんが、地道に遠回りしてみました。)

ユーザー登録

• ログイン登録すると、users テーブルにレコード生成
• 管理者に承認されると、ステータス (下記参照) が 2 から 1 に変化
• auth_sources は LDAP 連携とかしたときに利用されるみたい
• ちなみにデフォルトだと登録しただけじゃ、ユーザーはアクティブにならない

class User < ActiveRecord::Base

  # Account statuses
  STATUS_ANONYMOUS  = 0
  STATUS_ACTIVE     = 1
  STATUS_REGISTERED = 2
  STATUS_LOCKED     = 3

ユーザー承認

• ユーザー管理画面から「有効にする」
  • URL はこんなん
  • http://localhost:3000/users/3/edit?status=&user[status]=1
• これで users テーブルのステータスも ACTIVE に変わる

権限管理

• 種類は以下の 5つ: NonMember、Anonymous、管理者、開発者、報告者
• ロールはメンバーに対して複数指定できる
• roles テーブルの permission カラムに yaml 形式でつっこんである
• code review tools を導入したときは、plugin の migration を流すと管理者や開発者の permission に追記されている
• 余談ですが、code review tools の日本語化は中途半端
  • ロール -> 開発者 とかで開くと英語表記のまま

プロジェクトの作成

• projects テーブルにレコード生成
• 選択したモジュールも enabled_modules にレコード生成される

プロジェクトへのメンバー登録

• members テーブルにレコード生成
• 付与したロール分、member_roles テーブルにレコード生成

チケットの登録

• issues テーブルにレコード作成
• category_id はデフォルトでは null
  • カテゴリをあらかじめ用意しとけば、選択時にここに値がはいる
  • カテゴリはトラッカーごとには分けられない
• マイルストーンを定義してあると、fixed_version_id が設定される
• チケット監視者にチェックしとくと、watchers テーブルにもレコード生成

時間を記録

• time_entries テーブルにレコード作成
• チケットの経過時間の値が更新されることになる

関連チケットを追加

• チケットを作成してから、わざわざ関連づけしないといけないのがちょっとめんどい
• issue_relations テーブルにレコード生成
• issues テーブル上の変更はとくにない

チケットのカテゴリを追加

• issue_categories テーブルにレコード生成

チケットの編集

• journals テーブルにレコード生成
• journalized_id は該当する isuue_id
• journal_details に編集内容の詳細がはいる
  • ここで編集前後の値がすべて記録されるわけだ
• prop_key に変更項目名、old_value と value が記録される

フォーラムの追加

• boards テーブルにレコード生成

(フォーラムで) メッセージの追加

• messages テーブルにレコード生成
• parent_id は返答元の message_id
  • reply_count もインクリメントされるし、last_reply_id も更新される
• sticky カラムはなんだろ？

チケットへの添付ファイルの追加

• 添付ファイルが空のファイルだと無視されるが、そうでないと↓
• journal_details にも変更が記録される
• attachments テーブルにレコード作成
  • container_type は "Issue" になった
  • container_id は各タイプのモデルにおける id (ここでは issue_id の値をさす)
  • ちなみに文書への添付ファイルの追加だと、container_type は Document
• 添付ファイルは REDMINE_HOME のfiles 以下にファイル名に prefix をつけて格納される
  • これは文書やそれ以外での添付のときでも同じ
• 「添付ファイル」というメニュータブからの添付は、プロジェクトとしての成果物の公開のためっぽい
  • プロジェクトのバージョンを指定して公開できる

文書の登録

• documents テーブルにレコード生成
• 前述のとおり、attachments テーブルにもレコード生成

カスタムフィールドの追加

• custom_fields テーブルにレコード生成
• possible_values には Yaml 形式でつっこまれている

カスタムフィールドの編集

• custm_values テーブルにレコードが生成
  • カスタムフィールドの値として入力/選択した値がはいっている
• customized_type は attachments テーブルの container_type と似てる
• customized_id は対象となる user_id だったり issue_id だったり
  • カスタムフィールドは、プロジェクトやユーザー、チケットなどを対象に追加できる

バージョンの追加

• プロジェクトの設定でバージョンの追加
• versions テーブルにレコード生成
• チケット作成/更新のときに、対象バージョンを設定できる
• バージョンを 1つでも追加すると、ロードマップのメニューが増える

カスタムクエリの追加

• チケットの絞り込み用のクエリ
• ユーザーごと、プロジェクトごとに作成可能
• queries テーブルにレコード生成
• filter カラムに Yaml 形式で条件がはいる

Wiki の作成

• wikis、wiki_pages、wiki_contents、wiki_content_versions テーブルにレコード作成

wiki のページ名の変更

• wiki_redirects テーブルにレコード作成

あとは、Subversion や Git などの SCM と連携させると、repositories テーブルにレコードが生成されたり、トラッカーを追加したら trackers テーブルにレコードが生成されたりします。また、GUI からチケットの承認フローを編集すれば、workflows テーブルが書き変わります。ちょっと変わっているのは enumerations テーブルで、チケットの緊急度やドキュメントの種類、アクティビティなどのデフォルト値がまとめて書かれてたりします。

ざっとこんな感じですが、テーブルの構造や役割がはっきりしているとコードも頭に入りやすいと思います。と言うのは古いのかもしれませんが...？ (^^;

機能や導入、運用あたりについては以下を参考に。

Permalink | コメント(2) | トラックバック(2) | 23:26