僕はこんな開発インフラを使ってきた

僕は2002年に新卒で入社して今年８年目になる。
2002年といえばITバブルは弾けていたが同期は多かった。今の新人の倍はいた。ある意味バブル入社組。

ちなみに入社するまではプログラミングはほとんどやったことなかった。で、入社してから今まで開発のメイン言語はJavaだ。小規模しか経験してない。
最初に使ったIDEはJBuilderだった。まだEclilpseが出回る前だったしね。Java以外でいうと.NETが出始めたぐらいで、VC++6.0がWindows開発ではメインのIDEだったね。

2004年に初めて業務でCVSを使った。バグ管理はExcel。つってもバグを見つけたらちょろっと書いてただけで管理していたとはいえない。まだ構成管理のことはよくわからなかった。トランクとタグはわかってもブランチがよくわからなかった。
IDEはEclipse使ってた（2系を使ってた気がする）。フレームワークはStrutsが全盛だったように思う。内製フレームワークが出てきたのもこの頃だと思う。

AJAXやDIコンテナのことを聞くようになってきたのは2005年頃かな。

2006年から自社製品の開発に関わるようになる。そこではCVSを使っていて内製のバグ管理ソフトを使ってた。このソフトはWebアプリじゃなくてクライアントアプリでデータはファイルサーバにおいとくというしろもの。
そこではコミットコメントとソースコメントにバグIDを入れる運用をしていた。ブランチの意味を肌で理解したのはこの頃。パッケージやってるとブランチの意味がよくわかるんだよね。古いバージョンのバグ修正とかもあったから。

その後別仕事でTracを使うようになる。正直最初はチケットの意味がわからなった。
でもCVSよりSubversionのほうがいいのは感覚的にわかった（アトミックなコミット、TortoiseSVN、HTTPとの親和性などが理由）。
それにWikiもあるしdiffのビューアもよかったのでこの仕事の後にパッケージ開発のほうもTracに乗り換えた。チケット駆動開発もどきを始めたのもこの頃。

2007年頃にpost-commitのことを知り、もうバグ管理でExcelを使う時代は終わったなと思った。同時にBTSはソース管理とひも付かないと使えないと思うようになった。
今にして思うとTracのチケットは革命的だと思う。
Tracの弱点と言われるマルチプロジェクト非対応、ワークフローとWikiの貧弱さなどは気にならなかった。まあ小規模開発だったせいかも。
CruiseControlを試していたのは2008年頃。結構良かったんだけど後で知るHusonに比べるとconfig.xmlにいろいろ手動で書かないといけないのは面倒。

最近だと業務で使ってないけど試してみたのもいくつかある。

まずRedmineはすげーって思った。これはかなり高機能。ガントチャートとかすごいね。Tracでもプラグインを使えば同等のことはできると思うが標準でついてたほうが楽だろうと思う。
またTracはプロジェクトの作成などどうしてもコマンドからの作業が多くなってしまうしね。

もっともTracLightningのおかげでこの辺の壁はなくなりつつある。

ソース管理もSubversionで決まりだろって思ってたらGitやMercurialなどの分散バージョン管理システムが出てきた。
これはちょっと難しいがオープンソース開発の世界では有用だろう。
業務ではまだ個人で使うレベルかな。
こういうのを見るといまだにCVSや（Java開発なのに）VSS使ってるってどうなんだろって思っちゃう。ま、余計なお世話か。

CIではHudsonがいいと思っているが、TeamCityも面白い気がしてきた。IntelliJのプロジェクトファイル読み込めるってなんかすごい気がする。
なんでかっていうとビルドをAnt等で自動化しているところって意外に少ない気がするから。社内を見るとそう思っちゃう。気のせいかもしれないけど。
文字コードの問題でEclipseでしかビルドできない状況になっているプロジェクトも見たことあるし。

テスト管理はTestLinkは面白そうだが、画面操作に癖があるし運用はまだ難しいかもって思ってる。

こうしてみるとこの分野の進歩はすごい。ただ人間がそれに追いついてないのが現状。
ツールが開発プロセスを進化させているので、まずは自分のなかにうまく取り込んでいきたい。