大規模ソフトウェアにおけるディリービルド&リグレッションテスト@Dev Love

2,163 views

Published on

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

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,163
On SlideShare
0
From Embeds
0
Number of Embeds
24
Actions
Shares
0
Downloads
11
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

大規模ソフトウェアにおけるディリービルド&リグレッションテスト@Dev Love

  1. 1. 1 楽天株式会社 開発部 アーキテクト G よしおかひろたか | 2010 年 11 月 18 日 よしおかひろたか @DevLOVE
  2. 2. 2 よしおか 本日のメッセージ 開発者の皆さん、 テストを書こう テストを書く=テストコード+入力データ+期待する出力デー タ Excel でテストケースを作ることではない。 よしおか
  3. 3. 3 よしおか アジェンダ •大規模ソフトウェア 開発におけるディリ ービルド&リグレッ ションテスト - 事例
  4. 4. 4 よしおか 自己紹介 • 楽天株式会社 DU 、 ACT 課アーキテクト G 、技術 理事 よしおかひろたか • 2009 年 8 月入社 • カーネル読書会の主宰者、 DEBUG HACKS 共著 ISBN978-4-87311-404-0 • twitter @hyoshiok http://d.hatena.ne.jp/hyoshiok
  5. 5. 5 よしおか わたしの経験から • 大規模ソフトウェア開発の現場の経験 をお話する。 – ソフトウェア製品開発は受託開発とは相 当異なる。 • 事例: – Oracle8 の開発現場←今日はここ
  6. 6. 6 よしおか Oracle の場合 • 開発環境 • 開発プロセス • プログラマの日常 • リズム • チェックアウト、チェックイン • ディリービルド • リグレッションテスト • 学んだこと
  7. 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. 8 よしおか開発プロセス( Oracle の場合) • 要求仕様作り(開発者) – 外部 API 、 UI などを決定する。 • 例: SQL のシンタックス、セマンティックスを定義する。 – リファレンスマニュアルのベースになる。 • 設計(開発者) – API などを決定したら、設計&実装になる。 • 実装(開発者) – コードを書く、テストを書く、テストをする • ディリービルド&リグレッションテスト(自動) – チェックインされた最新のコードをスクラッチからビルドして、 リグレッションテストを実行。 • チェックインしたコードの概要と、テスト結果の概要が日々 担当者にメールで送られる • 常に動くコードが毎日ある。 • 安定化プロセス – フィーチャーフリーズ(機能追加を凍結する) – コードフリーズ(重大なバグフィックス以外のチェックインを認 めない)
  9. 9. 9 よしおか ソフトウェア製品開発のプログ ラマ • 設計者が実装者でテストも書く • 一つの機能については、すべて知って いる。 • コーダーという人がいるわけではない 。
  10. 10. 10 よしおか プログラマの一日 • 朝会社に来る。 • コーヒーでも飲みながら、メールをチェックする。 – 担当のテストを確認する。 • 自分が昨日チェックインしたコードがリグレッションテスト を壊していないか。 • 他の人のチェックインが、担当テストを壊していないか。 • 壊れている場合は、調査する。あるいは調査を依頼する。 • 仕掛の作業を行う。 – コードを書いたり、テストを流したり、あれやこれや。 – 全テストを流すと時間がかかるので、サブセットを流す – コードが安定したら当該ブランチの最新版にマージする • 自分の環境で動作確認ができたら、 – 同僚にレビュー依頼をして、コメントをもらう。特に問題がなさ そうの場合、リリースマネージャーにチェックインの許可をもら う。 • 許可が出たら、チェックインする。 – 次の日はどきどきしながらリグレッションテストの結果を見る • 休暇の前に確認しないでチェックインをするな、という不文律 – http://d.hatena.ne.jp/hyoshiok/20040516#p1
  11. 11. 11 よしおか リズム • チェックアウトして • コードをいじって、テストを書いて、 • テストを実行して、 OK になるまで繰り返 して、 • 変更についてコメントを書いて、(変更の 概要、バグ修正、機能追加、機能変更など など) • 同僚にレビューしてもらって、 • リリースマネージャに許可をもらって、 • チェックイン
  12. 12. 12 よしおかチェックアウト、チェックイン • 複数のブランチを同時にいじっている • バージョンがいくつか • それぞれについて、バグフィックス、 機能変更、機能追加、機能ごとに別々 のブランチを切っておく。 • 最新のバージョンでバグフィックスし たものを昔のバージョンに適用するこ ともある。(バックポート)
  13. 13. 13 よしおか ディリービルド • 毎日大量のチェックインがある。数 十~ • 最新のソースからビルドする。 – コンパイルエラーが出るチェックインは 無条件にロールバックされる。 – 複数のビルドマシンで分散ビルド • 安定性に差こそあれ常に動くものがあ る。 – Oracle8 の最初のビルドは前バージョン (Oracle 7.3) と同一。ここから始まる。
  14. 14. 14 よしおか リグレッションテスト • ディリービルドされた最新の実行イメージ でリグレッションテスト(数千)を実行す る – 10 数台(?)のサーバーマシンで何時間もかか る。 – テストコード、入力データを与えて、期待する 出力と実際の出力の差分を見る – diff (差分)が出たらそれを目視確認する。期待 する結果なのか、いなか。 – 新機能追加、バグフィックスの場合は対応する テストの追加、修正などを行う。 – リグレッションテストがあるので、既存の機能 の予期しない影響がすぐにわかる。リグレッシ ョンの発見。
  15. 15. 15 よしおか 安定化プロセス • あるクライテリアで、安定化プロセスに入 る。 – 新機能の追加を凍結する( feature freeze) 期間に 入る – バグ修正だけを行う – リグレッションテストの diff の数を減少させる – テストの追加、実行だけをやって、製品の安定 化を図る。 – あるクライテリアで、重大なバグ修正以外は一 切変更を認めない (code freeze) 期間に入る。 – バグ(不具合)はリリースノート等に記載し出 荷する
  16. 16. 16 よしおか 学んだこと • ディリービルド&リグレッションテストに よって、常に動作が確認されているものが ある。 – どの機能が実装されていて、どの機能が実装さ れていないかが一目でわかる – 実装すべき機能のプライオリティが変更になっ たとしても、すぐに対処可能 – スケジュールが遅延した場合、どの機能を落と すかの判断が容易に可能。(どれが動いている かいないかを把握できているので) – マニュアルに記述していない機能は存在しない のと一緒。
  17. 17. 17 よしおか デイリービルド&リグレッショ ンテスト • 大規模ソフトウェア開発において俊敏 性を高めるベストプラクティスで、ソ フトウェア製品開発では広く利用され ている。(例:マイクロソフトの OS 開発など) • 闘うプログラマー ビル・ゲイツの 野望を担った男達  http://books.rakuten.co.jp/rb/6130084/
  18. 18. 18 よしおか 開発者の皆さん、 テストを書こう テストを書いてプロフェッショナルにな ろう 世界へ
  19. 19. 19 よしおか

×