Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à 継続的12章
Similaire à 継続的12章 (20)
継続的12章
- 2. 12.1 導入 • アプリケーションのデータは長く保持しなけ ればならない • システムの中で一番重要なのはデータだ • データは移行しなければならない • データの構造や内容を変更する仕組みが必要 • データベースの移行プロセスを自動化するこ と • 本番のダンプをテストデータとして用いるの は問題なので代替案をあとで提示する
- 3. 12.2 データベースのスクリプト処 理 • DB のあらゆる変更は自動化されなければ ならない • アプリケーションの特定のバージョンに 合わせたDBスキーマに設定できるよう管 理しなければならない • ユニットテストはDBなしでも動作しなけ ればならない • 受け入れテストの準備プロセスでDBス キーマとデータを設定できなければなら ない
- 4. 12.2.1 データベースを初期化す る • データベースをデプロイする最もシンプ ルな手順： 1. 以前にあったものを削除する 2. データベースの構造、インスタンス、ス キーマなどを作る 3. データを読み込む • ほとんどのプロジェクトでは、デプロイ メントプロセスで既存データの移行が必 要となる
- 5. 12.3 インクリメンタルな変更 • 変更を加えた後もアプリケーションが動 作し続けなければならない • 既存のデータを保持し続けなければなら ない • ロールバックの手段も用意しなければな らない
- 6. 12.3.1 データベースのバージョンを 管理する • テーブルにバージョン番号を含める • 変更を加えるたびに２つのスクリプトを 作る – ロールフォワード（バージョンを上げる） – ロールバック（バージョンを下げる） • アプリケーションに動作するDBのバー ジョン情報を与える • Ruby on Rails がこの方式 – Java, .Netの場合、DbDeploy, Tarantino, DbDiff, Dbmigrateがある
- 7. 12.3.1 続き • 構造を追加する変更は簡単 – ロールバックスクリプトは削除するだけ • 構造を変更する場合、データを削除する ことがある – ロールフォワードで一時テーブルを作り、削 除するデータをコピーして、ロールバックで きるようにする
- 8. 12.3.1 続き２ • データベーススキーマの変更は難しくな りがち – 追加は概ねうまくいく • 追加する制約に既存のデータが違反していたり、 デフォルト値なしで追加する場合は難しくなる – 削除する場合は難しい
- 9. 12.3.2 続き３ • DBの変更を管理するテクニックにより、 – アプリケーションのデプロイで、デプロイ先 の環境のDBの状態を心配する必要がなくなる – DB変更によるアプリケーションへの影響を吸 収する • アプリケーションが要求するDBのバージョンを更 新するまでDBの変更が適用されない
- 10. 12.3.2 オーケストレイトされた変更 を管理する • すべてのアプリケーションを一つのDBに統合 するのはおすすめしないが、しようがない場 合もある • DB変更のテストはDBを共有するアプリケー ションもそろえた環境で行うこと – この環境をシステムインテグレーション環境ある いはステージング環境と呼ぶことがある • 他のアプリケーションを保守するチームと話 し合って変更すること • アプリケーションを複数のバージョンで動く ようにすると良い
- 11. 12.4 データベースのロールバック と ゼロダウンタイムリリース • 本番環境へのデプロイ次の制約 – アップグレードの取り消し時にアップグレー ド後のトランザクションを失わないこと – アプリケーションを利用可能なままにしてお くこと • ホットデプロイ、あるいはゼロダウンタイムリ リース
- 12. 12.4.1 データを失わずに ロールバックする • 単にロールバックするわけには行かない 場合 – 一時テーブルからデータを書き戻す場合、 アップグレード以降に追加されたレコードが 一貫性制約に違反することがある – ロールバック時に新たなトランザクションか らのデータを削除するが、システム上はその データを失うことが許されない
- 13. 12.4.1 続き • 解決策 – アップグレード後のトランザクションを キャッシュする • しっかりした設計とテストが必要 – ブルーグリーンデプロイメント • 片方のDBにロールバック前のデータがあるのでそ れを元に復元 • 上記の方法では、データが大量にあると、 ダウンタイムを避けられないこともある
- 14. 12.4.2 アプリケーションのデプロイを データベースのマイグレーションから分離 する • DBのマイグレーションとアプリケーショ ンのデプロイを切り離す – ブルーグリーンデプロイメントやカナリアリ リースにも使える
- 15. 12.4.2 続き • 後方互換 – 新しいバージョンのアプリケーションを古い バージョンのDBでも動くようにする – 新しいアプリケーションを古いバージョンの DBで動かす – 様子を見てロールバックの必要がないと判断 したらDBのバージョンを上げる
- 16. 12.4.2 続き２ • 前方互換 – 古いバージョンのアプリケーションを新しい バージョンのDBでも動くようにする – 新しく追加されたフィールドは無視する – 万能ではないが通常の変更の場合には有用
- 17. 12.4.2 続き３ • 抽象化レイヤ – ストアドプロシージャやビュー – データベースオブジェクトを変更しても、ア プリケーション向けのインターフェースであ るビューなどはそのままに保てる
- 18. 12.5 テストデータを管理する • パフォーマンス – ユニットテスト • DBを使わない、あるいはインメモリのDB – その他のテスト • 一部の例外を除き本番DBのデータを使わない • テストの分離 – テストの実行に関するデータが永続的に保持 されうる
- 19. 12.5.1 仮のデータベースでの ユニットテスト • DBとやり取りするサービスの代わりにテスト ダブルを使う • DBにアクセスするコードをテストダブルで置 き換える – リポジトリパターン • DBアクセスの抽象化レイヤ – DBアクセス用コードがひとまとめになり保守しやすい • DBのフェイクを使う – インメモリDB • H2, SQLite, JavaDB
- 20. 12.5.2 テストとデータのつながりを 管理する • テストの状態を管理する方法 – テストの分離 • 各テスト用のデータはそのテストからしか見えない – 順応型テスト • 各テストがデータ環境を調べ、データに合わせて振る 舞いを変える – テストの順序付け • 実行順序を決め、各テストが一つ前のテストの出力を 使う • 通常はテストの分離を使うべき – 並列化も可能になる
- 21. 12.5.3 テストの分離 • 個々のテストがアトミック – 他のテストに影響を与えず、影響を受けない • 方法 – テスト終了時にDBをテスト実行前の状態に戻 す • トランザクションを利用してロールバックする – データの機能分割 • 受け入れテストでも有効 • 命名規則を定めてそれに従い、各テストがそのテ スト用のデータだけを見る
- 22. 12.5.4 準備と後始末 • 開始位置を確立し、テスト終了時に状態 を復元する • 順応型テストでは、準備段階で環境を評 価して、既知の開始位置を確立する
- 23. 12.5.5 一貫したテストシナリオ • 一貫したストーリーを作ってテストした くなることがある – データの準備と後始末が簡単になる – 個々のテストがシンプルになる – 実行速度が早くなる（データの生成と破棄が 減るため）
- 24. 12.5.5 続き • 個人的には良くないと考えている – 各テストが密結合する • テストの設計が難しくなる • １つのテストの失敗により、依存するテストすべ てが失敗する • 業務のシナリオや技術的実装の変化によりテスト スイート全体の見直しが発生する • 各ステップでのテストを網羅できない
- 25. 12.6 データの管理と デプロイメントパイプライン • 我々がテストしたかったのは一体何か？ – 我々が望む振る舞いと一致しているか • ユニットテスト – 不注意による破壊を防げる • 受け入れテスト – 価値をお届けできることを確かめる • キャパシティテスト – キャパシティ要件を満たすことを確かめる • インテグレーションテスト – 他のサービスと正しくやり取りすることを確かめる • これらのテストで必要になるテストデータは どのようなものか、どのように管理するべき か
- 26. 12.6.1 コミットステージでの テストにおけるデータ • 実行速度が最重要 • 実装の詳細とテストを密結合させない – リファクタリングの妨げとなる – 本来はリファクタリングを安全に行う助けと なるべき – 密結合はテストデータに凝り過ぎた結果であ ることが多い
- 27. 12.6.1 続き • よくできたコミットステージは、手の込 んだデータを用意せずに済む • 最小限のテストデータを使う – それほどデータ駆動ではない – テストヘルパーやフィクスチャを使う • データ構造の変化の影響を軽減できる
- 28. 12.6.2 受け入れテストにおけるデー タ • システムをテストする – テストデータは複雑となる • テストケースの作成を再利用できるよう にすること • 各テストのテストデータに対する依存を 減らす
- 29. 12.6.2 続き • データの区分を意識すると良い – テスト固有のデータ • テスト対象を動かす • テストするケースの詳細を表す – テストが参照するデータ • テストに関係する • テスト対象の振る舞いにはあまり影響しない – アプリケーションが参照するデータ • テスト対象に無関係 • アプリケーション立ち上げのために必要
- 30. 12.6.2 続き２ • テスト固有のデータ – 一意でなければならない – テスト分離のための手段 • テストが参照するデータ – 事前に用意した初期データで管理可能 – 再利用する • アプリケーションが参照するデータ – どんな値でも、 null でも良い – テストの結果に影響しなければ良い
- 31. 12.6.2 続き３ • アプリケーションが参照するデータ、う まくすればテストが参照するデータも、 データベースからのダンプの形式で保持 しておける – それをバージョン管理し、マイグレーション を組み込む – DBの自動マイグレーション自体のテストとし ても有効
- 32. 12.6.2 続き４ • アプリケーションの内部コードやDBダン プを使って初期状態に持っていくのはお すすめしない • アプリケーションのAPIを使うべき – 受け入れテストの間に矛盾した状態に陥らな い – DBやアプリケーションのリファクタリングが、 受け入れテストに影響しなくなる – 受け入れテストがアプリケーションのAPIテス トとしても機能する
- 33. テストデータの形式：その一例 • 金融取引：ユーザーのポジションが正しく更新された かのテスト • テスト固有のデータ – アカウント、ポジション • テストの準備としてアカウントの登録と資金を提供 • テストが参照するデータ – 金融商品 • 他のテストが再利用しても、「ポジションのテスト」には影響 しない • アプリケーションが参照するデータ – アカウント作成のオプション • ポジションの算出に無関係ならばテストに無関係 • 任意のデフォルト値を使う
- 34. 12.6.3 キャパシティテストにおける データ • 大量のデータの生成を自動化することを勧める • 入力データもマスタデータも、インタラクション テンプレートのような仕組みを使う(p.299) • 受け入れテストをシステムとのインタラクション を記録したものとして捉える – 記録した内容はそれ以降のステージでの開始地点と して利用 – 受け入れテストを選択して関連するデータをツール を用いて膨らませ、様々なインタラクションを行え るようにする？ – 受け入れテストとキャパシティテスト両方で使える でしょ？
- 35. 12.6.4 その他の テストステージにおけるデータ • 自動化した受け入れテストを以降のすべ てのテストの開始地点として使う • WEB アプリケーションでは互換性テスト も用意する – 受け入れテストを全ての主要ブラウザで行う
- 36. 12.6.4 続き • 手動テストでのデータの扱い – 最小限のデータで、空っぽの初期状態で開始 する – 大きめのデータ群を使い、実環境を想定した 操作シナリオを実行する – 本番データベースのダンプを使う • おすすめしない • 巨大で扱いにくい • 本番DBのマイグレーションのテストなどでは有効
- 37. 12.6.4 続き２ • これらのデータ群は開発者が開発環境で も使えなければならない • 開発者の開発環境では、本番データベー スのデータを使ってはならない
- 38. 12.7 まとめ • データ管理の基本原則 – 完全に自動化したプロセスでDB作成やマイグ レーションを行えるようにすること – なんどでも繰り返せて信頼できること – どんな場合も同じ手順に従うこと
- 39. 12.7 続き • 本番DBのダンプをなるべく使わない – テスト自身に状態を作らせる – 各テストが独立して実行できる – テスターは目的に合わせてデータを用意し管 理する
- 40. 12.7 続き２ • DBをバージョン管理し、ツールでマイグレーショ ンを自動化する • スキーマ変更の際に前方互換性と後方互換性を維 持し、データのデプロイメントとマイグレーショ ンの問題をアプリケーションのデプロイメントの 問題と分離する • テストデータの作成はテストの準備段階に含める • テストで共有するデータの準備処理に、アプリ ケーション立ち上げのための必要最小限のデータ を含め、それ以外に含めるのは一般的に使われる マスターデータだけにする
- 41. 12.7 続き３ • テストに必要な状態を準備するときは、 可能な限りアプリケーションの公開APIを 用いる • 例外を除いて本番データベースのダンプ をテスト用に使わない – 本番データから注意して取り出した小さめの データか、受け入れテストやキャパシティテ ストを実行した結果のデータを使う