2010年11月18日、DevLOVEで発表。 大規模ソフトウェアにおけるディリービルド＆リグレッションテスト。Oracle8開発における事例。

1. 1
楽天株式会社 開発部 アーキテクト G よしおかひろたか ｜ 2010
年 11 月 18 日
よしおかひろたか
@DevLOVE

2. 2
よしおか 本日のメッセージ
開発者の皆さん、
テストを書こう
テストを書く＝テストコード＋入力データ＋期待する出力デー
タ
Excel でテストケースを作ることではない。
よしおか

3. 3
よしおか アジェンダ
•大規模ソフトウェア
開発におけるディリ
ービルド＆リグレッ
ションテスト - 事例

4. 4
よしおか 自己紹介
• 楽天株式会社 DU 、 ACT 課アーキテクト G 、技術
理事
よしおかひろたか
• 2009 年 8 月入社
• カーネル読書会の主宰者、 DEBUG HACKS 共著
ISBN978-4-87311-404-0
• twitter @hyoshiok http://d.hatena.ne.jp/hyoshiok

5. 5
よしおか わたしの経験から
• 大規模ソフトウェア開発の現場の経験
をお話する。
– ソフトウェア製品開発は受託開発とは相
当異なる。
• 事例：
– Oracle8 の開発現場←今日はここ

6. 6
よしおか Oracle の場合
• 開発環境
• 開発プロセス
• プログラマの日常
• リズム
• チェックアウト、チェックイン
• ディリービルド
• リグレッションテスト
• 学んだこと

7. 7
よしおか Oracle 8 の場合
• わたしが参加した時期、 1995 年～ 2000 年
• Oracle8/8i あたりのころ
• 開発環境： Sun Workstation 、 SunOS から
Solaris
• Clearcase ベースの開発環境。
– ファイルの仮想化。一人で複数のブランチを同
時に持てる。
• 例えば、 Oracle 7.3 用、 Oracle 8 用、 Oracle 8.1 用。バ
グ修正、機能ごと、ちょっとした確認用などなど
• check-out したものは check-in するまで他の人には見え
ない。

8. 8
よしおか開発プロセス（ Oracle の場合）
• 要求仕様作り（開発者）
– 外部 API 、 UI などを決定する。
• 例： SQL のシンタックス、セマンティックスを定義する。
– リファレンスマニュアルのベースになる。
• 設計（開発者）
– API などを決定したら、設計＆実装になる。
• 実装（開発者）
– コードを書く、テストを書く、テストをする
• ディリービルド＆リグレッションテスト（自動）
– チェックインされた最新のコードをスクラッチからビルドして、
リグレッションテストを実行。
• チェックインしたコードの概要と、テスト結果の概要が日々
担当者にメールで送られる
• 常に動くコードが毎日ある。
• 安定化プロセス
– フィーチャーフリーズ（機能追加を凍結する）
– コードフリーズ（重大なバグフィックス以外のチェックインを認
めない）

9. 9
よしおか
ソフトウェア製品開発のプログ
ラマ
• 設計者が実装者でテストも書く
• 一つの機能については、すべて知って
いる。
• コーダーという人がいるわけではない
。

10. 10
よしおか プログラマの一日
• 朝会社に来る。
• コーヒーでも飲みながら、メールをチェックする。
– 担当のテストを確認する。
• 自分が昨日チェックインしたコードがリグレッションテスト
を壊していないか。
• 他の人のチェックインが、担当テストを壊していないか。
• 壊れている場合は、調査する。あるいは調査を依頼する。
• 仕掛の作業を行う。
– コードを書いたり、テストを流したり、あれやこれや。
– 全テストを流すと時間がかかるので、サブセットを流す
– コードが安定したら当該ブランチの最新版にマージする
• 自分の環境で動作確認ができたら、
– 同僚にレビュー依頼をして、コメントをもらう。特に問題がなさ
そうの場合、リリースマネージャーにチェックインの許可をもら
う。
• 許可が出たら、チェックインする。
– 次の日はどきどきしながらリグレッションテストの結果を見る
• 休暇の前に確認しないでチェックインをするな、という不文律
– http://d.hatena.ne.jp/hyoshiok/20040516#p1

11. 11
よしおか リズム
• チェックアウトして
• コードをいじって、テストを書いて、
• テストを実行して、 OK になるまで繰り返
して、
• 変更についてコメントを書いて、（変更の
概要、バグ修正、機能追加、機能変更など
など）
• 同僚にレビューしてもらって、
• リリースマネージャに許可をもらって、
• チェックイン

12. 12
よしおかチェックアウト、チェックイン
• 複数のブランチを同時にいじっている
• バージョンがいくつか
• それぞれについて、バグフィックス、
機能変更、機能追加、機能ごとに別々
のブランチを切っておく。
• 最新のバージョンでバグフィックスし
たものを昔のバージョンに適用するこ
ともある。（バックポート）

13. 13
よしおか ディリービルド
• 毎日大量のチェックインがある。数
十～
• 最新のソースからビルドする。
– コンパイルエラーが出るチェックインは
無条件にロールバックされる。
– 複数のビルドマシンで分散ビルド
• 安定性に差こそあれ常に動くものがあ
る。
– Oracle8 の最初のビルドは前バージョン
(Oracle 7.3) と同一。ここから始まる。

14. 14
よしおか リグレッションテスト
• ディリービルドされた最新の実行イメージ
でリグレッションテスト（数千）を実行す
る
– 10 数台（？）のサーバーマシンで何時間もかか
る。
– テストコード、入力データを与えて、期待する
出力と実際の出力の差分を見る
– diff （差分）が出たらそれを目視確認する。期待
する結果なのか、いなか。
– 新機能追加、バグフィックスの場合は対応する
テストの追加、修正などを行う。
– リグレッションテストがあるので、既存の機能
の予期しない影響がすぐにわかる。リグレッシ
ョンの発見。

15. 15
よしおか 安定化プロセス
• あるクライテリアで、安定化プロセスに入
る。
– 新機能の追加を凍結する（ feature freeze) 期間に
入る
– バグ修正だけを行う
– リグレッションテストの diff の数を減少させる
– テストの追加、実行だけをやって、製品の安定
化を図る。
– あるクライテリアで、重大なバグ修正以外は一
切変更を認めない (code freeze) 期間に入る。
– バグ（不具合）はリリースノート等に記載し出
荷する

16. 16
よしおか 学んだこと
• ディリービルド＆リグレッションテストに
よって、常に動作が確認されているものが
ある。
– どの機能が実装されていて、どの機能が実装さ
れていないかが一目でわかる
– 実装すべき機能のプライオリティが変更になっ
たとしても、すぐに対処可能
– スケジュールが遅延した場合、どの機能を落と
すかの判断が容易に可能。（どれが動いている
かいないかを把握できているので）
– マニュアルに記述していない機能は存在しない
のと一緒。

17. 17
よしおか
デイリービルド＆リグレッショ
ンテスト
• 大規模ソフトウェア開発において俊敏
性を高めるベストプラクティスで、ソ
フトウェア製品開発では広く利用され
ている。（例：マイクロソフトの OS
開発など）
• 闘うプログラマー ビル・ゲイツの
野望を担った男達
http://books.rakuten.co.jp/rb/6130084/

18. 18
よしおか
開発者の皆さん、
テストを書こう
テストを書いてプロフェッショナルにな
ろう
世界へ

19. 19
よしおか