デイリービルド

先週YLUGのカーネル読書会でコード管理システムの話が出たので、ちょっとその話の続きを考えてみる。

前の会社では数百人のエンジニアがデータベースのカーネルを開発していた。

サンフランシスコ空港からスタンフォード大学のあるパロアルトにいくハイウェイ101沿いに見えるガラス張りの円柱のビルの会社だ。あなたがシリコンバレーに言ったことがあるなら見たことがあるかもしれない。

開発は定常的に行われている。毎日毎日新機能が追加され、バグは修正される。

毎日毎日ある時刻になると自動的にコード管理システムはその時点で登録されているコードを一意に識別するラベルを付けビルドをはじめる。これをデイリービルドと呼ぶ。本日のビルドを例えばKERNEL20040412とかラベルをつける。

新機能を開発するというのは通常次のようなプロセスである。

開発環境にそのラベルで示されているソースコード一式を取り揃える(コマンド一発で行える)。必要なソースコードの修正をはじめる。新機能の開発には数日から数週間かかる。自分が加えた修正はコード管理システムに登録するまでは他の人には見えない。登録することをチェックインすると言う。

数日間コードと格闘して機能を開発した。テストも行った。幸いリグレッションは発生していない。同僚にコードのレビューもしてもらった。いよいよコードをチェックインする時だ。

コードは日々進化している。数日前のコード(スナップショット)と今日のコード(スナップショット)は当然違う。新機能の実装に数日かかったので最新のコードは機能の開発を開始したときのコードと微妙に変わっていたりする。そのために、チェックインする前に最新版のコードに自分が施した修正を当てる必要がある。そして、再度ビルドをし、リグレッションテストをかけ、問題がないことを確認しコードをチェックインしなければならない。

開発に数週間かかるような大きな機能の場合ベース（元となったコード)の変化が激しくて簡単に修正がマージできない可能性がある。そのためプログラマにもよるが通常は数日単位で適宜メインラインとマージすることが多い。

ここでマージと呼んでいる作業はメインにコードをチェックインする作業のことではなくて、自分のプライベートなイメージに対してメインの変化を適用することである。例えばカーネル2.6.1でパッチをシコシコ作っていたのだが、いつのまにかに、2.6.2とか2.6.3とか2.6.4とかが出てきて、ある日チェックインをしようとしたら最新版は2.6.5だった。そこで最初にやることは、2.6.5向けのパッチを作る事なんだけど自分のパッチに2.6.1と2.6.5の差分を適用するようなイメージなので、マージと言う言葉を使う。（説明がわかりにくくてごめんなさい)

プログラマは開発している機能毎にある種のスナップショットを持っていて、それぞれのビューは独立していて他からは見えないので、独立してテスト、レビューなどが行える。そしてそれぞれを独立してチェックインをする。

大規模ソフトウェアの場合毎日毎日何十何百の機能がチェックインされ、ビルドされリグレッションで機能の後退がないか確認をされる。それが日々延々と繰り返されるのである。

YLUGカーネル読書会の時誰かが質問をしていた。プライベートな変更をどう管理すべきかと。わたしの所属していた組織は上記のようなポリシーで運営していたのである。もちろん、それが唯一の方法とは言わないが、一つの典型的な(?)アプローチではある。