Redmine入門 - プロジェクト

Redmine では基本的にデータをプロジェクトごとに管理します。 Redmine を使っていくためには、このプロジェクトを作成する必要があります。

プロジェクトの単位

プロジェクトは開発の単位で、プログラムライブラリをプロジェクトとするのが一般的です。
複数のプログラムで構成されるシステムをプロジェクトにすることも出来ます。 プロジェクトは階層構造にすることができるので、 そういった場合はシステムのプロジェクトの下にプログラム単位のサブプロジェクトができることになります。

お勧めできないのは、年度ごとや大きな機能追加をプロジェクトの単位とすることです。 こういったものをプロジェクトと呼ぶことはあると思いますが、 後で説明するバージョン管理システムとの連携もあり、バグはソースに対して管理した方がよいため、 なるべくソースの構成に基づいたプロジェクトにした方が管理しやすいです。

例えば、あるプログラムが Windows 版、 Linux 版または Standard 版、 Professional 版といったように別々のプログラムになっていたとしても、 ソースコードが一元管理されているのならば、同一プロジェクトするか もしくは 同一プロジェクト内でサブプロジェクトで分けるようにした方が管理しやすいと思います

プロジェクトの作成

プロジェクトを作成する場合、次のリンクを選択します。
  • トップレベルのプロジェクトであれば、 プロジェクトの一覧の [新しいプロジェクト]
  • サブプロジェクトであれば、プロジェクトの概要ページの [新しいサブプロジェクト]
このメニューが表示されない場合は、ログインしていないなどの理由でプロジェクトを作成する権限がないためです。

rt_project.png

rt_project_sub.png

メニューを選択するとプロジェクトの作成ページになります。
作成ページで指定する項目のうち、識別子だけはシステム管理者でなければ、後で変更することが出来ないので、スペルミスなど入力には注意してください。 それ以外はプロジェクトの設定ページで変更できます。プロジェクトの親子関係も権限の範囲内であれば変更可能です。

rt_project_new.png

プロジェクトの削除

権限が許す範囲内で、一般ユーザーでもプロジェクトは自由に作成することが出来るのですが、 削除はシステム管理者にしか出来ません。
間違えられないとなってくると構成をいろいろ試したりといったことはやりにくいです。 そういった場合には以下のプラグインを入れると、自分の作ったプロジェクトであれば削除ができるようになります。


 

Redmine入門 - ロールと権限

プロジェクトができたところで、プロジェクトに開発メンバーを追加します。
このとき、メンバーに対してプロジェクトにおける 役割(ロール) を決めます。 この割り振られたロールによって できること(権限) が変わってきます。

ロールの種類

Redmine のデフォルトのロールは 3 種類です。
ロール 説明
管理者 プロジェクトリーダー。プロジェクト内のすべての操作が出来ます。
開発者 ソースの修正など実際の開発を行う人
報告者 バグ報告などをする人。実際に開発を行わないプロジェクト関係者
権限としては以下のように設定されていることが一般的です。
管理者 > 開発者 > 報告者

ロールの決め方

ロールの設定の例として、次のようなプログラムで構成される Foo システムがあったと仮定します。
  • GUI フロントエンド
  • 共通ライブラリ
  • コマンドラインプログラム A
  • コマンドラインプログラム B
そして、この各プログラムの開発者およびプロジェクトリーダー、テスターがそれぞれ一人いたとします。

このシステムのプロジェクトの場合はロールの決め方は簡単です。 プロジェクトリーダーが管理者、テスターが報告者で、残りのメンバーが開発者となります。

各プログラム、ライブラリごとにサブプロジェクトを作った場合にはどうなるでしょうか

まず、各プログラムの開発担当者が管理者 兼 開発者となるのが自然でしょう。
管理者であれば、開発者の権限をすべて持っているので、開発者のロールは不要です。 しかし、誰が開発しているか明確になるので、両方のロールをつけておいた方が私は分かりやすいと思います。

次に残りのメンバーです。
例えば、コマンドラインプログラム A に対して GUI 担当者が不具合を見つけてバグ報告をするということはよくあると思います。 そのため、 Foo システムの残りのメンバー全員が報告者となります。
このとき、 Foo システムのメンバーでグループを作っていると一人づつ登録する手間が省けて便利です。
プロジェクトリーダーがサブプロジェクトで報告者と管理者のどちらがいいかというのは、場合によるので、 やりやすい方でいいと思います。

実際の運用では、プロジェクトメンバーでなくても、バグ報告を出せる設定にしてあることが多いです。 そのため、報告者はどちらかというと、管理者でも開発者でもないプロジェクトの関係者という意味合いが強いと思います。

権限

どのロールがどんな操作をできるのかという権限の情報は通常、システム管理者でしか確認することが出来ません。
それだと使いづらくはないでしょうか。そんな時は拙作 Redmine インフォメーション プラグインをインストールしてください。
以下の順でリンクを選択すると、ロールの可能な操作の一覧が表示できます。
  1. トップメニューの [情報]
  2. サイドバーの [権限レポート]

rt_role.png

ここに出てくる Anonymous は誰だかわからない人、 すなわちログインしていない(アカウントを持っていない)人で、 Non member はログインしているけど、プロジェクトのメンバーではない人です。

サンプルの画面はデフォルトの設定です。
今まででできた話題でいうと、メンバーの追加などの管理やサブプロジェクトの作成はそのプロジェクトの管理者でしか出来ません。
プロジェクトの追加は若干分かりづらいですが、どこかのプロジェクトで管理者になっていれば、 トップレベルのプロジェクトを追加することができるようになります。
[チケットの追加] はバグ報告といったことにあたります。 このバグ報告は Non member すなわち Redmine ユーザーであれば、誰でも出来ます。
また、その報告の閲覧はログインしていない人でも見ることが出来ます。
ただし、これはプロジェクト設定で[公開]を選択している場合で、 公開していなければ、プロジェクトメンバー以外はチケットの追加はもちろん、みることも出来ません。

また、 - は設定が有効になっていないという意味ですが、 - も無いのものは設定することが出来ません。
例えば、"チケットの追加"はシステムの設定しだいで Anonymous (Redmine ユーザー以外)でも追加できますが、 "プロジェクトの追加"は Anonymous が追加できるようにすることは出来ません。

ユーザーの追加方法

ユーザーの追加はプロジェクトメニューの [設定][メンバー] タブから行います。
サブプロジェクトを作った時には作った人は自動的に管理者としてメンバー登録されています。

追加する場合、 Redmine に登録されたユーザーが多いと選択するのが面倒です。 検索ボックスに名前またはメールアドレスの一部を入力するとメンバーが絞り込みが起こります。

rt_member.png


 

Redmine入門 - チケットとバージョン

Redmine はバグ管理、プロジェクト管理のシステムです。
これらの用途に使用するためには、チケットを使います。

トラッカー

チケットはバグ報告、機能追加のタスクのどちらにも使用します。 このチケットの種類を決めるのが、トラッカーでデフォルトでは以下の 3 種類です。
トラッカー 用途
バグ 不具合報告
機能 機能追加
サポート 不具合修正、機能追加のどちらでもない作業

ほとんどの場合、開発作業はバグまたは機能にわけることができると思います。 ただ、テスト環境の準備といった直接には開発に関係のない作業が必要なときもあります。 こういうときにはトラッカーをサポートにしたチケットにします。

これで足りないなというときは Redmine では新しくトラッカーを追加することもできます。 また、チケットの種類を細分化したいというときは、 カテゴリを使用します。
トラッカーの追加はシステム管理者のみが可能で、システム全体に対してトラッカーを追加するのに対して、 カテゴリはプロジェクトの [設定] ページで追加できます。
デフォルト以外のものが欲しくなったとき、トラッカーを追加するかカテゴリで分けるかというのは難しいところですが、次回説明するワークフローを変えたい場合にはトラッカーの追加となります。
いろいろとトラッカーを追加したいと思われることは多いと思いますが、 やりすぎると混乱のもとになります。この 3 つでも結構十分なので、使いなれてくるまではこのままで、やってみるのがいいかなと思います。

バージョン

チケットはバージョンに関連づけることが出来ます。
バージョンは通常 1.0.0 、 1.5.3.42 のような型式ですが、まだ明確にきまっていない場合は "初期開発" や "Linux 移植" といった内容を表す名前でもかまいません。後から名前を変更することも出来ます。

[ロードマップ]ページでバージョンに関連づけられたチケットの一覧と バージョン全体での進捗をみることができます。
このバージョンが完了した時、 このロードマップがちょうどリリースノートのようになるようにチケットを作るのが、基本的な使い方ではないかと思います。

rt_roadmap.png
このため、バージョンの使い方で一つ注意点があります。
バグ報告で対象バージョンを指定する場合、 対象バージョンバグの発生したバージョンではなく、 バグを修正するバージョンを指定することです。
バグをどのバージョンで修正するかは開発側が決めるものなので、 もし自分が開発者ではない状況でバグ報告を出す場合、 チケット作成時に対象バージョンは指定しないようにしてください。

バージョンの作成

新しいバージョンはプロジェクトの [設定] ページから作成します。
rt_version.png
ステータスは作成時には [進行中] のままにしておきます。
バージョンをリリースするなどして完了した時に [完了] にします。 [ロック中] は保留のような状態になります。 Wiki ページはバージョンにもっと詳しい説明をつけたい場合にページ名を書いておきます。 ページの内容がロードマップの説明に追加されます。
ページは後で修正できますし、まだ存在していないページの名前でも構いません。

共有は前回あげた Foo システムの例のようにプロジェクトが複数のサブプロジェクトを持つ場合などで使用します。共有しておけばサブプロジェクトのチケットも同一のバージョンに関連づけれれるようになります。
共有範囲は細かく選択できますが、共有するようなバージョンは親のプロジェクトで作成することが多いので、 [すべてのプロジェクト] 以外はどれを選んでもあまりかわりません。

バージョンの追加


チケット編集時にも + のボタンを押すことによって、新しいバージョンを追加することができます。
rt_version_add.png
細かい設定はできませんが、チケットを編集する時に気づいて、 [設定] ページに戻って作ってから、 再度、チケットを編集するという手間が省けて便利です。
後から変更もできますし、バージョンを作成するときにそんなに細かい設定が必要ないことが多いので、 バージョンは結構こちらで作成することの方が多いです。

ただし、バージョンがひとつもないとバージョンの項目自体が出てこなくなり、 チケット編集画面でのバージョンの作成はできません。


 
このページをシェア
アクセスカウンター
アクセスランキング
[ジャンルランキング]
コンピュータ
22位
アクセスランキングを見る>>

[サブジャンルランキング]
プログラミング
3位
アクセスランキングを見る>>
カレンダー(アーカイブ)
プルダウン 降順 昇順 年別

08月 | 2019年09月 | 10月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 - - - - -


はてな新着記事
はてな人気記事
ブロとも申請フォーム
プロフィール

yohshiy

Author:yohshiy
職業プログラマー。
仕事は主に C++ ですが、軽い言語マニアなので、色々使っています。

はてブ:yohshiy のブックマーク
Twitter:@yohshiy

サイト紹介
プログラミング好きのブログです。プログラミング関連の話題や公開ソフトの開発記などを雑多に書いてます。ただ、たまに英語やネット系の話になることも。