一刻も早いリリースのために：アプリケーションの自動プロモーション

Paul Nixon著
2007年5月3日（翻訳記事2007年12月20日）

BEA WebLogic Platformアプリケーションは通常、複雑な実運用システムの一部としてデプロイされます。WebLogic Platformにホストされたアプリケーションを配布するとき、正式なアプリケーションテストを行うにはテスト条件が適正に制御されていることが必須で すが、そうした条件を整えること自体が複雑な作業です。環境を正しく整備し、アプリケーションを適切にデプロイしなければ、正式なテストを実施できず、配 布スケジュールにほとんど余裕がないような場合、プロジェクトに遅れが発生してしまいます。

テスト環境の構築プロセスを自動化することで、このような遅延の発生を防止することができます。この記事では、ある特定のテスト環境へのデプロイ作業を自動化し、その取り組みを他のテスト環境で再利用する方法について説明します。

Please Release Me（僕をリリースして）

「Please release me, let me go（僕をリリースして、公開してくれ）
My bugs aren't major anymore....（もう大したバグなんてないんだよ....）」

この替え歌は私の作ではありませんが、この記事のテーマにぴったりです。この替え歌の全文に興味がある方は こちらをご覧ください。 このWebサイトには、これ以外にもさまざまな替え歌が紹介されています。

さて、開発チームはアプリケーションスイートを構築し、WebLogicドメインに適切にデプロイして、自動テストスクリプトによる完全なアプリケーションテストを実施しました。おそらく開発者チームは、Michael Meinerの記事『Developing Web Applications in a Clustered Environment Using WLST and BEA Workshop』 （2006年のDev2Devにて公開）を読んでその推奨事項を実行に移したのでしょうが、Webサーバをフロントエンドとして使用するクラスタ環境でス イートのテストを行いました。そのスイートがクラスタで動作することも、フェイルオーバーが機能していることを開発者チームが実証できることも確認済みで す。

リリースノートが作成され、すべてのアーカイブファイルも用意できました。ユーザ側の受け入れテストの準備もすべて整い、あとはユーザがこれを気に入ってくれて納入を完了し、プロジェクトの成功を祝えることを祈るばかり・・・

・・・だったらどんなにいいでしょうか。現実には、スイートは実運用環境で機能するには程遠い状態です。そこに行き着くまでには数多くのハードルが あり、次の納期までに間に合いそうもありません。テスト担当者またはテストツールによってスイートとマシンの両方に対するテストが実施されますが、開発 チームはそのマシンにアクセスできません。テストではいくつかバグが発見され、少なくともその一部は修正する必要があります。そして、こうしたことがまた 何度も繰り返されます。

プロモーションの実施

テストは通常、明確に指定された一連の環境で実施されます。ここでは、そのような制御された環境とはどのようなものであるかを検討し、アプリケーションを特定のテスト環境から次のテスト環境にプロモートするための条件を考えてみます。

制御された環境

ここでは、「制御された環境」とは何らかのポリシーに従ってアクセスが制限されている環境を意味します。実運用環境は制御された環境であり、準備環 境も制御された環境にあたります。この2つの環境のアクセス制御ポリシーは似ていますが、準備環境のアクセスポリシーは実運用環境ほど制約的ではないと考 えられます。「制御されたテスト環境」とは単に、アプリケーション（スイート）のテストに使用するための制御された環境のことです。つまり、この環境では ポリシーによってアクセスが制限されています。

制御された環境でテストを行う目的は、再現可能なテスト結果を得ることにあります。同じテストを同じソフトウェアに対して同じ条件で実施すれば、同 じ結果が得られるはずです。「同じ条件」を用意するためには、テスト環境の準備が一貫していると同時に、再現可能である必要があります。環境の構築を自動 化するためには、環境がまず再現可能である必要がありますが、それ以上にテストが再現可能な条件の下で行われる必要があります。構築された環境を変更でき るユーザーおよび可能な変更範囲を制限するために、アクセス制御を実装します。テストの実施前に実行時の変更内容を適用する場合、そのような変更が何らか のテストログに記録されるようにし、実行時の変更を再適用して繰り返し環境を構築することによって正確なテスト条件を再現できるようにすることが重要で す。

アクセス制御の適用は、公式的に行うことも非公式に行うこともでき、その両方を併用することもできます。プロジェクトで公式的なアクセス制御を使用 する場合、通常はポリシールールの違反を防止するソフトウェアまたはハードウェアデバイスによって実装します。プロジェクトがそれほど公式的な進め方をし ていない場合は、アクセス制御の一部または全部を非公式に、つまり許容された手順に同意するか従うことによって適用します。非公式の制御の場合、意図的で ない違反も含めて違反が起こりやすいことは明らかなので、そうした環境では監査ソフトウェアをインストールして、環境コンフィグレーションを決められた設 定と比較確認し、許容できないほどの差異が存在する場合にはアラートを生成させることができます。

パフォーマンステスト、負荷テスト、ユーザ受け入れテストなどはすべて、制御されたテスト環境の例です。開発者は通常、制御されたテスト環境でテス ト結果を確認し、問題点やエラーを調査することは許可されていますが、環境コンフィグレーションの管理や変更、またはテストの実行に関与することは許可さ れていません。

制御された環境に関係するものはハードウェアだけではなく、適切なハードウェア、インフラストラクチャ、ソフトウェアが組み合わせられます。例え ば、同じハードウェアをパフォーマンステスト環境と負荷テスト環境の両方に使用できるとしても、ソフトウェアコンフィグレーションは異なるといった場合が 考えられます。他にも例えば、パフォーマンステスト環境ではパフォーマンスのボトルネックの発生箇所を解析するために計測機能付きJVMを使用して診断 ツールを有効にする場合がありますが、負荷テストではそのような要件は必要ありません。

プロモーションの仕組み

適切に管理されたプロジェクトでは、複数の制御されたテスト環境にわたってアプリケーションスイートを移行させ、そのアプリケーションに対してそれぞれのテストを実施します。図1に、その一例を示します。

図1：複数の制御されたテスト環境間でのアプリケーションの移行

プロジェクトのテスト計画では、多様なテスト環境を特定してその使用方法を計画する必要があります。多様なテスト環境の間でスイートを移行させ、最終的に実運用環境でライブにするプロセスは、 アプリケーションのプロモーションと呼ばれています。

プロジェクトでは、プロジェクト計画の一部として、特定の環境から別の環境へとアプリケーションスイートのプロモーションを行うために達成すべきエ ントリ基準が定義されていることがあります。また後で説明しますが、制御された環境にデプロイしてテストを実施する場合、多大なコストがかかる可能性があ り、エントリ基準を適用すれば、アプリケーションの品質が不十分なためテストを実施しても意味がないような場合に、そのようなコストの発生を回避できま す。

反復的または俊敏な開発手法を使用しているプロジェクトでは、複数のバージョンのアプリケーションスイートを1つ以上の制御された環境でテストする ことがあります。普通、テストの合格基準はテスト対象のバージョンが進むにつれ、次第に厳しくなるか範囲が広くなります。適切な手段を講じなければ、テス ト環境を準備してスイートをデプロイするコストが数倍に跳ね上がりかねません。場合によっては、開発手法の価値が疑問視されるほどコスト高になる可能性も あります。幸いなことに、信頼性の高い効率的なプロモーションを行うためのツールやテクニックがいろいろと存在します。この記事では、その一部を紹介しま す。

再デプロイとテストの繰り返し

デプロイに関連するプロモーションタスクは、次の2つの段階に分割できます。

• 環境のプロビジョニング
• アプリケーションスイートのデプロイ

プロビジョニングという用語は、広義には「アプリケーションが仕様どおりに動作するために必要とされるリソース を提供すること」と定WebLogic Platformアプリケーションプロビジョニングの自動化：ケーススタディ義できます。ここでリソースとは、BEA WebLogic Serverコンテナ自体から、データベース接続、Webサービスやバックエンドシステムへの接続性まで、あらゆるものを指します。プロビジョニングの問 題点については、Andy Linの自動化に関する優れた記事『』（Dev2Dev、2005年）で詳しく紹介されています。

アプリケーションを徹底的にテストするには、各テスト環境にそれぞれアプリケーションを何回もデプロイしてテストする必要があります。その際には、次の2つの広範なアプローチからいずれかを選択できます。

• テストごとに、環境のプロビジョニングとアプリケーションのデプロイを行う
• 環境を一度にプロビジョニングし、それ以降はテストごとに、アプリケーションのデプロイ、テスト、再デプロイを繰り返す

前者のアプローチ（テストごとに毎回環境を再構築する）を採用する場合、大きなコストがかかりますが、プロビジョニングとデプロイの2つ1組のタス クとなるため、それぞれに別のスクリプトを用意する必要がなくなるというメリットがあります。他方、テスト計画で多数のサーバやドメインが関わる複雑なテ スト環境が必要な場合は、プロビジョニングにかかるコストが非常に大きくなり、テストのたびにプロビジョニングするわけにはいかなくなるため、後者のアプ ローチを採用することをお勧めします。

プロモーションテストに失敗しないためには

アプリケーションスイートのプロモーションは、単に既存の環境のさらに大きなバージョンを構築して、スイートをそこにデプロイするだけのものではあ りません。さまざまな制御されたテスト環境があり、それぞれに特定のテスト目的があります。その目的の相違はプロビジョニング要件の相違として現れます。

下記の表1は、この点を示すために用意した、完全に架空のものですが非現実的ではないアプリケーションスイートテスト用の テスト環境仕様の概略です。環境に次第に追加されていく要素が、ごく一部ですが示されています。

機能テスト	ライブラリとドライバは「デバッグ」バージョンを使用 診断コンポーネント（例えば、ユニット テスト フレームワーク［Cactus］）をインストール データベースは低スペック（RACなしのOracleなど）、スキーマはDBMSに最適化されていなくてもかまわない プラットフォームとアプリケーションは、データベースのテーブルスペースを共有し、「汎用」スキーマを使用 クラスタ内には最小限のサーバだけを用意 多くのバックエンドサービスはダミー化されている
システムテスト	ドライバとライブラリは実運用バージョンを使用 データベースはフルスペックのエンタープライズ（RAC付きのOracleなど）、スキーマはDBMSに完全に最適化されていなくてもかまわない WebLogic Platformテーブルとアプリケーションテーブルのそれぞれに、別のテーブルスペースを用意 小数のサーバをインストール バックエンドサービスはテスト実装でもかまわない
パフォーマンス	ドライバとライブラリは実運用バージョンを使用 JVMは計測機能を搭載 JVMのパラメータ値セット、および接続プールサイズやカスタム実行キューなどの他のコンフィグレーション項目は調整済み パフォーマンスデータ収集エージェントをインストール データベースはフルスペックのエンタープライズ（RAC付きのOracleなど） Platformテーブルとアプリケーションテーブルのそれぞれに、別のテーブルスペースを用意、スキーマはDBMSに最適化 指定された最大負荷に十分対応できるよう、多数のサーバを使用 負荷生成用サーバを構成 バックエンドサービスはテスト実装でもかまわない
ユーザ受け入れテスト	ドライバとライブラリは実運用バージョンを使用 データベースはエンタープライズ、ただしフルスペックである必要はない（RACなしのOracleなど） Platformテーブルとアプリケーションテーブルのそれぞれに、別のテーブルスペースを用意 最小限のサーバをインストール バックエンドサービスを完全に構成

表1：テスト環境仕様の例

以上のような環境間の相違は、プロビジョニングの負荷を大幅に押し上げる原因となる可能性があります。通常、プロビジョニングのエラーはデプロイのエラーとして現れるため、環境を構築してアプリケーションスイートを最初にデプロイするときまで顕在化しません。

制御された環境を初めて使用する場合、デプロイの問題の解決に手間と時間がかかることがよくあります。開発者もプロビジョニングチームも、複雑な環 境でデプロイの例外を解析した経験がないからです。開発者は、自身のテストマシンや統合環境でデプロイに成功すれば他の環境でのデプロイの問題も解決され たも同然だと考えがちです。逆に、テスト担当者や運用スタッフの側からすると、デプロイの問題は開発者がソフトウェアの配布作業の一環として解決済みのは ずのものであり、制御された複雑な環境でアプリケーションを実行したことがないと開発者から説明を受けた場合、不満に思うことが少なくありません。

要するに、 アプリケーションのプロモーションに必要な作業を過小評価すると、思いもよらない打撃をこうむることになります。

Pages: 1, 2

Next Page »