• Like

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

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

  • 1,731 views
Uploaded on

2010年11月18日、DevLOVEで発表。 …

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,731
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
9
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 楽天株式会社 開発部 アーキテクト G よしおかひろたか | 2010 年 11 月 18 日 よしおかひろたか @DevLOVE
  • 2. 本日のメッセージ
    • 開発者の皆さん、 テストを書こう
    • テストを書く=テストコード+入力データ+期待する出力データ
    • Excel でテストケースを作ることではない。
    よしおか
  • 3. アジェンダ
    • 大規模ソフトウェア開発におけるディリービルド&リグレッションテスト - 事例
  • 4. 自己紹介
    • 楽天株式会社 DU 、 ACT 課アーキテクト G 、技術理事 よしおかひろたか
    • 2009 年 8 月入社
    • カーネル読書会の主宰者、 DEBUG HACKS 共著 ISBN978-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 から Solaris
    • 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.