開発環境に関わるメモ
今月で今やってる仕事の契約が切れるので,ここで培ったノウハウなどをメモしておこうと思う。
しかし,今後この手の開発系の仕事ができるとは限らないってのが悲しいところ。
プロジェクトポータルまわり
とりあえず,Subversion(SCM), Trac(ITS/Wiki), Hudson(CI)は必須。この3セットがないプロジェクトなんてうんこ。
とにかくTrac-Subversionの連携が強力なので,Subversion以外のSCMは無視していい。HudsonはCIつうよりプロジェクトダッシュボードとして使うのが吉(数あるプラグインを有効利用しよう)。
- marsのメモ - Trac
- marsのメモ - MacroBazaar - The Trac Project
- marsのメモ - 角谷HTML化計画(2006-04-25)
- marsのメモ - trac-post-commit-hookが便利すぎる
- marsのメモ - tractabpluginをインストール
- marsのメモ - TotoriseSVNとTracの連携
- marsのメモ - Kohsuke Kawaguchi’s Blog: Hudson 1.122 and build/test matrix
- http://labs.airs.co.jp/2007/7/19/trac_useful_tips
Subversionといえば,ブランチ-マージは必修科目。これホントに便利で,もうブランチ使ってなかった時が信じられないってくらいに便利。ただ,ブランチの運用をはじめたのはメンテナンス・フェーズに移ってからで,初期開発時はメインライン一本でやっておりましたよ。はい。
今回やってたブランチの運用ルールは,こんな感じで,trunkが安定ラインとリリース候補ラインを兼務。マージしたら,ブランチのフォルダ名を「-CLOSED」にリネームするのが,ちょっと異端。
ビルドスクリプト
もうAntでいい。:-)
Mavenの魅力は,インハウス・リポジトリを用意できるかどうかだと勝手に思っているので,用意できなきゃムリしてMavenizeする必要もないかなと。
ビルドスクリプトにbuild.xmlを使うかどうかは,NetBeans使いがいるかどうかで思案したほうがいい(あたしは,build.xmlは使わない事にしている)。それと,XML嫌だからAnt以外のビルドツール使うってのは,あんまりオススメしない。
ビルドスクリプトとCIネタであるが,ビルドした生成物にはビルドナンバーとリリースビルド/スナップショットビルドなどがわかる識別子を必ず埋め込むこと(そんでもって,その確認手段も)。これ,とっても重要。
あと,ビルドスクリプトは目的に応じて数種類作っておくことをオススメする。
- marsのメモ - Ant and Maven
- marsのメモ - Rabbitのサンプル:『ビルドツールを知ろう』
- marsのメモ - NetBeansのbuild.xmlとnbprojectはSCMに突っ込んでヨロシ
- marsのメモ - Ship It!のヒント3「必要なものはチェックインしておくこと」で目が覚める
- marsのメモ - Artifactory
- marsのメモ - 自分がなかなかMavenizeできない言い訳を淡々と記録するよ
- marsのメモ - Buildr
- marsのメモ - メンテナンス・リリースを「サービスパックなんたら」とか「アップデートなんたら」と呼ぶのはどうか?
テスト
JUnitは鉄板。Seleniumは便利なんだけど,CIで自動運転させるのにちょいと工夫がいるのが難点だが,これほど便利なツールはないので,多少無理してでも使うべき。
JUnitは工夫次第で,プログラムの構造検査や耐圧テストにも使える。さらに工夫すれば,目的別にJUnitのテストハーネス置き場を変えた方が良い(下記参照)。
src/ |- test/ ... 普通の単体テスト |- stress/ ... 耐圧テスト用 +- inspection/ ... 品質検査用
カバレッジは取れるんだったら取っておいた方が良い。レポートの見栄えの好みでCoberturaを愛用していたが,インスツルメンテーションが不要なEMMAのほうが良かったんじゃないかと最近では思っている。
理由は先の目的別JUnit。特に耐圧テストなどは,いちいちカバレッジ取ることないし,むしろカバレッジ取得にかかるオーバヘッドが邪魔でもある。そんな場合,Coberturaだとビルドし直し(もしくはクラスパス変更)せにゃならなくて面倒だった。
その他
IDEはもうすぐ6.0も出るし,こだわりがなければNetBeansでOK。使用するIDEが統一してあるんなら,プロジェクトのディレクトリ構成も,そのIDEが得意な構成にしちゃってもいいか?と言えば,CIで自動ビルドとか考えると,あんまりIDEに依存しないほうがイイに決まっている。
メタ情報をExcelで定義するのも構わないが,自動ビルドのさまたげになってはイケナイ(考え無しにVBA組むのもいい加減にしろと)。
- marsのメモ - ワーキングコピーと作業ディレクトリは分けるべき?
- marsのメモ - プロジェクトのディレクトリ構成
- marsのメモ - 実はIDEAのディレクトリ構成が一番おかしい(その1)
- marsのメモ - 実はIDEAのディレクトリ構成が一番おかしい(その2)
正直,みんながどのIDE使うかはどうでもいいのだ。あたしがIDEA使うのを邪魔しなければ,それこそ何してくれても構わない。:-P
#今や,プラグインを自作してでもIDEAを使い続ける所存であります。:-D
利用サイドと信頼関係ができてないと,モジュールをリリースしても難癖付けて適用してくんないことがある。あとで四の五の言わせないように,変更点や変更事由のとりまとめはしといたほうがいい。とりわけ,APIの差分は準備さえしておけば,手間いらずで作れるのでハッタリかますのに便利。
これは開発環境ではなく,実行環境ネタになるが,エラー画面はリッチなほうがいい。例えば,スタックトレースをログするタイミングを奪い取れるのであれば,そんときのシステムプロパティやら業務プロパティやらも一緒にダンプしたほうがいい。
この手の情報は邪魔になることはないぞ。
あと,余力があればアバウトページを作って自己診断情報をいつでも参照できるようにするのも良い...。イヤ,これは余力とは言わず,多少ムリしてでも用意した方がいいな。
開発環境,実行環境の両方に言えることだが,「EJBEARなんてうんこ」。WARのほうが取り回しが簡単なので,WARで済みそうならWARにとどめた方が全然良い。どうしてもEARじゃなきゃイケナイ場合もあろうが,そんなときは自分の身の上を呪うが良い。:-P
あ,そうそう。プロジェクトの運営スタイルはスクラムが望ましいってのは,今さらだから言わないよ(って言ってるじゃんか)。