98/2/18 デイリービルド
シリコンバレー日記 98/2/18 デイリービルドより
http://web.archive.org/web/19991114161700/www.best.com/~yoshioka/d/98/i980218.html
”デイリービルドとは何か?なぜ重要なのか?そしてリグレッションテストとは何か?なぜ重要なのか?それを記しておこう.”と先に書いた.今日はそれについて記す.
データベース管理システムとか,オペレーティングシステムなどの商用ソフトの開発方式について簡単に記すと次のようになる.開発の渦中では,日々多数のプログラマが,システムの様々の部分のソースコードを変更している.ソースだけではなくて,テストプログラムとかデータとか各種マニュアルとか,内部的なドキュメント,例えば機能仕様書,設計仕様書などを更新する.
通常,多数で共有されるものは,ソースコード管理システムによって管理される.変更のプロセスは,個々のプログラマにとって見れば自分の変更を日々他のプログラマとは独立に行っている感じになる.変更は,新機能の実装,機能の変更・拡張,バグ(不具合)の修正などのために行われる.チェックアウトしてからの修正は,チェックインするまで他のプログラマには一切見えない.チェックインすることによって,初めて他のプログラマへ見えるようになる.
- ソースコードをソースコード管理システムより取り出す.これをチェックアウトと呼ぶ
- 変更を加える.
- テストをして変更が意図通りであることを確認する.問題があれば上記を繰り返す.
- リグレッションテストを行い意図をしない副作用がないかを確認する.問題があれば上記を繰り返す.
- ソースコードのレビューを同僚と行う.
- 問題がなければ,ソースコード管理システムへ登録する.これをチェックインという.
チェックインする以前の変更はその変更した個人にしか見えない.その段階である程度のテストを行う.意図どおりの変更であることを確認した後,チェックインするのだが,時として,他のプログラマの変更が自分の変更と干渉しあって不都合を生じさせることがある.それぞれ独立して作業をしているので,さけられない一面もある.
そのような不都合を発見するため,毎日,登録されているソースプログラムをもとに,はじめからコンパイル,リンクを行う.これをデイリービルドという.ビルドは夜間に行われる.その後,新しく作成されたソフトウェアを自動的にテストする.このテストはリグレッションテストと呼ばれている.前回までの実行結果と新しく作ったソフトウェアでの実行結果を比較してみて,結果が同じであれば良しだし,もし違っていたとしたら,その原因を探る必要がある.いずれにせよ,ビルドとリグレッションテストは一対の作業で毎日繰り返される.
仮に,今日のビルドで結果に差が出たとしよう.これをディフという.ディフがでるのは,実行環境が全く同じなら,昨日チェックインした変更が原因であるといえる.実際は,実行環境も日々微妙に変化していたりするので,それほど単純な話ではないが,おおざっぱに言って,ソースの変更が,結果の変化を生むという因果関係はあるので,どの部分がどの影響を与えたかを特定することはそれほど難しい作業ではない.
統合化した結果によってなんらかの影響がでたとしたら,それを即座に発見して対策をとる.そのプロセスがデイリービルドとリグレッションテストといえる.毎日毎日それを繰り返す.
ソフトウェアの機能は少しずつ雪ダルマ式に増えていく.テストも徐々に増えていく.日々,常に動作可能なソフトウェアがある.プロジェクトのどの時期をとっても,安定度に差はあるとしても,取り合えづ,動くものがある.マーケット環境が変化して,急に新しい機能が必要になったとしても,柔軟にその変化に対応できる.一つの作業行程は,通常,数日程度にする.そのため,スケジュールが遅れた場合,優先度の低いものから切っていくことが,柔軟に行える.
われわれはソフトウェアを新規にまるっきりスクラッチ(ゼロから)作ることはなくて前バージョンからの拡張という形で製品化する.そのため,開発0日目に,すでに動くものを持っている.この新製品の新機能は0ではあるけどともかく動く.それを毎日毎日機能を追加していくのである.そして毎日毎日リグレッションテストにかけられ機能の後退がないことを確認する.製品をいつ出荷するかというスケジュールとの絡みで,いつ新機能の追加をやめ,製品の安定化に注力するかというのを決定する.そして,ある時点で,機能の凍結を行い,これをコードフリーズといい,その後は重大なバグの修正だけを行う.
この開発方式では金太郎飴的に開発のどの時点をとってみてもある程度動くそこそこの機能の製品が常にあるというのが特徴である.これを従来のウォーターフォールモデルとして知られる方式と比較してみよう.従来の方式は,下記の工程が直列に行われる.
各工程では成果物を厳密に定義して,後戻りを発生しないようにする.というのは,後戻りのコストが非常に高いといわれているからである.例えば,単体テストで見つかった不具合はコーディング工程で修正できるかもしれないが,統合テストで見つかった不具合は,上流の工程まで後戻りしなければならないかもしれない.上流に戻れば戻るほど重複する無駄な作業が発生するのでコストが高くなる.そのため,開発が始まるかなり前に機能を凍結して,コーディング工程以降に影響が少なくなるようにする.その結果,開発期間が数年にもわたる大規模プロジェクトの場合,開発が終了した時点では,ユーザーニーズとかけ離れたものができがちである.
- 要求定義
- 概要設計
- 詳細設計
- コーディング
- 単体テスト
- 統合テスト
- 運用
この方式のもう一つの欠点は,統合テストが始まるまで実際に動くものがないので,どのようなものができあがるか実のところよく分からないのである.
結構いいかげんな作り方である.
一方毎日のビルド,テストのアプローチは常に仕様の変更,機能の変更があるという前提で行われている.そのため,マーケットの変更に強い.スピード重視である.そして製品は逐次的に改良,進化していく.
以上のような開発プロセスはシリコンバレーではごく当たり前に行われている.日本ではどうなのだろうか?
このプロセスを成功させるにはいくつかのポイントがある.テストの自動化,ビルドの自動化などがそれである.それについても,簡単に記そう.
はげましのお便りは
よしおかひろたか
までどーぞ.
というようなことを98年(6年前だよ)に書いた。ネットワークの時代はドッグイヤーだなんだと言われているが、ソフトウェア開発プロセスの現場はそれほど変化はないのではないだろうか?ソフトウェアは機械が作るわけではなく一人一人のプログラマが作るのだから急には変化はしないとしても。(というような事を書きつつもバザール方式のソフトウェア開発というのは驚異的な変化だなあとは思ったりもする)
デイリービルドの世界では開発0日目で既に動くものがある。今日からバージョンNを開発開始したとして、バージョンNー1は既にあるので、それに日々機能追加、機能修正をやっていく。テストも同時並行に開発し逐次開発環境に組み入れられていく。テストファーストあるいはテストドリブン的な色彩もある。
このスタイルはシリコンバレーの現場では常識だと思う。ソフトウェア開発プロセスの「定石」ないしは「デザインパターン」みたいなものであろう。
http://blog.japan.cnet.com/umeda/archives/001177.html で石黒さんは
レビュー、ソースコード管理、デイリービルドを毎日行なう早い開発サイクル
このスピード感はなかなかのものである。マイクロソフトやOracleのような大企業でも、従業員数十人のベンチャーでも同じようなスピード感をもっているというのも不思議な感じはする。