大規模ソフトウェアにおけるディリービルド＆リグレッションテスト@Dev Love
Download as PPT, PDF4 likes1,537 views
大規模ソフトウェアにおけるディリービルド＆リグレッションテスト@Dev Love
- 1. 1 楽天株式会社 開発部 アーキテクト G よしおかひろたか ｜ 2010 年 11 月 18 日 よしおかひろたか @DevLOVE
- 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/
- 19. 19 よしおか