2011-02-20

2/17: デブサミ 2011 / チケット管理システム大決戦

はじめに: ずーっと一参加者としての参加なので、非常に申しわけないのです..。

ただ、平日夕方や土日になかなかIT系のイベントに参加できない身のわたしにとっては、平日の昼間で東京での開催 / 参加費無し というのは凄く有難い催しです。
子どもが生まれてからの数年、なんとかこのイベントだけは参加するようにしています。

本当は通して2日間参加したいなあと思ったのですが、さすがにそれは厳しかったので、今年の参加は2/17の午後のみ、となりました。

参加したセッションは、下記の通りです。

はじめは1本のブログ記事にまとめようと思ったんですが、あまりにも長くなってしまったので(汗)、今回は『チケット管理システム大決戦』のみ取り上げます。

メモを取りながらの参加でしたが、聞き違い・認識間違いもあるので、そのあたりはご指摘いただければ幸いです。

* * *

【17-B-4】 チケット管理システム大決戦 JIRA vs Redmine vs Trac 〜ユーザーが語る、なぜ私はこのツールを使うのか

こちらは、本日もっとも楽しみにしていたセッションです。広い会場ですが、人もたくさん!デブサミ始まって以来、一番の参加人数だったとか、あとで聞きました。気が付くと、同じ会社の方が1つおいた隣の席に座っていました。(先方はTrac派です)

実は、3つのBTS(ITS)についてのアツい戦い(!)を想像していたのですが、割と穏やかに、それぞれの特徴を紹介し、違いを認識し合うような形で進んでいました。

どちらかというと、共通の敵は『Excel』であったり、『プロジェクトマネジメント上、進捗管理やリスク管理にかかるコスト』である、という共通の認識で、こちらを使えばこうだよ、というのをお話ししてくださった感じです。

Redmineは実際使っていますし、Tracも別の部署が立てているものにアクセスしたりして、概要は知っているので、このあたりは「ふむふむ」という感じで聞いておりました。

20110217-1

0. はじめに – Issue Tracking Systemについて / 大澤さん

まずは、モデレータの大澤さんのお話し。スピーカーの方のご紹介から始まり、Excelを代表とする、プロマネのファイル上に記録されたチケット・タスクの管理の煩雑さを表すディレクトリの例を上げて下さっています。

(わたしの部署でも、企業内に閉じたプロジェクトであれば、ITS・BTSで管理する方向になっていますが、人によっては紙のWBSを作らないとダメ、細かい計画を立てないとダメ、というポリシーの方もいます。)

  • WBSを作っても、あとになるほど現状と乖離してしまい、保守に1日のほとんどを費やすことになってしまう。
  • ガントでしかリスクが見えなくなってしまい、タスクの依存関係はそこからは見えてこない、という状況になってしまう。

そうしたコストを減らすためにITSを使おうという認識は、会場の皆さんも含め一致したかと思います。

1. Tracについて / 吉羽さん

吉羽さんも、かつては複数のプロジェクトを一度にマネジメントしないといけない立場だったそうで、その時は一日1000件ものメールがあったとか。(さすが、処理の限界がありますよね…)

メールだとプロジェクト全体が把握できない、プライオリティ付けがうまくできないと仰っていて、その例をこんな風に表現されていました。

  • 後入れ先き出しになってしまう、と。

また、メールや口頭でのコミュニケーションだけでは、行き違いや認識違いが発生してしまうこともあり、そういった状況に対応しないといけない場合の、見えないコストが高いとも仰っていました。

さらに、メンバーが変わった時に、今までの情報の共有や、スキルトランスファーがメールでは難しい、ということも。

伺った限りでの、Tracの特徴は、下記の通り。

  • インストールが簡単である。
  • 吉羽さんが導入しようとした際は、他に選択肢が無かった、という理由もある。
  • プラグインが非常に豊富で、100以上ある。(http://trac-hacks.org/
  • レポートクエリが強力で、Trac用のクエリ&SQLのクエリの双方で記述できる。
  • お客さん向けの報告書をまとめるときにも、レポートは非常に重要!

2. Redmineについて / あきぴーさん2. Redmineについて / あきぴーさん

Redmineは実際使っているので、どちらかというと、自分が『これはイイ!』と思っている点が、他の皆さんにもあてはまるかどうか、の再確認として伺っていました。

やはり、プラグインの追加無しで、チケット管理だけでなく、バージョン管理やWik・フォーラムなどのコミュニケーションツール、ガントチャートの利用ができる点は、管理する側にとっては楽だと感じています。

あきぴーさんの仰る通り、わたしもバージョン(ロードマップ)の使い方がうまく理解できたのは、Redmineを使ってからでした。

  • Redmineはデフォルトでも集計・レポート機能が使える。
  • チケットのバージョン紐づけて使うことで、進捗の管理が行いやすい。

なお、海外ではRedmineの利用は少ない、というお話しがありました。これについては、@haru_iida さんのブログに面白いデータが載っています スマイル

3. JIRAについて / 鈴木さん, 大澤さん

一方で、JIRAについての知識がほとんどなかったので、鈴木さん、アトラシアンの大澤さんのお話は、貴重な収穫になりました。

Jenkins (旧Hudson)のIssue Trackerのプラットフォームとして使われているので、私もバグレポートのためにアカウントを作り、触ったりしてはいるのですが、てっきり有料だと思っていました…。

伺った限りで、JIRAの特徴をまとめておきます。

  • 基本はチケット管理に特化したもの。チケット管理しかしない。
  • 1つのJIRAで、マルチプロジェクト(複数プロジェクト)での利用が可能。
  • チケット管理の機能はシンプルに作られている。
  • ワークフロー設定が柔軟にできている。(ただし、設定が非常に難しい or 煩雑らしい?)
  • Office製品との連携が可能で、Excelだけでなく、Wordにも出力できる。(マネージャ向けには便利)
  • アトラシアンの自社開発で、まず自分たちで使い、フィードバックし、製品としてリリースするスタイルを取っている。この点については、大澤さんは、『ドッグフーディング』と表現されていた。
  • ソースコードはオープンである。
  • オープンソース開発でJIRAを利用する場合は、無償で利用できる。(じゃあ、Jenkinsもそうなんですね!)
  • 10名のプロジェクトなら、月額1000円で利用できる。
  • 1000円と言っても、じつは名のある基金への寄付金に充てられる。
  • プラグインという形ではなく、JIRAとは別のアトラシアン製のモジュールを併用することで、拡張ができる。

「ドッグフーディング」について、このレポをまとめている間に気になったので、検索をしてみると、ズバリ、大澤さんのブログそのものが一番にヒットしました。

ドッグフーディングと頻繁な内部リリース: http://blogs.atlassian.jp/2009/12/post-12.html

  • ドッグフーディングとは、自分たちの製品を使用することをまさに意味しています。これは、素晴らしい原則です。
    なぜなら、自分たちのソフトウェアを使用することにより、顧客と同じような痛みを共有することが出来るからです。

もちろん、アトラシアンに限らず、いろんなところでそういう開発はされていると思いますが、端的に表す言葉として、これはいいなあと感じました。
また、アトラシアンの方は、チケットに登録することを『JIRAっといて』と言うのだそう。なかなか良い言い回しですよね。

#単純な私は、『JIRAっといて』と言いたいばかりに、JIRAを試してみようかな、と強く思いました。月1000円なら主婦のお小遣いでも捻出できますので…。

4. フリーの討論

ひととおり各ITSの紹介が終わった後は、フリースタイルの討論になりました。
ここから先、メモしたものを書いてみます。

  • 案件のかけもちがなく、みんな同じ場所にすぐ集まれるなら、アジャイル的にポストイットでタスク・進捗を管理するのが一番。
  • でも、ISMSの規定により、「カベに貼るな!」という決まりになっているところもあるのだそう…。(切ないですね)
  • 朝会のときにだけ貼り出し、あとは巻いてしまっておく、という涙ぐましいやり方もあるらしい。
  • BTS・ITSを導入すると、たくさんチケットやタスクを積みたがる人が出てくる。どういった粒度で記録するか、この辺をうまくコントロールすることが大事。
  • 仕様書とWikiの使い分けは?
  • 履歴管理が必要な仕様書はSVNに、プロジェクトを遂行するために共有すべき情報やテスト、振り返りといったものは、Wikiに記述する形で使い分けている。(あきぴーさん)
  • アジャイル開発だけではなく、ウォーターフォール型の開発でも、特にバグトラックのフェーズではITS/BTSの導入は有効。

チケットがすべてか?という問いには、こんな意見が。

  • なんでもTrac,メッセで済まそうとしてはダメ。
  • 本当に必要なもの、共有したいもの、残しておきたいものをプラットフォーム上に残すこと。
  • 一過性の会話で、すぐに解決してしまうものならチケット化する必要は無い。
  • 大事なのは、やはり Face To Face だよ。

また、使い方のポイントとしては、こんな意見も。

  • 導入だけじゃ効果がでない。チームで使い方、運用方法を決めないとダメ!(吉羽さん)
  • 使うならプロジェクトの最初から使おう。
  • プロジェクト成功のための『場』として、全員がつねに見るんだというように教育することが大事
  • 毎日使う、毎日更新。
  • 積まれたタスクは放置しない。ゴミ箱のような状況になるのを放置しない。
  • タスクが多ければ多いほど不健康なプロジェクト。週1回は放置チケットをチェックし、アラートを上げるなどの方法で、棚卸すること。
  • プロジェクトのふりかえりと一緒に、ツールそのものの使い方についての振り返りも行い、改善を図ること。(あきぴーさん)

JIRAについては、まだ商用(有償)ベース、日本語の情報が少ないといった課題を上げ、これから拡販を目指すとのことです。

20110217-2

5. 補足 / 感想

セッションのタイトルの、「なぜ私はこのツールをつかうのか」というテーマなんですが、それぞれ良いところがあるし、どれが一番とは言えないなあと感じました。

セッションの最後でも、「どれが一番、というのではない。プロジェクト毎に一番フィットするものがあるかもしれない」というコメントが出ていました。
まあ、もしかしたらその後のLTやShibuya.tracの勉強会で、アツい戦いが繰り広げられていたのかもしれませんが…。

レポを書いている間に、いろいろとプレゼン資料や比較表がアップされていたので、下記に貼っておきます。

また。今回のセッションをきっかけに、JIRA、Mantis、そしてKanonといったBTS/ITSについての話題もハッシュタグ (#itsjp)に乗っていろいろ出てきたのは、とても有難いことです。

* * *

実は、個人的には、TracはTrac月を入れようとして挫折した経験があります…。

当時、なぜ難しかったのか思い起こすと、素のTracだけでは機能がシンプルすぎて何か追加しようとしても敷居が高すぎたこと、それから、リポジトリとTracが同じサーバにないとダメだったこと、マルチプロジェクトに対応していないことがネックになったような気がします。

ちなみに、Tracは、私にとっては『漢(おとこ)らしい』とか、『エンジニア気質』といったイメージがあります。
そういうイメージが、Shibuya.trac のロゴに出ているかな…と思っています。

今はもっと簡単になっているかと思いますが、もともと、産休前に自分のタスクを引き継いでもらいたくて、何か管理しやすいものは無いかと思ってBTSを探したのが始まりです。

ただし、自分はあと3か月くらいでいなくなってしまうので、そのあとに設定が難しいシステムもろとも、引き継ぎ担当者に渡すのは申し訳ないなあ…と判断し、一回入れれば済むだけのRedmineに軍配があがりました。

そんなこんなで、「なぜそのツールを使うのか」というと、人と人とのように、プロジェクトにもそのツールと出会う『縁』みたいなものがあるのかもしれませんね。

Face To Faceのやりとりの大切さは、スピーカーの皆さんが仰っておりましたが、会話の中で出てきた本当に共有すべきことや、お互いに合意し合った証、アイディアの種は、大切にプラットフォーム上に記していきたいな、と思いました。
きっと、あとでITS上のタイムラインを眺めることで、自分たちのプロジェクトの軌跡をたどることができる、大切な『場』になってくれるんじゃないかな~、と思っています。

2011-02-19

Hudson to Jenkins (トライアル)

1. まずはいつも通り考えなしに

そろそろHudsonの騒動(?)も落ち着いてきたことと、曽我部さんがEmail Extension Pluginの修正をしてくださっているようなので、バージョンアップを止めていた某Hudsonも更新しなくちゃな…と思い出しました。

ただし、メインで皆で利用しているHudsonは、いきなり変えるとまずいので、まずはよろず目的で使っているHudsonを変更し、移行のノウハウを貯めることに。

バージョンアップに当たっては、毎時実行しているジョブもあるので、いきなり変更はまずいだろうから、jenkins.war をダウンロードして、別ポートで起動して確認しよう...と思いました。

でも、『そういえばCentOSは、rpmでインストールできるんだった….』ということに気が付き、jenkins-ci.orgをチェックすると、RPMのインストール手順も、ちゃんとJenkins用に書き換わっていたのでした。

手順を見て、じゃあKeyのインポートだけしようかな….というつもりが、ついつい、 指は yum install jenkins  と打ち込んでいました…。

* * *

面白かったので、下記、インストールログ。(一部省略)

# sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
--2011-********-- http://pkg.jenkins-ci.org/redhat/jenkins.repo
pkg.jenkins-ci.org をDNSに問いあわせています... 63.246.20.93
pkg.jenkins-ci.org63.246.20.93:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 76 [text/plain]
`/etc/yum.repos.d/jenkins.repo' に保存中
100%[===================================================>] 76 --.-K/s 時間 0s
(6.40 MB/s) - `/etc/yum.repos.d/jenkins.repo' へ保存完了 [76/76]
# sudo rpm --import
http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
# yum install jenkins
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
* addons:
ftp.jaist.ac.jp
* base: ftp.jaist.ac.jp
* extras: ftp.jaist.ac.jp
* rpmforge: fr2.rpmfind.net
* updates:
ftp.jaist.ac.jp
…………
80 packages excluded due to repository priority protections
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package jenkins.noarch 0:1.397-1.1 set to be updated
--> Finished Dependency Resolution
Dependencies Resolved
=============
Package Installing:
jenkins noarch
replacing hudson.noarch 1.371-1.1
Transaction Summary
=====================================
Install 1 Package(s)
Upgrade 0 Package(s)
otal download size: 35 M
Is this ok [y/N]: y
Downloading Packages:
jenkins-1.397-1.1.noarch.rpm 35 MB 01:59 Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : jenkins 1/2 mv: cannot stat `/var/lib/hudson/*': そのようなファイルやディレクトリはありません
Erasing : hudson 2/2 warning: /etc/sysconfig/hudson saved as /etc/sysconfig/hudson.rpmsave
warning: /etc/init.d/hudson saved as /etc/init.d/hudson.rpmsave
Installed:
jenkins.noarch 0:1.397-1.1
Replaced:
hudson.noarch 0:1.371-1.1
Complete!

サービの確認をしてみると、/etc/rc.d/init.d/hudson が無くなって (hudson.rpmsaveに変更)、 /etc/rc.d/init.d/jenkins に変わっていました。

で、調子にのって再起動。
hudsonのサービスはなくなっちゃってるので、hudsonの停止はエラー。でも、jenkinsは正常に起動しました。

[root@hudson-slave tmp]# /etc/rc.d/init.d/jenkins restart
Shutting down Jenkins [失敗]
Starting Jenkins
[ OK ]

プロセスの実行ユーザも、Jenkinsさんになっています。

# id jenkins
uid=102(jenkins) gid=106(jenkins) 所属グループ=106(jenkins)
context=root:system_r:unconfined_t:SystemLow-SystemHigh

Hudsonの場合は HUDSON_HOMEを/home/hudson にしていましたが、RPMのデフォルトは/var/lib/xxxx なので、JENKINS_HOMEも /var/lib/jenkinsになっています。

起動を確認すると、JENKINS_HOME が変わっているため、当然ジョブは何も無く、アカウント情報もまっさらな状態。

過去の資産を引き継がないといけないので、さてどうしよう?

2. 過去の資産をひきつぐ作業

大した仕事はしてない Hudson 改め Jenkinsさんですが、上司のよろずジョブも管理するというミッションを負っているため、そのままだと上司からクレームが来ます(汗)。

とにかく、従来使っていた、/home/hudson を引き継ぐところから始めました。 (このあたりは自己責任でお願いします…)

    • まずはいったんJenkins停止。(/etc/rc.d/init.d/jenkins stop)
      こわいので /var/lib/jenkins をmvしてバックアップしておく。
    • /var/lib/jenkins の中身を、/home/hudson で入れかえ。
    • chown -R jenkins:jenkins /var/lib/jenkins でOwner調整。
    • jenkins再起動。

さっそくアクセスすると、マスタ/スレーブの設定も引き継がれているようです。ジョブの一覧もちゃんと表示されました。

ちょうど、Jenkinsのコミッタの曽我部さんが、Email Extension Pluginの新しいバージョンをリリースしたと呟かれていたのを発見したので、同プラグインを入れ替えてみようとJenkinsの管理画面を参照したところ、下記のメッセージが。

jenkins-ci


さすがに『無視』もどうかと思ったので、『管理』のボタンを押すと、下記のような画面が表示されました。

jenkins-ci-2


旧データは無かったのですが、読めないデータとしていくつかリストが上がっていました。
ただし、あまり重要なジョブではないので、ここはあっさり『読めないデータを無視』ボタンを押すことに。

すると....。

Status Code: 500

Exception:
Stacktrace:
java.lang.NullPointerException
  at hudson.model.AbstractItem.getRootDir(AbstractItem.java:116)
  at hudson.model.Items.getConfigFile(Items.java:124)

IEだけかと思ったのですが、Firefoxでも同様の現象になってしまいました。
ちょっとここは良くわからなかったので、いったんJenkinsの管理に戻り、『無視』のボタンを押したところ、エラーや警告メッセージが出なくなりました。

あとでJenkinsのJIRA (BTS)の報告をチェックしてみようと思います。#JIRAっとこう、という表現になるのかな。

3. スレーブとの調整

さて、よろずJenkins には、Windowsスレーブと、CentOSのスレーブがいます。
接続の確認をしたところ、下記のようなパターンになりました。

    1. DCOM経由のWindows Slaveの起動 -> スレーブのAdministratorアカウント&パスワードを指定するため、問題無し。
    2. SSHによる起動 -> 公開鍵を利用する場合は、鍵の場所をカスタマイズしていたり、OwnerがJenkinsになっていないとNG.

2に関しては、マスターのJENKINS_HOME以下を、chown -R jenkins:jenkins して、Ownerを丸ごと変えたので、で問題なくなりました。
ただし、スレーブの接続先のアカウントは、勝手にJenkinsに変わるわけではありません

そのままでも問題無さそうですが、とりあえず変更したほうが気持ちがいいかな、と思って、スレーブの設定を、下記の通りにしてみました。

  • RemoteFSの変更: /tmp/huson -> /tmp/jenkins にしました。
  • スレーブ上の実行アカウントを hudson -> jenkinsに変更:
    ユーザ追加ではなく、/etc/passwd と /etc/group と、HOMEの変更を実施

/etc... の編集は、あまりお勧めできません。(というか、何やってんだ、コラ!というご指摘があればぜひ頂戴したいところです…)ご利用は自己責任で(^^;

が、とりあえず、これでうまくいっているようです。おかげ様で、久しぶりにプラグインの更新もできました。

もう少しノウハウをためて、メインで利用しているHudsonも、Jenkins化を検討していこうと思います。

2011-02-04

BitNami Redmine Stack + NetBeans + FastDebugger

ちょっとハマったので、メモです。

Redmineプラグインハンズオンのため、環境を整えていたのですが、NetBeansでコーディングをするのは初めて。

BitName Stack付属のRubyをNetBeansで指定するところは出来たのですが、デバッグを実行しようとすると、Fast Debugger入れてね、というダイアログが出現。

でも、なんだかんだでデバッガのインストールがうまくいかずじまい…。

IDEでコードを書けるようになった、IDEからRedmineを起動できるようになっただけで、だいぶ進歩なのですが、プラグインのおさらいでコードを書いているうちに、どうしてもデバッグしてチェックしたい箇所が出てきました。

少し探したところ、こちらの記事を発見。

まったくもって、ありがたや、です。

記事の通りに、ruby-debug-base, ruby-debug-ideを自動ではなく先にダウンロードしてから、ローカルインストールを行ったところ、なんとかデバッグできるようになりました。

私の環境はNetBeans6.9.1 + Ruby1.8.7-p249 だったのですが、上記の記事に注意書きがある通り、ruby-debug-ideは、ruby-debug-ide-0.4.6.gem を使いました。

(それ以上のバージョンを試してみると、やはりエラーになってしまいました。最新のものでもだめなようです)

デバッグに限らないのですが、IDEを通すと、Webricの起動からログの参照、Redmineのプラグインのassets以下が、Redmine直下の  public/plugin_assets/ にコピーされる様子も1画面で参照できるので、これはなかなか面白いですね。(あ、ホントだ!と思いました)

 

* * *

上記の記事を書かれていたBlogでは、NetBeans6.9.1 & Ruby1.9.1の組み合わせについても書かれていました。こちらも、とても助かりました。

自分はなかなかBlogを書く時間が取れないので、なおさら、時間を割いて書き残してくださっている皆さんには頭が下がる想いです。どうもありがとうございました!