停電がきっかけで、個人で仕事していた頃のやり方を思い出したので、書いておきます。
一人で仕事をしていたときは複数のシステムの開発を一人で手掛けていました。そのため案件ごとにHD単位で分けて環境を作り、リムーバブルケースでディスクを物理的に入れ替えて作業していました。1案件1HD(バックアップ除く)という塩梅でした。そのときにやっていたことは、
- 作業ディレクトリのレイアウトを可能な限り合わせる
- 使用するOSSは全てソースをダウンロードしておいて、手元でビルド可能にしておく
- 上記OSSのビルド方法を手順化し、メモに残す。可能ならば全自動化する
- プロダクトコードのビルドももちろん自動化する(make、もしくはant)
- バックアップはディスク丸ごと行う
- 案件毎に壁紙を変える(地味だが、結構重要)
というようなことでした。いまではもう古臭いやり方かもしれませんね。かなりディフェンシブに見えます。バグ修正や機能追加案件が入ったときにすぐにそのときの作業状態に戻れるように意識していました。
現在の開発現場では、ビルドはmaven(maven2)にお任せで、自動化率はさらに上がっています。makeやantでやっていた頃に戻ろうとはなかなか思いません。そのかわりバイナリ(jar)に依存していて、ソースが手元に無いということが増えています。5年後、10年後、20年後でもそのときのOSSのソースコードにアクセス可能であるか、そしていざという時にビルド可能であるか。そもそもibiblio.orgは20年後も存在するのか。mavenによって自動化率が上がり、さらに先を目指すことが出来るようになっても、いざという時にオフラインでビルド完結できるようにはしておいた方が良さそうですね。依存ライブラリがどんどん増える昨今、どこまで出来るかは分かりませんが。
自動化対象として、もしくは規律として、ベンダブランチに定期的にimportするということが考えられるでしょう。いま手掛けている案件でも、主要なOSSプロダクトに関してはベンダブランチに随時importしています。例えばSeasarのプロダクト群は手元のベンダブランチにimportしています。今のところはそれで問題無いとは感じています。ただ、Seasarが依存しているOSSの全てのコードが手元にあるわけではありません。
OSSのソースコードの扱いは、結局リスク管理としてどこまでコストを掛けるかという問題なのかもしれません。他のプロジェクトではOSSのソースコードの扱いをどうしているかを聞いてみたいです。
