1

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

よしおかひろたか@DevLOVE

2

よしおか 本日のメッセージ

開発者の皆さん、テストを書こう

テストを書く＝テストコード＋入力データ＋期待する出力データ

Excelでテストケースを作ることではない。

よしおか

3

よしおか アジェンダ

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

4

よしおか 自己紹介

• 楽天株式会社 DU 、 ACT 課アーキテクト G 、技術理事よしおかひろたか

• 2009 年 8 月入社• カーネル読書会の主宰者、 DEBUG HACKS 共著 IS

BN978-4-87311-404-0 • twitter @hyoshiok http://d.hatena.ne.jp/hyoshiok

5

よしおか わたしの経験から

• 大規模ソフトウェア開発の現場の経験をお話する。– ソフトウェア製品開発は受託開発とは相当異なる。

• 事例：– Oracle8の開発現場←今日はここ

6

よしおか Oracleの場合

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

7

よしおか Oracle 8の場合

• わたしが参加した時期、 1995 年～ 2000 年• Oracle8/8i あたりのころ• 開発環境： Sun Workstation 、 SunOS から Solari

s• Clearcase ベースの開発環境。

– ファイルの仮想化。一人で複数のブランチを同時に持てる。

• 例えば、 Oracle 7.3 用、 Oracle 8 用、 Oracle 8.1 用。バグ修正、機能ごと、ちょっとした確認用などなど

• check-out したものは check-in するまで他の人には見えない。

8

よしおか開発プロセス（ Oracleの場合）

• 要求仕様作り（開発者）– 外部API、UIなどを決定する。

• 例： SQLのシンタックス、セマンティックスを定義する。– リファレンスマニュアルのベースになる。

• 設計（開発者）– APIなどを決定したら、設計＆実装になる。

• 実装（開発者）– コードを書く、テストを書く、テストをする

• ディリービルド＆リグレッションテスト（自動）– チェックインされた最新のコードをスクラッチからビルドして、リグレッションテストを実行。

• チェックインしたコードの概要と、テスト結果の概要が日々担当者にメールで送られる

• 常に動くコードが毎日ある。• 安定化プロセス

– フィーチャーフリーズ（機能追加を凍結する）– コードフリーズ（重大なバグフィックス以外のチェックインを認めない）

9

よしおか ソフトウェア製品開発のプログラマ

• 設計者が実装者でテストも書く• 一つの機能については、すべて知っている。

• コーダーという人がいるわけではない。

10

よしおか プログラマの一日

• 朝会社に来る。• コーヒーでも飲みながら、メールをチェックする。

– 担当のテストを確認する。• 自分が昨日チェックインしたコードがリグレッションテストを壊していないか。

• 他の人のチェックインが、担当テストを壊していないか。• 壊れている場合は、調査する。あるいは調査を依頼する。

• 仕掛の作業を行う。– コードを書いたり、テストを流したり、あれやこれや。– 全テストを流すと時間がかかるので、サブセットを流す– コードが安定したら当該ブランチの最新版にマージする

• 自分の環境で動作確認ができたら、– 同僚にレビュー依頼をして、コメントをもらう。特に問題がなさそうの場合、リリースマネージャーにチェックインの許可をもらう。

• 許可が出たら、チェックインする。– 次の日はどきどきしながらリグレッションテストの結果を見る

• 休暇の前に確認しないでチェックインをするな、という不文律– http://d.hatena.ne.jp/hyoshiok/20040516#p1

11

よしおか リズム

• チェックアウトして• コードをいじって、テストを書いて、• テストを実行して、OKになるまで繰り返して、• 変更についてコメントを書いて、（変更の概要、バグ修正、機能追加、機能変更などなど）

• 同僚にレビューしてもらって、• リリースマネージャに許可をもらって、• チェックイン

12

よしおか チェックアウト、チェックイン

• 複数のブランチを同時にいじっている• バージョンがいくつか• それぞれについて、バグフィックス、機能変更、機能追加、機能ごとに別々のブランチを切っておく。

• 最新のバージョンでバグフィックスしたものを昔のバージョンに適用することもある。（バックポート）

13

よしおか ディリービルド

• 毎日大量のチェックインがある。数十～• 最新のソースからビルドする。

– コンパイルエラーが出るチェックインは無条件にロールバックされる。

– 複数のビルドマシンで分散ビルド• 安定性に差こそあれ常に動くものがある。

– Oracle8の最初のビルドは前バージョン(Oracle 7.3)と同一。ここから始まる。

14

よしおか リグレッションテスト

• ディリービルドされた最新の実行イメージでリグレッションテスト（数千）を実行する– 10数台（？）のサーバーマシンで何時間もかかる。– テストコード、入力データを与えて、期待する出力と実際の出力の差分を見る

– diff（差分）が出たらそれを目視確認する。期待する結果なのか、いなか。

– 新機能追加、バグフィックスの場合は対応するテストの追加、修正などを行う。

– リグレッションテストがあるので、既存の機能の予期しない影響がすぐにわかる。リグレッションの発見。

15

よしおか 安定化プロセス

• あるクライテリアで、安定化プロセスに入る。– 新機能の追加を凍結する（ feature freeze)期間に入る

– バグ修正だけを行う– リグレッションテストの diffの数を減少させる– テストの追加、実行だけをやって、製品の安定化を図る。

– あるクライテリアで、重大なバグ修正以外は一切変更を認めない (code freeze)期間に入る。

– バグ（不具合）はリリースノート等に記載し出荷する

16

よしおか 学んだこと

• ディリービルド＆リグレッションテストによって、常に動作が確認されているものがある。– どの機能が実装されていて、どの機能が実装されていないかが一目でわかる

– 実装すべき機能のプライオリティが変更になったとしても、すぐに対処可能

– スケジュールが遅延した場合、どの機能を落とすかの判断が容易に可能。（どれが動いているかいないかを把握できているので）

– マニュアルに記述していない機能は存在しないのと一緒。

17

よしおかデイリービルド＆リグレッションテ

スト

• 大規模ソフトウェア開発において俊敏性を高めるベストプラクティスで、ソフトウェア製品開発では広く利用されている。（例：マイクロソフトの OS開発など）

• 闘うプログラマー　ビル・ゲイツの野望を担った男達　http://books.rakuten.co.jp/rb/6130084/

18

よしおか

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

19

よしおか