Comments
Transcript
アプリケーション開発管理 1 ISE Webシステム基盤 Webコア・インフラ グループ
アプリケーション開発管理 ISE Webシステム基盤 Webコア・インフラ グループ 小松 英之（[email protected]） 1 06. アプリケーション開発管理 Disclaimer この資料は日本アイ・ビー・エム株式会社ならびに 日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式なレビューを受けておりませ ん。 当資料は、資料内で説明されている製品の仕様を保証するものではありません。 資料の内容には正確を期するよう注意しておりますが、この資料の内容は2010年9月現在の情 報であり、製品の新しいリリース、PTFなどによって動作、仕様が変わる可能性があるのでご注意 下さい。 今後国内で提供されるリリース情報は、対応する発表レターなどでご確認ください。 2 WAS V7 アプリケーション・デザインWorkshop Part2 2 06. アプリケーション開発管理 Agenda 1. アプリケーション開発管理の機能要件 – 2. アプリケーション開発におけるツールの選択指針 – – – – 3. RTCによるチーム・コラボレーション、成果物管理 デプロイ後のモジュール管理 – 5. ソースコード管理 ビルド管理 テスト 問題管理 IBM Rational Team Concertによるチーム開発 – 4. アプリケーションの開発フロー アプリケーションの運用における考慮点 まとめ 3 WAS V7 アプリケーション・デザインWorkshop Part2 当セッションのアジェンダになります。 1章ではアプリケーション開発のフローをもとに、各フェーズにおいて発生しうる問 題と決定すべき事項について紹介致します。 2章ではフローでの決定すべき事項をもとに、ソースコード管理、ビルド、単体・結合 テスト、問題管理における有用なツールを紹介します。 3章ではワークアイテム管理やメンバー管理、計画管理、構成管理、ビルド管理を 統合したAll-in-One製品であるRational Team Concert(RTC)を紹介し、RTCにお ける管理方法やRTCを利用するメリット、各ツールとの連携について紹介致します。 4章ではデプロイ後のモジュール管理として、アプリケーション運用における考慮点 を上げ、WASやWVE、OSGiを用いた運用方法について紹介致します。 3 06. アプリケーション開発管理 アプリケーション開発管理の機能要件 4 WAS V7 アプリケーション・デザインWorkshop Part2 4 219.開発－デプロイのフローに関する検討 06. アプリケーション開発管理 アプリケーション開発のフロー 1. 2. 3. 4. 5. モジュール作成 単体テスト 実行ファイル（earファイル）作成 結合テスト デプロイ 開発チームA リリース管理 本番環境 ③実行ファイル作成 デプロイ、 ロールアウト 本番リリース ソースコード 管理サーバー 開発用PC ①モジュール作成 ビルド サーバー プロダクト 管理サーバー テストリリース テスト環境 ⑤デプロイ ②単体テスト 開発チームB デプロイ、 ロールアウト ④結合テスト 5 WAS V7 アプリケーション・デザインWorkshop Part2 アプリケーション開発のフローを上に示します。 アプリケーションの開発は、開発者が各モジュールを作成するところから始まります。 開発者が作成した成果物は単体テストを実施し、ソースコード管理サーバーで管 理されます。集められたソースコードは、ビルド担当者によりビルドサーバーでビル ドされ、実行ファイルとなります。規模が大きなアプリケーションの場合は、他の開発 チームの成果物と合わせて一つの実行ファイルを作成することもあります。 作成された実行ファイルは、プロダクト管理サーバーで保管され、管理運用担当者 によってテスト環境にリリースされます。テスト担当者はテスト環境で結合テストを行 います。テストにクリアすれば、デプロイ担当者によって、プロダクト管理サーバー から本番環境にリリースされ、アプリケーション・サーバー本番機にデプロイされま す。デプロイされたアプリケーションは、適切なアプリケーション・サーバー上で稼働 され、サービスインとなります。 1章では、モジュール作成、単体・結合テスト、実行ファイル作成、デプロイとアプリ ケーション・サーバー稼働の4つの観点から、発生しうる問題や決定すべき事項に ついて紹介します。 5 06. アプリケーション開発管理 ①モジュール作成 作業内容 – 1 特定時点へのソースコードの戻しが出来ない 古い日付のものを誤って上書き 存在するソースコードがどの時点のコードなのか不明 不必要なファイルの残存 2 0 3 1 見ているソースコードが どの時点コードかを知る必要 2 決定すべき事項 – – – 0 発生しうる問題 – – – – Javaのソースコードを開発し、モジュールを作成 ソースコードのバージョン定義 ソースコードの一括保管先 ソースコードの名称ルール 開発チームA 決定フェーズ – 基本設計 開発チームB 6 WAS V7 アプリケーション・デザインWorkshop Part2 モジュール作成は、Javaのソースコードを開発し、モジュールを作成するまでの段 階です。この段階ではソースコードの管理が課題となります。ソースコードの管理が 不十分だと、特定時点へのソースコードの戻しが出来ない。古い日付のものを誤っ て上書きしてしまう。存在するソースコードがどの時点のコードなのわからない。不 必要なファイルが残るといった問題が発生します。 そこでこの段階では、ソースコードのバージョン定義、一括保存先、名称ルールな どをあらかじめ決定し、ソースコード管理方法の選定を行う必要があります。その決 定フェーズは基本設計フェーズが良いでしょう。 6 06. アプリケーション開発管理 ②単体テスト、④結合テスト 作業内容 – 各自の環境で実施する単体テスト – テスト環境で実施する結合テスト – 発生した問題の管理 発生しうる問題 – – – – テスト漏れの発生 問題発覚による手戻り作業の発生 問題解決の遅れ 不明瞭な問題管理 決定すべき事項 – – – – テストの実施項目 テスト漏れの防止策 問題発生時のフローと管理 解決した問題の保管 決定フェーズ 開発チームA 開発チームB – 品質に関わる要件であるため、要件定義で 決定しておくことが望ましい 7 WAS V7 アプリケーション・デザインWorkshop Part2 アプリケーション開発で行うテストには、開発者が各個人の成果物レベルで行う単 体テストと、それらを元に作成された実行ファイルをテスト環境などで実行する結合 テストがあります。テスト段階においては、発生した問題の管理が鍵になります。テ スト段階での考慮が不十分だと、テスト漏れや問題発覚による手戻り作業が発生し たり、それにより問題解決の遅れに繋がることになります。 そうした不明瞭な問題管理を行わないためにも、テストの実施項目を明確にし、問 題発生時のフローと管理、解決した問題の保管が重要な決定事項となります。また、 テストはアプリケーションの品質に大きく関わりますので、要件定義の段階で、必要 なテスト項目と完了報告についてお客様と合意を得ることが望ましいです。 7 06. アプリケーション開発管理 ③実行ファイル作成 作業内容 – 複数のモジュールからデプロイ可能なearファイルを作成 発生しうる問題 – 誤ったバージョンの使用 – 構成要素の欠落 – 問題発生時の各要素のバージョンが不明 決定すべき事項 – 実行ファイルの各構成要素の管理方法 – 実行ファイル作成のタイミング 決定フェーズ 開発チームA – 基本設計 開発チームB 8 WAS V7 アプリケーション・デザインWorkshop Part2 開発者が作成したソースコードやモジュールを集めてコンパイルし、実行に必要な フレームワークのJarファイルなどを取り込んで、アプリケーション・サーバーでデプ ロイ可能なファイルを作成する段階です。この段階では、実行ファイルに必要な各 要素のバージョンを明確に把握しておくことがポイントとなります。それが不十分だ と、誤ったバージョンの使用や構成要素の欠落によるエラーの発生、また問題発生 時に各要素のバージョンが不明であり、問題の再現ができないといったことにもなり 兼ねません。 そのような問題を起こさないためにも、実行ファイルの各構成要素の管理が重要な 決定項目となります。また作成のタイミングも決定すべき事項の一つです。それらの 決定フェーズとしては基本設計フェーズが良いでしょう。 8 06. アプリケーション開発管理 ⑤デプロイ 作業内容 – 環境固有の情報を追加し、earファイルをアプリケーション・サーバーにデプロイ 発生しうる問題 – アプリケーションの誤リリース – サービス停止への影響 決定すべき事項 – アプリケーションの運用方法の確定 • • • サービス継続の必要性 切り替えの容易性 切り替え時間の最小化 開発チームA 決定フェーズ – 運用方法に関わる内容であるため、 要件定義段階で決定しておくことが 望ましい 開発チームB 9 WAS V7 アプリケーション・デザインWorkshop Part2 実行ファイルが作成され、テストを通過すれば、環境固有の情報を追加し、本番環 境にアプリケーションをリリースします。システムの規模によってはステージング環境 と呼ばれる環境を用意し、本番環境にリリースする前に本番環境想定のテストを行 うこともあります。リリース段階で発生すべき問題としては、誤ったアプリケーションの リリースが考えられますので、そのようなことがないためにも、プロダクト管理サー バーによるリリース管理が重要になります。 また、アプリケーションリリースの運用の観点から、サービス停止への影響を考慮す る必要があります。そのためにリリース時でもサービスを継続する必要があるか、切 り替えは容易に行えるか、要する時間はどれくらいか、といったことを考慮しなけれ ばなりません。これらは全て運用方法に関わる内容であるため、要件定義の段階で お客様と合意を得、その要件にふさわしい方法を取ることが望ましいです。 9 06. アプリケーション開発管理 アプリケーション開発におけるツールの選択指針 10 WAS V7 アプリケーション・デザインWorkshop Part2 10 113. 開発管理／テスト製品の選定 06. アプリケーション開発管理 アプリケーション開発とツール プロセス 自動化ツール 開発ツール 開発者 IBM Rational Application Developer ビルド担当者 デプロイ担当者 IBM Rational Build Forge / Ant / Maven IBM WebSphere Application Server 構成管理ツール ビルド記録 構成管理ツール 変更管理ツール ear デプロイ記録 jar java IBM Rational ClearCase / Subversion / CVS All-in-Oneの チーム開発推進ツール IBM Rational ClearQuest / Trac / Redmine IBM Rational Team Concert 結合テスト 単体テスト テスト自動化ツール IBM Rational Functional Tester 単体テストツール FindBugs / JUnit / jcoverage 11 テスト担当者 セキュリティー評価ツール IBM Rational AppScan WAS V7 アプリケーション・デザインWorkshop Part2 アプリケーション開発の流れを、使用するツールとともに図示した図です。 開発者が作成したソースコードやビルド担当者が作成した実行ファイルやモジュー ルは、成果物として構成管理ツールを用いて保管されます。構成管理ツールには IBM Rational ClearCase、オープンソースソフトウェアであればSubversion、CVS が挙げられます。また、ビルド担当者が行うビルドプロセスの自動化ツールとして IBM Rational Build Forgeがあります。構成管理ツールは、変更記録を管理する変 更管理ツールと連携することで、変更内容と成果物を結びつけることが可能です。 変更管理ツールとしては、IBM Rational ClearQuest、オープンソースであれば TracやRedmineが挙げられます。 また、構成管理や変更管理、ビルド管理といった一連の管理作業を一括して扱うた めのツールがIBM Rational Team Concert(RTC)です。RTCの導入により、アプリ ケーション開発で必要なさまざまな管理をAll-in-Oneで扱うことができ、それにより 連携にかかる運用コストを削減することができます。さらにRTCは、チーム開発を推 進するための機能も充実しています。 開発者の単体テストを支援するツールとして、 FindBugsやJunit、 jcoverageがあり ます。結合テストでは、Webアプリケーションのセキュリティーを評価するツールとし てIBM Rational AppScan。テストスクリプト作成を支援するIBM Rational Functional Testerなどを用います。 この章では、ソースコード管理、ビルド管理、テスト、問題管理の観点から有用な ツールを紹介し、どのような場面で用いられるかを紹介します。 11 06. アプリケーション開発管理 ソースコード管理 複数の開発者がモジュールを作成するためには、各開発者が作 成したソースコードを管理する仕組みが必要 ソースコード管理に求められること – ファイルの作成日時、変更日時、変更点などの履歴の保管 – 過去の状態や変更内容の確認 – 変更前の状態の復元が容易 0 以前の段階に復元も可能 現在、開発中のバージョン バージョンアップの際は履歴を残す 12 1 0 2 1 3 WAS V7 アプリケーション・デザインWorkshop Part2 複数の開発者が一つのモジュールを作成するためには、各開発者が作成したソー スコードを管理する仕組みが必要です。ソースコード管理には、ファイルの作成日 時や変更日時、変更点などの履歴に基づき、過去の状態や変更内容が確認でき ること、また、変更前の状態の復元が容易にできることが求められます。図のように、 開発者は、開発中のコードが現在どのバージョンなのかを把握し、それらをバー ジョンアップした際には履歴が残せるようにしなければなりません。また、以前の段 階に復元する必要がある場合にも、容易に対応できる必要があります。 12 06. アプリケーション開発管理 ソースコード管理の流れ 作成されたコードの一元管理 – リポジトリー • • – 成果物を一括管理 各開発者はリポジトリーからローカル環境にファイルをチェックアウト 各開発者のローカル環境 • • チェックアウトされたファイルに対し変更 変更したファイルをリポジトリーにチェックイン リポジトリー チェックアウト 開発者Aは ファイルAを変更 A変更 チェックイン A変更 A変更 ビルドされ、 実行可能ファイルへ B変更 開発者Bは ファイルBを変更 B変更 モジュールAの推移 13 WAS V7 アプリケーション・デザインWorkshop Part2 複数の開発者が一つのモジュールを作成するためには、作成した成果物を一元管 理する必要があります。そのためのソースコード管理の仕組みが「リポジトリー」と 「ローカル環境」です。リポジトリーは全ての成果物を管理する保管庫で、各開発者 はリポジトリーからローカル環境に担当ファイルをチェックアウトして作業を行います。 各開発者のローカル環境では、チェックアウトされたファイルを変更し、変更した ファイルを再度リポジトリーにチェックインすることで、リポジトリーに反映されます。 各開発者が担当するファイルを変更し、推移したモジュールは随時バージョニング されます。そして、あるタイミングでビルド担当者によってビルドされ、実行可能ファ イルとなります。 13 06. アプリケーション開発管理 ソースコード管理に用いるツール 代表的なソースコード管理ツール – CVS（Concurrent Version System） • The CVS Teamによって開発された、オープンソースのバージョン管理システム • ファイルの変更履歴を一括管理 • 実績は非常に多いが、近年ではSubversionなどに推移 – Subversion • CVSをもとに機能拡充が行われた、オープンソースソフトウェア • Apache Incubatorプロジェクト配下のバージョン管理システム • CVSの課題であった、ディレクトリの移動削除やアトミック・コミットにも対応 – IBM Rational ClearCase • IBM Rational 開発の構成管理ツール • 小規模のワークグループからエンタープライズ規模の分散型チームまで、様々な規模 のチームをサポート • さまざまなツールと統合し、資産を全ライフサイクルに渡って管理 14 WAS V7 アプリケーション・デザインWorkshop Part2 ソースコード管理に用いられる代表的なツールを紹介します。 CVSはThe CVS Teamによって開発された、オープンソースのバージョン管理シス テムです。ファイルの変更履歴を一括管理できるツールとして歴史もあり、実績は 非常に多いですが、近年ではSubversionに変更されつつあります。 SubversionはCVSをもとに機能の拡充が行われたオープンソースソフトウェアです。 開発はCollabNet社ですが、Apache Incubatorプロジェクト配下となり、ライセンス もApache Licenseに準じたものとなっています。SubversionではCVSの課題で あったディレクトリの移動や削除をサポートし、複数のファイルを同時にコミットした 場合の原子性の確保にも対応しています。そういった改善点により、現在ではCVS をSubversionに移行するプロジェクトも多くなっています。 IBM Rational ClearCaseはIBM Rationalが開発した構成管理ツールです。 Rational ClearCaseは、小規模のワークグループからエンタープライズ規模の分 散型チームまで、様々な規模のチームを取り扱うことができ、他のツールと統合する ことで、資産を全ライフサイクルに渡って管理することも可能です。 14 06. アプリケーション開発管理 Subversion CollabNet社が開発した、オープンソースのバージョン管理システム – Apache Incubatorプロジェクトの一つであり、Apache Licenseに準じたライセンス体系 – 最新バージョンはv1.6.12 日本語書籍や資料も多数あり、習得は容易 Subversionのリポジトリーにアクセスするためのクライアントが必要 – CollabNet Subversion Command-Line Client – TortoiseSVN – Eclipseのプラグインとしても提供 Subversionのバージョン管理の特徴 – コミット毎にコミットログを作成 • コミットの際には「リビジョン番号」が振られ、変更セットが特定 – リビジョン番号による変更セットの特定 • 番号がコミット単位であるため、 リビジョン番号を指定すれば、特定の変更前の状態に コミット コミットログ コミットログ リビジョン番号：1 15 WAS V7 アプリケーション・デザインWorkshop Part2 SubversionはCollabNet社が開発したオープンソースのバージョン管理システムで す。現在はApache Incubatorプロジェクト配下となり、Apache Licenseに準じたラ イセンス体系となっています。現在での最新版はv1.6.2です。Subversionは日本 語書籍や資料も多数あるため、機能の習得はしやすいと言えます。 Subversionはリポジトリーでファイルの一元管理を行いますが、リポジトリーにアク セスするためにはクライアントが必要になります。CUIでアクセス可能なCollabNet Subversion Command-Line Clientも用意されていますが、Windows環境であれ ば、GUIで直感的にアクセスすることが可能なTortoiseSVNが有名です。また、 Eclipseのプラグインとしても提供されているため、Eclipseからアクセスを行うことも 可能です。 Subversionのバージョン管理の特徴は、コミット毎にコミットログを作成され、リビ ジョン番号もコミット毎に付けられることです。そのため、一つのコミットが変更作業 に結びつき、リビジョン番号を指定すれば、変更前の状態に戻すことが可能です。 15 06. アプリケーション開発管理 IBM Rational ClearCase 成果物の管理と開発のコントロールを行う構成管理ツール – – – – – ファイルやディレクトリのバージョン管理 並行開発の実現するための開発環境の提供 ブランチやバージョンをビジュアル的に表示 ビルドに用いたファイルやディレクトリの整合性確保 ビルドの追跡と再現 変更管理ツールであるClearQuestと連携 最新バージョンはv7.1.1.3 (2010/08) 大規模プロジェクトではClearCase、小規模で短期的なプロ ジェクトはSubversion – コントロール • プロジェクトの状況のトラッキング – 分散開発環境への対応 • マルチサーバーをサポート – コンプライアンス • 16 監査能力と追跡管理機能 WAS V7 アプリケーション・デザインWorkshop Part2 IBM Rational ClearCaseは、成果物の管理と開発のコントロールを行う、ソフトウェ ア構成管理ツールです。主な機能は、ファイルやディレクトリのバージョン管理。並 行開発を実現するための開発環境を提供するワークスペース管理。ビルドに用い たファイル･ディレクトリの整合性を確保するビルド管理機能などです。特長として、 並行開発のためのブランチやバージョン管理のためのラベルをビジュアルに表示 でき、ビルド時のバージョンや環境変数を自動で記録するなど、監査性に優れたビ ルド管理機能を提供していることが挙げられます。また、変更管理ツールである ClearQuestと連携して用いることが多く、ClearQuestで扱う変更内容とClearCase で扱う成果物の情報を結びつけて管理を行うことが可能です。 現在での最新版は v7.1.1.3です。 SubversionとClearCaseの判断基準としては、扱うプロジェクトの規模が目安になり ます。小規模で短期的なプロジェクトはSubversionでも構いませんが、大規模プロ ジェクトになるとClearCaseを用いるほうが良いとされています。また、ClearCaseに はプロジェクト状況のトラッキング、マルチサーバーのサポート、監査追跡機能と いったSubversionにはない機能を備えています。 参考料金）「IBM Rational ClearCase Floating User License + SW Subscription & Support 12 Months (D5315LL) 」¥677,900https://www112.ibm.com/software/howtobuy/buyingtools/paexpress/Express?P0=E1&par t_number=D5315LL,D0BH1LL,D0BH2LL&catalogLocale=ja_JP&Locale=ja_J P&country=JPN&PT=html&S_TACT=none&S_CMP=none&brand=rat 16 06. アプリケーション開発管理 IBM Rational ClearQuest 変更依頼とその状態を管理する変更 管理ツール – 集中管理されたデータベースに、障害 や機能追加などの変更依頼が蓄積 – メンバーが情報をリアルタイムに共有 – 個々の担当者にアサインされた作業 をトラッキング 変更依頼のライフサイクルをサポート 変更依頼の分析 – グラフの表示、レポートの出力 最新バージョンはv7.1.1.3 (2010/08) 17 WAS V7 アプリケーション・デザインWorkshop Part2 IBM Rational ClearQuestは、アプリケーションのライフサイクルを通じての障害や 機能追加といった変更依頼とその状態を管理する変更管理ツールです。集中管理 されたデータベースに障害や機能追加などの変更依頼が蓄積され、メンバーはそ の情報をリアルタイムで共有することが可能です。また、管理者はその情報を通じ て、担当者にアサインされた作業のトラッキングを行うことができます。 変更依頼は右上図のようにアクションの発生により状態を遷移させることができます。 図はその一例ですが、状態やアクションについてはプロジェクトごとにカスタマイズ して定義することも可能です。それらの変更依頼は、グラフとして表示したり、レ ポートとして出力させることもできます。右下図は所有者別の障害の状態をグラフ化 したものです。 IBM Rational ClearQuestの現在での最新版はv7.1.1.3です。 参考料金）「IBM Rational ClearQuest Floating User License + SW Subscription & Support 12 Months (D531LLL) 」¥743,600 – https://www112.ibm.com/software/howtobuy/buyingtools/paexpress/Express?P0=E1&par t_number=D53NSLL,D531LLL,D56DBLL,D56DDLL,D0BHBLL,D0BHCLL,D0 BHDLL,D0BHELL&catalogLocale=ja_JP&Locale=ja_JP&country=JPN&PT=h tml&S_TACT=none&S_CMP=none&brand=rat 17 06. アプリケーション開発管理 ビルド管理 ビルド – ソースコード、設定ファイル、画面ファイル（JSPやHTML）など構成要素を組み合 わせて「実行可能ファイル」を作成 – JavaEEアプリケーションを作成する場合、warファイルやearファイルが実行可能 ファイルに相当 特に大規模なアプリケーションの作成には、ビルド専用のツールが必要となる ケースが多い ビルド管理ツールに求められること – – – – 18 実行可能ファイルに存在する各構成要素の組み合わせを記録 ビルドされたものを個別に認識 必要なライブラリーとの関係の把握 ビルド手順や単体テストの自動化 WAS V7 アプリケーション・デザインWorkshop Part2 作成されたソースコードはコンパイルされ、設定ファイルや画面ファイル、さらにフ レームワークに必要なJarファイルなどを取り込み、一つの実行可能ファイルとなりま す。この実行可能ファイルを生成する作業をビルドと言います。JavaEEアプリケー ションであれば、warファイルやearファイルが実行可能ファイルに相当します。 ビルド作業自体は各個人の環境でも行うことが可能です。しかし、大規模なアプリ ケーションとなると、複数のメンバーで一つのアプリケーションを作成することもあり、 そのような状況で各個人の環境だけでビルドを行うと、成果物の管理が困難です。 そこで、そのような大規模アプリケーションの作成にはビルド用の環境を用意し、ビ ルド専用ツールが必要となるケースも多くあります。 そのようなビルド管理ツールに求められることは、実行可能ファイルに存在する各 構成要素の組み合わせを記録。ビルドされたものを個別認識。必要なライブラリー との関係の把握。ビルド手順や単体テストの自動化などが挙げられます。 18 06. アプリケーション開発管理 JavaEEアプリケーションの作成 JavaEEアプリケーション・ファイルの構成要素 – Webモジュール – EJBモジュール – アプリケーションクライアント・モジュール フレームワークが提供するJarファイルも、libディレクトリー配下に配置 JSP WARファイル Webモジュール Servlet HTML モジュールの開発 実行 単体テスト ディプロイメント・ ディスクリプター(DD) JARファイル 使用するフレームワークが 提供するJarファイル JARファイル EJBモジュール EJB ディプロイメント・ ディスクリプター ディスクリプター(DD) E A R フ ァ イ ル デプロイ 稼働確認 JARファイル APP Client 19 アプリケーション クライアント・モジュール ディプロイメント・ ディスクリプター(DD) WAS V7 アプリケーション・デザインWorkshop Part2 JavaEEアプリケーション・ファイルは、Webモジュール(war)、EJBモジュール(jar)、 アプリケーションクライアント・モジュール(jar)などのファイルを含んでいます。フ レームワークを用いる場合は、Webモジュールのlibディレクトリーの配下などにフ レームワークが提供するJarファイルを配置する必要があります。これらを含んだ EARファイルは、JavaEEの実行ファイルとして、アプリケーション・サーバーにデプ ロイされ、稼働確認を行います。 19 06. アプリケーション開発管理 ビルドのタイミング ビルドは定期的に実施 – 最初のビルドは、実現可能性の調査と検証が目的なので週次レベル – プロジェクトが進み、アプリの品質チェックが目的になると日次に – ビルドの自動化により期間は縮小可能 期間内で以下のような項目を計測することにより、ビルドの品質 の安定を示す指標となる – 発生した不具合の数 – 修正した不具合の数 – 未修正の不具合の数 20 WAS V7 アプリケーション・デザインWorkshop Part2 プロジェクト開始時のビルドは実現可能性の調査と検証が目的ですので、週次レ ベル等、期間を少し広めにします。プロジェクトが進み、アプリケーションの品質 チェックが目的になると、週次から日次レベルにするなど、期間を短縮させることが 一般的です。ビルドの自動化が可能になると、さらに期間は縮小させることができま す。また、ビルド実行時には、期間内に発生した不具合の数、修正した不具合の数、 未修正の不具合の数などを計測し、プロジェクト進行に伴うビルドの品質安定性を 示す指標とします。 20 06. アプリケーション開発管理 ビルドに用いられるツール Apache Ant – – – – ビルドのルールをXML文書で記述 EclipseにはAntプラグインが標準で内蔵 WAS、RADもAntをサポート 最新バージョンはｖ1.8.1 Apache Maven – ソースコードのコンパイルやテストだけでなく、テストレポート生成、サー バーへのデプロイなど、様々な機能 – 最新バージョンはv2.2.1 21 WAS V7 アプリケーション・デザインWorkshop Part2 ビルドに用いられるツールとしては、AntとMavenが有名です。Apache Antはビル ドのルールをBuild.xmlというXML文書で記述し、その定義に基づいてビルドを実 行します。EclipseにはAntプラグインが標準で内蔵され、WASやRADもサポートし ているため、EclipseやRAD、WASの環境があれば、導入を別途しなくても使用す ることができます。最新版はv1.8.1です。Mavenはソースコードのコンパイルやテス トだけでなく、テストレポート生成、サーバーへのデプロイなど、様々な機能を持っ たビルドツールであり、XML構成ファイルへの記述が困難な、より複雑なビルドでも 簡単にビルドを実行することができます。最新版はv2.2.1です。 いずれもオープンソースソフトウェアですが、日本語の書籍や資料もあり、開発に用 いられる実績は非常に多いです。 21 06. アプリケーション開発管理 IBM Rational Build Forge ソフトウェア配布プロセスの実行自動化ツール – ソースや関連モジュールから実行可能なソフトウェアを生成するプロセスの自動化 – コーディングからビルド、テスト、デプロイまでのチームの手作業での連携を効率化 工程間の情報を集約し、可視化 – ボトルネックの発見や ビルドプロジェクトの傾向の把握 • リリース毎の実行時間の傾向 • ビルドのステップ毎の実行時間のグラフ • ビルドプロジェクトに対する分析結果…など 最新バージョンは V7.1.1.4(2010/05) 22 WAS V7 アプリケーション・デザインWorkshop Part2 IBM Rational Build Forgeはソフトウェアの配布プロセスの自動化を実現するツー ルです。Build Forge自体にはビルド機能そのものはありませんが、ビルドのみに限 らず、コーディングからビルド、テスト、デプロイといった、実行可能なソフトウェアを 生成するプロセスを自動化することが可能です。さらに自動化により、チームの手 作業での連携を効率化することができます。最新版はv7.1.1.4です。 Rational Build Forgeはプロセス自動化だけではなく、その工程間の情報を集約し、 可視化することができます。右図はビルドステップ毎の実行時間のグラフと、ビルド プロジェクトのビルドの実行数や成功数、実行時間など、分析結果を示した表です。 このような情報を収集することで、ボトルネックの発見やビルドプロジェクトの傾向の 把握ができます。 参考料金）「IBM Rational Build Forge Standard Edition Server License + SW Subscription & Support 12 Months (D59BCLL) 」¥17,303,000 https://www112.ibm.com/software/howtobuy/buyingtools/paexpress/Express?P0=E1&par t_number=D59BHLL,D59BJLL,D59BCLL,D60GSLL,D60L8LL,D60U4LL,D60 U0LL,D60S7LL,D60SVLL,D60S1LL,D60SALL,D090VLL,D090XLL,D0BIPLL, D0BIQLL,D0BIRLL,D0BISLL,D0BIZLL,D0BJ0LL&catalogLocale=ja_JP&Loca le=ja_JP&country=JPN&PT=html&S_TACT=none&S_CMP=none&brand=rat 22 06. アプリケーション開発管理 単体テスト、結合テスト アプリケーションの品質管理の指標 – コーディング規約の遵守 • フォーマットは適切か、コーディング規約にそっているか、バグになりやすい コードはないか – 動作の保証 • 決められた仕様通りに動作するか – テストの網羅性 • テストケースに漏れがないか – コードの脆弱性 • 23 公開した際に問題となる脆弱性はないか WAS V7 アプリケーション・デザインWorkshop Part2 テストはアプリケーションの品質管理の指標となるものですので、どのようなテストを 行い、どのような結果になれば問題ないかをお客様と事前に決定しておく必要があ ります。 アプリケーションの品質管理のための指標としては、コーディング規約の遵守、動 作保証、テストの網羅性、コードの脆弱性などがあります。 23 06. アプリケーション開発管理 テスト支援ツール 各品質管理指標に対応したテスト支援ツール – コーディング規約の遵守 ： FindBugs • コードレビューツール、欠陥の起こりやすいコードパターンをレビュー – 動作の保証 ： JUnit • 作成したコードが仕様どおりに正しく動くかをテスト – テストの網羅性 ： jcoverage • テストがどれくらい網羅できてるかを測定 – コードの脆弱性 ： IBM Rational AppScan • Webアプリケーションの脆弱性を検知し、修正案を提供 テストを効率よくするための自動化支援ツール – IBM Rational Functional Tester – ユーザーとのやり取りを記録し、テストスクリプトを作成 24 WAS V7 アプリケーション・デザインWorkshop Part2 品質の指標が決まったら、使用するツールの検討を行います。コードレビューは FindBugs、単体テストの動作保証はJUnit、テストの網羅性チェックはjcoverage、 コードの脆弱性検知はIBM Rational AppScanを、この章ではそれぞれ紹介致しま す。また、テストを効率よく行うための自動化支援するツールとしてIBM Rational Functional Testerを合わせて紹介します。 Rational Functional Testerはユー ザーとのやり取りを記録し、テストスクリプトを作成するツールです。 24 06. アプリケーション開発管理 各ツールの使用時期 コードレビュー ソースコードの体系的な検査 参加者の共通認識を図り、可読性を向上させる目的 FindBugs 単体テスト メソッドなどの小さな単位で行うテスト コードが正しく動作することを確認する目的 JUnit / jcoverage 結合テスト 単体テストが完了したプログラムを組み合わせて行うテスト 単体テスト実施済みのプログラムを組み合わせた際の 正しく動作することを確認する目的 IBM Rational AppScan IBM Rational Functional Tester システムテスト 25 他のプログラムやハードウェア、 ネットワーク、データベースなどと組み合わせて実施するテスト システム全体として動作することを確認するのが目的 WAS V7 アプリケーション・デザインWorkshop Part2 テストはコードレビュー、単体テスト、結合テスト、システムテストの順に行い、それぞ れのフェーズでテストの目的が異なります。コードレビューはソースコードの体系的 な検査であり、参加者の共通認識を図ることと可読性の向上が目的です。単体テス トはメソッドなどの小さな単位で行うテストであり、コードの動作確認が目的です。結 合テストは単体テストが完了したプログラムを組み合わせて行うテストのことであり、 単体テスト実施済みのプログラムを組み合わせた際の動作確認が目的です。シス テムテストは他のプログラムやハードウェア、ネットワーク、データベースなどを組み 合わせて実施するテストであり、システム全体としての動作確認が目的です。これら のフェーズに、先ほどのテストツールを当てはめると、FindBugsはコードレビュー、 JUnitやjcoverageは単体テスト、 Rational AppScanやRational Functional Testerは結合テストの際にそれぞれ有効なツールであると言えるでしょう。 25 06. アプリケーション開発管理 FindBugs コード解析ツール – クラスファイルやJarファイルを入力し、コードの脆弱性や問題点のチェックを実施 – GNU Lesser General Public Licenseライセンスによるオープンソースソフトウェア – 最新バージョンはv1.3.9 FindBugsの特長 – 単体でも使用可能、Eclipseプラグインも存在 – 解析結果はXMLデータとして出力 – ツールも日本語に対応し、日本語訳のマニュアルも存在 – 導入してすぐに使用可能 26 WAS V7 アプリケーション・デザインWorkshop Part2 FindBugsは、クラスファイルやJarファイルを入力し、コードの脆弱性や問題点の チェックを行うコード解析ツールです。FindBugsはGNU Lesser General Public Licenseライセンスによるオープンソースソフトウェアであり、最新版はv1.3.9です。 FindBugsは個別に導入して使用することもできますが、プラグインを導入して Eclipse環境から使用することも可能です。解析結果はXMLのデータとして出力さ れます。また、ツールも日本語に対応し、日本語に訳されたマニュアルもありますの で、使用は容易と言えるでしょう。 26 06. アプリケーション開発管理 FindBugs コード解析の結果画面 対応する指摘箇所 検出された内容 詳細な説明と対策 27 WAS V7 アプリケーション・デザインWorkshop Part2 コード解析の結果画面は上のようになります。分析するアーカイブやディレクトリー を入力すると解析が始まり、検出された内容が画面左上、その詳細な説明が下に 表示されます。ソースディレクトリーも合わせて入力すると、検出内容の対応箇所が 右上に表示されます。 27 06. アプリケーション開発管理 JUnit Javaプログラム単体テスト用のフレームワーク – 作成したコードに対し、テスト用プログラムを作成 – Common Public Licenseライセンスによるオープンソースソフトウェア – 最新バージョンはv4.8.1 JUnitの特長 – Eclipseから利用可能であるため、コーディングと同時にテストコードの作成 が可能 – Eclipseに同梱されているため、別途導入は不要 – 日本語の資料や書籍もあり、習得は容易 28 WAS V7 アプリケーション・デザインWorkshop Part2 JUnitはJavaプログラムの単体テスト用のフレームワークです。このフレームワークを 用いて作成したコードに対するテスト用のプログラムを作成し、テスト用プログラムを 実行させることでテストを実施します。JUnitはCommon Public Licenseライセンス によるオープンソースソフトウェアであり、最新版はv4.8.1です。 JUnitはEclipseやRADにプラグインが内蔵されているため、EclipseやRADの環境 があれば別途導入しなくてもJUnitを使用でき、コーディングと同時にテストコードを 作成し実行することが可能です。また、日本語の資料や書籍もあるため、習得は容 易と言えるでしょう。 28 06. アプリケーション開発管理 JUnit テスト後の画面 実行されたメソッドと 実行時間 コード上の 問題発生箇所 失敗した箇所 29 WAS V7 アプリケーション・デザインWorkshop Part2 JUnitによるテスト画面は上のようになります。上はRational Application Developr v7.5環境でJUnitのテストを実行させています。左上に実行されたメソッドと実行時 間、左下に失敗した箇所、右にコード上の問題発生箇所が指摘されています。 29 06. アプリケーション開発管理 jcoverage 単体テスト実施時のコードの網羅率測定ツール – Antなどを利用し、クラスファイルに対して網羅率を収集するプログラムを埋め込 み、そのコードを用いて単体テストを実施し、レポートを表示 – FindBugsやJUnitと比較すると、資料は少なく、習得はやや難 djUnit / Cobertura – jcoverageはGNU General Public Licenseライセンス版は開発、保守が終了 – jcoverageを引き継いだ網羅率測定ツール – djUnit • Eclipseのためのプラグインとして提供 • 内部でjcoverageを利用し、Junitの実行結果よりレポートを表示 – Cobertura • Antタスクがモジュールとして提供され、Antタスクを利用して網羅率を測定 30 WAS V7 アプリケーション・デザインWorkshop Part2 jcoverageは単体テスト実施時のコードの網羅率を測定するツールです。 jcoverageはAntなどを利用し、クラスファイルに対して網羅率を収集するプログラム を埋め込み、そのコードを用いて単体テストを実施することで結果を表示します。 jcoverageの使用にはAntの知識も必要であり、またFindBugsやJUnitと比較すると 資料は少なく、習得はやや難と思われます。 jcoverageはGNU General Public Licenseライセンスによるオープンソースソフト ウェアでしたが、GPL版は開発および保守は完了しているため、その機能はdjUnit やCobertuna(コヴェルトゥーラ)に引き継がれています。djUnitはEclipseのプラグイ ンとして提供され、内部でjcoverageを利用してJUnitの実行結果よりレポートを表 示することが可能です。 CobertunaはAntタスクを利用して網羅率の測定を行いま すので、jcoverageの使用方法に比較的近いと言えます。 30 06. アプリケーション開発管理 jcoverage 測定後の画面 行の網羅率 分岐の網羅率 テストコードでは この行が 網羅されていない 31 WAS V7 アプリケーション・デザインWorkshop Part2 jcoverageによる測定後の画面です。テスト対象全体、パッケージ別、Javaファイル 個別、それぞれ行の網羅率と分岐の網羅率がグラフで表示されます。Javaファイ ル名をクリックすると、網羅されていない箇所が色付きで表示されます。上の例では、 15行目の行網羅がされていないことを示しています。14行目は変数aとbがともに0 の条件分岐ですので、この条件を満たすテストケースが欠けていることがわかりま す。 31 06. アプリケーション開発管理 IBM Rational AppScan Webアプリケーションのセキュリティー評価ツール – 開始URL とログイン手順を指定するだけでスキャンが可能 – インフラ(Webサーバー)の設定ミスも判断可能 – SOAPを利用したWebサービスの検査も可能 最新バージョンはV7.9.0.3 (2010/07) テスト・ポリシーを選択したスキャンも可能 – テストをカテゴリー化したもの – Application-Only、Infrastracture-Only、Invasive(侵入) …など 修復作業も表示可能 – 修復作業ビューで、脆弱性を修正する作業別に表示 32 WAS V7 アプリケーション・デザインWorkshop Part2 IBM Rational AppScanはWebアプリケーションのセキュリティー評価ツールです。 Rational AppScanは開始URLとログイン手順を指定することでスキャンを行い、ア プリケーションの脆弱性を判断することが可能です。アプリケーションはSOAPを利 用したWebサービスの検査にも対応し、Webサーバーであれば設定ミスも判断す ることが可能です。最新版はv7.9.0.3です。 Rational AppScanはテストをカテゴリー化したテスト・ポリシーによってスキャンを行 いますので、インフラ面のみ、アプリケーション面のみ、侵入に関する脆弱性といっ たように、問題に合わせてスキャンすることも可能です。また、必要な修復作業も結 果に表示されますので、問題に対する修正作業も行うことができます。 参考料金）「IBM Rational AppScan Standard Edition Floating User License + SW Subscription & Support 12 Months (D61SYLL) 」¥4,791,000https://www112.ibm.com/software/howtobuy/buyingtools/paexpress/Express?P0=E1&par t_number=D61SYLL&catalogLocale=ja_JP&Locale=ja_JP&country=JPN&PT =html&S_TACT=none&S_CMP=none 32 06. アプリケーション開発管理 IBM Rational AppScan スキャン後の画面 レポート出力 セキュリティ 問題ビュー スキャン結果 修復作業 ビュー アプリケーションの ファイル構造 結果の詳細 重要度別の問題総数 33 WAS V7 アプリケーション・デザインWorkshop Part2 Rational AppScanを用いたスキャン画面の例です。右上のスキャン結果に対し、 右下に結果の詳細が記載されています。これは「セキュリティ問題ビュー」の画面で すが、「修復作業ビュー」を選択すると、問題に対する修復作業を確認することもで きます。 33 06. アプリケーション開発管理 IBM Rational Functional Tester 機能テストの自動化ツール – アプリケーションとユーザー間の操作を記録し、ユーザー操作を再現でき るテストスクリプトの作成 – 検証の結果レポートの生成 – テスト中のアプリケーションに検証ポイントを挿入して、指定のデータやプ ロパティーを抽出 最新バージョンはV8.1.1.3 (2010/09) テスト結果 34 WAS V7 アプリケーション・デザインWorkshop Part2 IBM Rational Functional TesterはJavaやWebアプリケーションのGUIアプリケー ション向けの機能テストを自動化するツールです。アプリケーションに対して行う ユーザーとの一連の操作を記録し、操作を再現するテストスクリプトを生成します。 このスクリプトを再生することで、同じ画面操作を再現することができます。 また、自動実行された機能テストはHTML形式などのレポートとして出力されます。 テスト中のアプリケーションには検証ポイントを挿入することができますので、レポー トのどのチェックポイントでの実際のデータやプロパティーを判断することもできます。 最新版はV8.1.1.3です。 参考料金）「IBM Rational Functional Tester Floating User License + SW Subscription & Support 12 Months (D530BLL) 」¥1,616,000https://www112.ibm.com/software/howtobuy/buyingtools/paexpress/Express?P0=E1&par t_number=D53NFLL,D530BLL,D54SHLL,D0BGLLL,D0BGMLL,D0BGNLL&c atalogLocale=ja_JP&Locale=ja_JP&country=JPN&PT=html&S_TACT=none& S_CMP=none&brand=rat 34 06. アプリケーション開発管理 問題管理 問題管理の重要性 – 地理的、時間的なメンバー間での問題の共有 問題管理で求められること – 問題管理の記録 • • • • • 問題の発生条件 問題の影響範囲 問題原因 問題に対する修正案 修正案の採用理由 対応中の問題の 対応状況 対応後の問題の 原因・修正案 – 発生した問題に対する対処状況の把握 35 WAS V7 アプリケーション・デザインWorkshop Part2 問題管理は地理的、時間的なメンバー間で問題を共有することが目的です。問題 管理で求められることは、問題の発生条件、問題の影響範囲、問題原因、問題に 対する修正案、修正案の採用理由など、問題管理の記録と、発生した問題に対す る対処状況の把握です。 35 06. アプリケーション開発管理 問題管理ツール 表計算ソフトによる管理表＋ファイルサーバー＋メーリングリストの課題 – タスクが増えるにつれ、一覧表を最新の状態にしておくのが困難 – ファイルサーバーにある情報と各自の情報にズレ – 変更履歴が残せず、問題の追跡が困難 問題管理ツール – Trac • Pythonで実装されたバグ管理ソフトウェア • チーム開発を推進するためのコミュニケーションツール – Redmine • Ruby on Railsで実装されたバグ管理ソフトウェア • 問題管理を重点とした、プロジェクト管理 – 問題管理の機能ならRedmine – コミュニケーションを重点におけばTracも十分選択肢に 36 WAS V7 アプリケーション・デザインWorkshop Part2 問題管理はかつて、表計算ソフトで作成した管理表をファイルサーバーに置き、変 更の度にメールで通知するということが一般的でした。しかし、タスクが増えるにつ れ、一覧表を最新の状態にしておくのも困難ですし、ファイルサーバー上の管理表 の情報と各自認識している情報とのズレも生じることもあります。また、変更履歴が 残せないため、問題の追跡が困難である課題もあります。このような課題の解決策 として、問題管理ツールが開発されました。 問題管理ツールとして、ここではTracとRedmineを紹介します。TracはPythonで実 装、RedmineはRuby on Railsでそれぞれ実装された、オープンソースのバグ管理 ソフトウェアです。どちらも問題管理ツールとして実績もありますが、問題管理の機 能としてはRedmineのほうが高機能です。しかし、Tracにはコミュニケーションツー ルとしての用途もありますので、問題管理の機能に重点を置くならRedmineですが、 コミュニケーションツールとして重点を置くならTracも十分選択肢として考えられま す。 36 06. アプリケーション開発管理 チケットによる問題管理 作業単位は「チケット」 – プロジェクトのタスク、報告された問題、 QAなど – チケットの状態に応じて、各担当者が 適切な処理を実施 – チケットの情報をメンバー間で共有する ことで、作業状況を全員が把握可能に チケットはバージョン管理システムと連携 – 問題解決に要した変更ファイルと チケットをリンクし、問題とファイル操作の 関係を明確に 37 WAS V7 アプリケーション・デザインWorkshop Part2 TracやRedmineはともに「チケット」を作業単位としています。チケットはプロジェク トのタスク、報告された問題、QAなどが記載され、状態に応じて各担当者が適切な 処理を行い、状態を変更させます。チケットの情報はメンバー間で共有することが 可能ですので、作業状況を全員で把握することができます。 また、チケットはバージョン管理システムと連携させるのが一般的です。問題解決に 要した変更ファイルとチケットをリンクし、問題とファイル操作の関係を明確にするの が連携させる大きな目的です。 37 06. アプリケーション開発管理 Trac EdgeWall Software およびThe Trac Project が開発した、オープンソースの問題管理 ツール – 修正BSDライセンスで公開 – 最新バージョンはv0.12 本来は英語だが、日本語化されたTrac-jaもインタアクト社から公開 – 日本語書籍もあり、習得は容易 – 最新バージョンはV0.12.ja1 Trac Lightning – Webサーバー、Pythonの動作環境、データを保存するDBなど、導入と設定が複雑 – Tracの稼働に必要なソフトウエアや主要なプラグインを簡単にインストール、設定するため のインストーラー – Trac Lightningの最新バージョンはv2.5.2 （導入されるTrac-jaはv0.11.7.ja1） Webサーバー（Apache） tracd CGI（mod_python） Trac データベース（SQLite） 38 バージョン管理システム（Subversion） HTMLテンプレート（ClearSilver/Genshi） WAS V7 アプリケーション・デザインWorkshop Part2 TracはEdgeWall Software およびThe Trac Project が開発した、オープンソース の問題管理ツールであり、修正BSDライセンスで公開されています。最新版は v0.12です。Tracは本来は英語ですが、日本語化されたTrac-jaもインタアクト社か ら公開されており、その最新版はV0.12.ja1です。Trac-jaはTracに日本語化のた めの変更が加えられているモジュールです。また、Tracは日本語の書籍などもある ため、習得は容易です。 TracはWebサーバー、Pythonの動作環境、データを保存するDBなど、多数の ツールの導入と連携のための設定が必要であり、それらを全て自身で行うのは骨 が折れます。そこでTracの稼働に必要なソフトウエアや主要なプラグインを簡単に インストール、設定するためのインストーラーTrac Lightningが公開されています。 Trac Lightningの最新版はv2.5.2ですが、導入されるTrac-jaはv0.11.7.ja1となりま すので注意して下さい。 38 06. アプリケーション開発管理 Redmine Jean-Philippe Lang氏が中心となり開発された、オープンソースの問題管理ツール – GNU General Public License v2で公開 – 最新バージョンはv1.0.1 本来は英語だが、日本語の情報は多い – 日本語書籍もあり、習得は容易 BitNabi – Redmine、Ruby on Rails、MySQLをセットで導入するAll-in-oneインストーラー Trac同様「チケット」による問題管理を実施し、バージョン管理システムと連携可能 Tracとの相違点 – Tracよりも、より多くの作業をWebベースで実施可能 – 日本語を含め、多くの言語をユーザーごとに切り替えて利用可能 39 WAS V7 アプリケーション・デザインWorkshop Part2 RedmineはJean-Philippe Lang氏が中心となり開発された、オープンソースの問 題管理ツールであり、GNU General Public License v2で公開されています。最新 版はv1.0.1です。Redmineも本来は英語ですが、日本語に訳されたマニュアルや 書籍もあるため、習得はそれほど困難ではありません。RedmineにもBitNaviと呼ば れるAll-in-oneインストーラーが存在し、チケットよる問題管理や、バージョン管理シ ステムとの連携も可能です。 RedmineはTracよりも高い機能を持っています。例えばTracよりも多くの作業が Webベースで実施できますし、日本語以外の多くの言語をユーザーごとに切り替 えて利用することも可能です。 39 06. アプリケーション開発管理 問題管理ツールとバージョン管理システムの連携 問題管理ツールはバージョン管理システムと 連携可能 – 発生した問題と問題解決に要したファイル操作を連結 – 問題管理ツールからソースコードを確認 – バージョン管理システムの処理に応じたチケット処理 チケットの履歴 変更者 （IN [6] ） ダイアログにAを入力すると クラッシュする問題を修正（see #6) TracとRedmineの相違点 – Redmineは別サーバーにあるバージョン管理システ ムのリポジトリーを参照できるが、Tracは同一サー バーのみ – RedmineはSubversionをはじめ、MercurialやGitなど にも対応するが、TracはSubversion以外の管理ツー ルは別途Tracのプラグインが必要 チェンジセット 6 ログメッセージ ダイアログにAを入力すると クラッシュする問題を修正（see #6) com.ibm.main.Sample.java 4 public void config(){ 5 if (a!=0) { … TracやSubversionで管理しているチケットと Subversionのチェンジセット(変更記録）がリンクすることにより、 問題の解決に対し、どのファイルをどう変更したかがわかる 40 WAS V7 アプリケーション・デザインWorkshop Part2 問題管理ツールはバージョン管理システムと連携可能です。発生した問題と問題 解決に要したファイル操作を連結することで、発生した問題に対してどのファイルを どのように変更したのかがわかります。また、バージョン管理システムの処理に応じ たチケット処理を行い、バージョン管理システムへの変更を検知して、自動的にチ ケットの状態を変更させるといった使用方法も可能です。TracやRedmineは、とも にSubversionと連携することが可能です。連携することで、TracやRedmineのチ ケットとSubversionのチェンジセットがリンクされ、チケットからチェンジセットに記載 の変更箇所を確認することができます。 TracとRedmineはともにSubversionと連携可能ですが、相違点もあります。 Redmineは別サーバーにあるバージョン管理システムのリポジトリーを参照できま すが、Tracは同一サーバーのバージョン管理システムのリポジトリーしか参照する ことができず、別サーバーと連携させるにはそのための仕組みが必要です。また、 RedmineはSubversionをはじめ、MercurialやGitなどにも対応していますが、Trac はSubversion以外の管理ツールは別途Tracのプラグインが必要となります。 40 06. アプリケーション開発管理 アプリケーション開発とツールのまとめ 開発者 ビルド担当者 ソースコード管理 ・ IBM Rational ClearCase(CC) ・ Subversion / CVS 選択基準の目安は規模 監査やトラッキングが必要ならCC ビルド管理 ・ IBM Rational Build Forge プロセスの自動化を実現 Ant / Maven ビルドを実行するツール デプロイ担当者 ビルド記録 ear java 単体テスト jar 変更・問題管理 デプロイ記録 ・ IBM Rational ClearQuest(CQ) CCと連携し、変更依頼の状況をビジュアル表示 ・ Trac / redmine Subversionと連携 問題管理機能はredmineのほうが優れている コミュニケーションが重点ならTracも選択肢に ・ FindBugs / JUnit / ｊcoverage Eclipseプラグインとして使用可能 コード解析・テストコード作成支援・ コード網羅率を測定 41 テスト担当者 結合テスト ・ IBM Rational AppScan アプリの脆弱性チェック ・ IBM Rational Functional Tester スクリプトの作成より、 テストの自動化を実現 WAS V7 アプリケーション・デザインWorkshop Part2 この章では、ソースコード管理、ビルド管理、テストツール、問題管理の4点につい て、用いられるツールと判断の目安についてご紹介しました。上図はそのまとめに なります。 41 06. アプリケーション開発管理 IBM Rational Team Concertによるチーム開発 42 WAS V7 アプリケーション・デザインWorkshop Part2 42 06. アプリケーション開発管理 チーム開発の重要性 複数チームでの開発で発生しうる問題 – チーム内外への伝達の遅れ – 他チームに影響のある変更の伝達漏れ – プロジェクトの進捗把握が困難 進捗会議の フィードバック チーム開発に求められること – プロジェクト状況の正確な把握 – 複数チーム間での情報の共有 チーム間 調整 進捗/問題 の共有 メンバー リーダー 他チームの 作業状況確認/ 仕様すりあわせ 各チームで持っている情報の スムーズな連携 43 プロジェクトの進捗の明確な把握 WAS V7 アプリケーション・デザインWorkshop Part2 プロジェクトとして行う開発は複数のチーム、多数の人員が関わる作業です。プロ ジェクトの規模が大きくなるにつれ、チーム間の連携をいかにスムーズに取るかが プロジェクトを円滑に進める大きな鍵となります。チーム間の連携が不足すると、 チーム内外への伝達の遅れが生じます。他チームにも影響のある変更が生じた場 合は、伝達の遅れがプロジェクト全体の遅延の原因となることもあります。また、プロ ジェクトの規模が大きくなるにつれ、プロジェクトの進捗把握が困難になります。従 いまして、チーム開発には、プロジェクト状況の正確な把握と複数チーム間での情 報の共有が強く求められます。 43 06. アプリケーション開発管理 IBM Rational Team Concert (RTC) チームが自律的に働ける環境 – ワークアイテム管理を軸に、メンバー管理、計画管理、構成管理、ビルド 管理を統合したAll-in-One製品 – 分散開発におけるチーム・コラボレーションをサポート – オープン＆スケーラブルなJazzプラットフォーム上の製品 RTCクライアント Rational TeamConcert 開発者 RTCクライアント Web UIでの管理 RTCクライアント 設計 / 開発 / テスト 開発者 管理者/開発者/閲覧者 44 管理者 計画 / 割り振り WAS V7 アプリケーション・デザインWorkshop Part2 IBM Rational Team Concert（RTC）は、ワークアイテム管理を軸にメンバー管理、 計画管理、構成管理、ビルド管理を統合したAll-in-One製品です。RTCの特長は チームが自律的に働ける環境を目指して、分散開発におけるチーム・コラボレー ションに有用な機能が充実していることです。また、RTCのプラットフォームには、コ ラボレーション支援を目的としたプラットフォームであるJazzを採用しています。 RTCはサーバー・クライアント方式を採用しています。ワークアイテムやソースコー ドなど、プロジェクトの成果物や管理項目はサーバー上のリポジトリーに保存し、管 理者や開発者はサーバー上のリポジトリーにアクセスを行うことでプロジェクトの状 況を把握したり、ソースコードの変更を行います。開発者は各自の環境にRTCのク ライアントを導入する必要がありますが、プロジェクト全体の管理や状況把握は Webベースで行うことができます。また、RTCのクライアントはRADと連携することが 可能ですので、実際のWebアプリケーションの開発にはRTCクライアントと連携し たRADを用いるのが一般的です。 参考料金）「IBM Rational Team Concert Standard Edition Server Install with 3 Authorized Users License + SW Subscription & Support 12 Months (D041TLL) 」¥2,589,000https://www112.ibm.com/software/howtobuy/buyingtools/paexpress/Express?P0=E1&par t_number=D041TLL&catalogLocale=ja_JP&Locale=ja_JP&country=JPN&PT =html&S_TACT=none&S_CMP=none 44 06. アプリケーション開発管理 RTCによるチーム・コラボレーション RTCを利用した複数チーム間での情報連携 – 開発者は知りたいときに知りたい情報を得ることが可能。リーダーがその都度調 整をする必要はない – 複数チームで協力して進めている作業に変更があった場合、自動で通知 – 他チームのスケジュールやタスク、成果物を直接確認可能 チーム内外の スムーズな情報伝達 メンバー リーダー 他チームの開発者の 進捗や成果物を確認 メンバー リーダー 自分に影響のある作業に 対する変更を受信し、 変更の伝達漏れを防止 45 WAS V7 アプリケーション・デザインWorkshop Part2 RTCは、プロジェクト全体やメンバーの進捗把握など複数チーム間の情報連携をス ムーズに行うための機能が充実しています。RTCの導入により、開発者は知りたい ときに知りたい情報を得ることが可能になり、リーダーがその都度調整をする必要は なくなります。また複数チームで協力して進めている作業に変更があった場合、そ の変更を自動で通知したり、他チームのスケジュールやタスク、成果物を直接確認 することも可能ですので、他チームの情報でも容易に得ることができます。 45 06. アプリケーション開発管理 RTCによる成果物管理の仕組み ローカルスペース – 成果物を表示、変更するためのローカルの作業場所 リポジトリーワークスペース – 各メンバーが行った変更をRTCのサーバーに保管する場所 – ローカルからチェックインすると反映 ストリーム – メンバー全体で成果物を共用する場所 – 各メンバーがワークスペースで実行した変更内容を統合し、保管 個人用のワークスペースが、安 全に隔離され履歴管理される 開発＆テストが終わると、 チェックイン 誰かが提出すると、その情報が、 他のワークスペースに伝達され、 受け入れるかどうか確認できる ローカルスペース ローカルスペース チェックイン チェックイン チェックイン ワークスペース ワークスペース 提出 提出 ワークスペース 提出 ストリーム (チームスペース) メンバー間で共有する成果物 Rational Team Concert 46 WAS V7 アプリケーション・デザインWorkshop Part2 RTCによる成果物管理は上図のように、ローカルスペース、リポジトリーワークス ペース、ストリームの3階層構造をしています。ローカルスペースは成果物を表示、 変更するための開発者ローカルの作業場所です。リポジトリーワークスペースは、 各開発者が行った変更をRTCのサーバーに保管する場所であり、ローカルから チェックインすることでリポジトリーワークスペースに反映されます。個人のリポジト リーワークスペースの内容を、他者のリポジトリーワークスペースと連携することは可 能ですが、この時点ではまだメンバー全体で共有しているわけではありません。メン バー全体で成果物を共有する場所はストリームと呼ばれるチームスペースです。個 人のリポジトリーワークスペースの内容をストリームに提出することで、変更した内容 が統合され、チーム全体で共有可能な状態になります。 46 06. アプリケーション開発管理 RTCを利用したソースコード管理の流れ 変更セット – RTCの変更の基本単位 – ローカルで各自行った複数のファイルの変更は、1つの「変更セット」としてリポジト リーにチェックイン 変更反映の流れ ①開発者Aが ローカルスペースでコードを変更 開発者Ａ ローカルスペース ローカルスペース 自分の変更 開発者B 他者の変更 ②開発者Ａが 自分のワークスペースにチェックイン ⑥自動的に ローカルスペースにロード ワークスペース ワークスペース 変更セット ③変更した内容が自動で 「変更セット」として作成される 変更セット ⑤開発者Ｂは「受託」を選び、 自身のワークスペースにマージ ④開発者Ａがストリームに提出 ストリーム 変更セット 47 WAS V7 アプリケーション・デザインWorkshop Part2 RTCでは「変更セット」を変更の基本単位としています。ローカルで各自行った複 数ファイルの変更は、1つの変更セットとしてリポジトリーにチェックインされます。 開発者Aがローカルスペースでコードを変更し、自分のリポジトリーワークスペース にチェックインすると、ローカルスペースで行った変更の内容が、一つの変更セット として自動的にリポジトリーワークスペースに作成されます。その変更セットを開発 者Aがストリームに「提出」を実行することで、ストリーム上に反映されます。変更後 に開発者Bがアクセスすると、ストリームに変更があったことが通知されます。開発 者Bはその変更セットに対し「受託」を選択することで自身のリポジトリーワークス ペースに反映され、自動的にローカルスペースにもロードされます。 47 06. アプリケーション開発管理 RTCのソースコード管理画面 変更の前後を比較し、差分を確認 ソースファイルの変更履歴の表示 48 WAS V7 アプリケーション・デザインWorkshop Part2 RTCによるソースコード管理の一画面です。図のようにソースコードの変更前後の 差分を確認することもできますし、ソースファイルの変更履歴を表示させることも可 能です。 48 06. アプリケーション開発管理 RTCのビルド管理画面 プライベート・ビルド – 変更をストリームに提出する前にビルドを実施し、確認することが可能 ビルドと同時にスナップショットが作成 – ビルドによる問題解析に有用 公開された ビルドの情報 自身のビルド ビルドの履歴、 待ち状態のビルドを表示 49 アラート WAS V7 アプリケーション・デザインWorkshop Part2 RTCによるビルド管理の画面です。自身で行ったビルドの他、公開されているビル ドの情報、またビルドの履歴や待ち状態のビルドなどを一画面で表示させることが できます。 RTCでは、変更をストリームに提出する前にビルドを実施し、個人のワークスペース で結果を確認することが可能です。この機能をプライベート・ビルドと言います。ま た、ビルドと同時にスナップショットも作成されるため、ビルド時に発生した問題の解 析に有用な情報も合わせて取得できます。 49 06. アプリケーション開発管理 RADとRTCとの連携 RADで実装したソースコードをRTCの管理対象にすることも可能 RAD v8.0ではコード・カバレッジとビルドの連携が強化 – RTCの自動ビルドと連携し、RADのコード・カバレッジを呼び出して、結果をRTC で共有 カバレッジに関する 情報が表示 50 WAS V7 アプリケーション・デザインWorkshop Part2 RADで実装したソースコードをRTCの管理対象にすることも可能です。JavaEEア プリケーションの開発にはRADが用いられることが多いため、実際の開発にはRAD をRTCクライアントとして使用する方法が一般的です。 RAD v8の新機能として、コード・カバレッジとビルドの連携が強化されたことが挙げ られます。RTCの自動ビルドとRADが連携し、RAD上で行ったテストに対しコード・ カバレッジを呼び出して、結果をRTCで共有させることも可能になりました。 RAD v8の新機能に関しては以下の資料をご覧下さい。 参考資料）RSA/RAD V8.0 アナウンスメント・ワークショップ資料 http://www.ibm.com/developerworks/jp/rational/library/am/cms/rsdp/rsa/rsara dv8_intro/ 50 06. アプリケーション開発管理 RTCと他製品の比較 典型的な利用例 Web View 問題管理ツール. RTCを使うと？ Eclipse View ビルド管理 ツール 構成管理ツール 課題 価値 9シングルリポジトリで管理コストを削減 9プロジェクト、チーム、ユーザが明確に管理できる 9チーム間のメンバー移動時のセットアップコストが非常に低 く、流動的にチームを編成可能 9コンテクストベースのコラボレーション機能 9プロセス管理可能なツール 9JUnitテスティングを統合 9ダッシュボードを通じてプロジェクトをリアルタイムに見える 化 9ソースコントロール、ワークアイテム、ビルドが密に連携 別々のデータベースの管理コスト 将来的に個々のツールのロードマップが見えない ツール連携全体のサポートが存在しないリスク クライアントインテグレーションが乏しく、目に見えな いコスト 新メンバーを入れる際、チーム移動の際のセットアッ プコストの高さ プロジェクトステータスに対する統合されたビューが ない ソースコントロール、課題トラッキング、ビルドが有機 的に連携していない 51 WAS V7 アプリケーション・デザインWorkshop Part2 RTCの一番のメリットは問題管理やビルド管理、構成管理といったプロジェクトで必 要な管理項目を全て一括したリポジトリーで行えることです。各ツールは連携させて 使用することも可能ですが、製品としては別であるため、導入や保守も各ツールで 別途行う必要があり、連携のためのコストも必要になります。RTCはそれら複数の管 理を一つの製品としてカバーしているため、連携させるための処理は必要なく、管 理コストを削減することが可能です。また、豊富なダッシュボードやチーム間のコラ ボレーションに便利な機能を兼ね備えていたり、RTCならではの機能も有していま す。 51 06. アプリケーション開発管理 RTCと問題管理、ビルド管理ツールとの関連 RTCは構成管理、ビルド管理、ワークアイテム管理（問題・変更管理）に加え、チーム 開発に有用な機能を持つ – 豊富なダッシュボードによるプロジェクトの見える化 – フィード等によるチームの作業状況把握やチャットなど、コミュニケーションに便利な機能 プロセス 自動化 開発 ビルド担当者 開発者 IBM Rational Application Developer デプロイ担当者 IBM Rational Build Forge / Ant / Maven 構成管理 ビルド記録 構成管理 変更管理 ear デプロイ記録 jar java IBM Rational ClearCase / Subversion / CVS Rational Team Concert IBM Rational ClearQuest / Trac / Redmine 結合テスト テスト自動化 単体テスト 単体テスト 52 テスト担当者 セキュリティー評価 WAS V7 アプリケーション・デザインWorkshop Part2 RTCは構成管理、ビルド管理、ワークアイテム管理（問題・変更管理）に加え、チー ム開発に有用な機能を持っています。豊富なダッシュボードによるプロジェクトの見 える化、フィードなどによるチームの作業状況把握やメンバー間のチャット機能など は、チーム開発の際に非常に有用と言えるでしょう。 RTCで管理可能な内容をアプリケーション開発とツール（p.11）の図に照らし合わ せた図が上になります。RTCは構成管理、ビルド管理、ワークアイテム管理をカ バーしていますので、この3つをオープンソースフレームワークの連携で行うために は、SubversionとTrac/Redmine、Mavenなどのビルドツールの連携。Rational製 品では、Rational ClearCase、Rational ClearQuest、Rational Build Forgeの連 携が必要になります。 52 06. アプリケーション開発管理 RTCと問題管理、ビルド管理ツールとの関連 RTCはソース管理、変更管理、ビルド管理の機能を持つがClearCase(CC)、 ClearQuest(CQ)、Build Forgeの機能を包含してるわけではない – CC/CQを既に使用している環境にRTCを連携させることは可能 CCのソース管理、CQの変更管理 – 高度なカスタマイズ – CCとCQの連携実績 RTCのソース管理、変更管理 – 特別な設定をすることなくソース管理、変更管理の連携が可能 – 連携にかかるコストを削減 Build ForgeはRTCにはない機能も存在 – 分散環境におけるマルチ・プラットフォームのビルドをサポート – スレッド化技術によるビルド時間の短縮 53 WAS V7 アプリケーション・デザインWorkshop Part2 RTCはソース管理、変更管理、ビルド管理の機能を保有しています。ただし Rational ClearCaseやClearQuest、Build Forgeを内部で使用しているわけでは なく、それらの機能を包含しているわけではありません。ただし、 ClearCaseや ClearQuestをすでに使用している環境が存在している場合、RTCと連携させ、 ClearCaseやClearQuestのソース管理や変更管理をRTCのワークアイテムと連携 させることも可能です。 ClearCase、ClearQuestによる管理の特長は高度なカスタマイズ、RTCの管理の 特長は連携にあります。RTCは他のツールを用いなくてもそれぞれの管理を行うこ とができ、連携のコストを削減できるのが大きなメリットですので、RTCを新規導入さ れる際には他のツールとの連携をあまり気にする必要はありません。すでに ClearCaseとClearQuestで管理を行っている場合は、RTC導入後もそれらを用い るという選択肢もあります。 Build ForgeはRTCにはない機能として、分散環境でのマルチ・プラットフォームの ビルドのサポートや、スレッド化技術によるビルド時間の短縮といった機能がありま す。これらの機能をRTC導入後も使用したい場合は、Build Forgeと併用し、ビルド 結果をRTCと連携させるといった使用方法も考えられます。 53 06. アプリケーション開発管理 デプロイ後のモジュール管理 54 WAS V7 アプリケーション・デザインWorkshop Part2 54 218. アプリケーション更新／バージョニングに関する検討 06. アプリケーション開発管理 アプリケーションの運用における考慮点 サービス継続に対する影響 – システム無停止での実施 or 停止時間内に実施 切り替え、切り戻しの容易性 – アプリケーションのバージョン管理 切り替え時間の最小化 – 切り替えの粒度 55 WAS V7 アプリケーション・デザインWorkshop Part2 この章では、アプリケーションをデプロイした後の、アプリケーション更新に関する運 用の考慮点について紹介致します。 考慮点として、ここでは、更新時のサービス継続に対する影響、切り替えと切り戻し の容易性、切り替え時間の最小化の3つについて紹介します。 55 06. アプリケーション開発管理 アプリケーションの更新 アプリケーションの更新を反映するにはクラス・ローダーがクラスを再ロード する必要 AS アプリケーションの再起動 – 変更したクラスが再ロードされ、 変更がサーバーに反映 – アプリケーション停止中は 全ての処理が停止 – プラグインは割り振りを実行 App アプリの停止中はアクセス不可 AS App 運用にて対応 – システムの停止時間を設定 • その間にアプリケーションを更新 – システム無停止での対応 • クラスター構成を用意し、 順次アプリケーション・サーバーを再起動 • プラグインは停止した アプリケーション・サーバーには割り振りを実行しない 56 アプリの停止中はアクセスさせず、 別のサーバーへ WAS V7 アプリケーション・デザインWorkshop Part2 アプリケーションの更新を行う際、更新をアプリケーション・サーバーに反映させる ためには、クラス・ローダーがクラスを再ロードする必要があります。クラスを再ロード させる最も単純な方法はアプリケーションを再起動させることですが、アプリケーショ ンの停止は、そのアプリケーションによるサービスが全て停止してしまうため、再起 動中はシステム全面ダウンとなります。しかもアプリケーション・サーバー自体は起 動しているため、プラグインは割り振りを実行してしまいます。その対処としてホット・ デプロイや動的再ロード機能もありますが、設定ファイルの変更を伴うような変更な ど、どのような変更にも対処できるわけではありません。 実際には、このようなアプリケーションの更新は運用でカバーするケースが大半で す。例えば、システムの停止時間をあらかじめ決めておき、その間で更新を行うの も一つの方法ですし、システム無停止が要件であれば、クラスター構成を用意し、 順次アプリケーション・サーバーを再起動させるのも一つの方法です。プラグインは 停止したアプリケーション・サーバーには割り振りを行わないので、順次アプリケー ション・サーバーを再起動することで、プラグインも起動中のアプリケーション・サー バーに順次割り振りを行い、システムを継続させることが可能です。 56 06. アプリケーション開発管理 サービス継続に対する影響 アプリケーション・サーバーの停止中は、アプリケーションが処理 できないため、その間の考慮が必要 – サービス停止時間を設け、その期間はリクエストを全てSorryサーバーに 負荷分散サーバー マシン1 AS1 IHS Dispatcher マシン2 AS2 IHS Sorryサーバー IHS – サービスが停止しないように、停止の方法を運用で対処 • 案① WAS NDのロールアウト • 案② WVEのロールアウト 57 WAS V7 アプリケーション・デザインWorkshop Part2 アプリケーション・サーバーの停止中は、当然そのアプリケーション･サーバーはリク エストを処理できません。そのため、更新に伴うアプリケーション・サーバーの停止 はサービスの停止時間を考慮する必要があります。 サービスに停止時間を設けることが可能な場合は、負荷分散サーバーにより停止 時間は全てのリクエストをSorryサーバーに割り振り、その間にアプリケーションの再 起動を行うという運用が一般的です。しかしサービスの停止が認められない場合は、 クラスター構成を構築し、別のクラスター・メンバーにリクエストを割り振ってる間に、 アプリケーションではなくアプリケーション・サーバーを順次停止するという運用を行 う必要があります。その対処法として「ロールアウト」があります。同じロールアウトで も、WAS NDのロールアウトとWVEのロールアウトは異なった性質を持っています。 57 06. アプリケーション開発管理 案① WAS NDのロールアウト クラスターにデプロイされたアプリケーションを更新・再起動する際、ノードごとに順番に 反映 複数ノードのうち、いずれかは常に稼働しているため、サービス全体としては無停止で 更新が可能 考慮点 – 起動停止はノード単位であるため、垂直クラスターの場合は有効ではない – 3台以上のノード構成の場合、新旧バージョンの混在する時間帯が存在 本番用クラスター マシン1 ② 反映 ③ 完了 App WAS管理ツール ①更新 58 AS App AS App ④ 反映 ⑤ 完了 マシン2 ⑥ 反映 ⑦ 完了 マシン３ AS App AS App WAS V7 アプリケーション・デザインWorkshop Part2 ロールアウトとは、クラスター・メンバーに対しノード毎に順番に再起動を行う機能で す。アプリケーション・サーバーの再起動によりアプリケーションの更新は反映され ますが、複数ノードのうち、いずれかは常に稼働しているため、サービス全体として は無停止で更新を行うことが可能です。 ロールアウトによるアプリケーションの更新はWAS NDで利用できますが、起動停 止はノード単位であるため、一つの筐体に複数のクラスター・メンバーが存在する 垂直クラスターの場合は有効ではありません。また、3台以上のノード構成の場合、 2台目の再起動中は1台目の更新は終了し、3台目の更新は実施されていないた め、新旧バージョンが混在することになります。そのため、この時点で届いたリクエ ストが新しい機能が使えるかどうかは、どちらのサーバーに割り振られるかによって 決まります。 58 06. アプリケーション開発管理 案② WVEのロールアウト ＷＶＥのロールアウト – グループ・ロールアウト • 指定したサーバー数ずつ更新 – アトミック・ロールアウト • クラスター・メンバー全体を2つに分け、順次更新を実施 • 垂直クラスターにも有効、混在する時間帯も存在しない アトミックロールアウトの更新フロー 更新前 更新中 59 更新完了 全サーバ Edition2に 更新完了 全アクセスが Edition2 STOP 全アクセス がEdition1 へ STOP 更新開始 更新中 WAS V7 アプリケーション・デザインWorkshop Part2 WebSphere Virtual Enterprise（WVE）にはNDのロールアウトに加え、独自のロー ルアウトが存在します。アプリケーション・サーバーの再起動を指定したサーバーず つ行うグループ・ロールアウトと、クラスター・メンバー全体を2つに分けて順次更新 を行うアトミック・ロールアウトの2つです。このうちアトミック・ロールアウトは垂直クラ スターにも有効であり、2つに分けて行うため、新旧バージョンが混在する時間帯は 存在しません。従いまして、WAS NDのロールアウトで考慮しなければいけない、 垂直クラスターの課題と新旧バージョン混在の課題が大きな影響を与える場合に は、WVEのアトミック・ロールアウトが有効です。 59 06. アプリケーション開発管理 切り替え、切り戻しの容易性 アプリケーションの切り替え、切り戻しは、アプリケーションの削除と再導入に より実施 アプリケーションのバージョン管理は、WASに別途バージョン管理ツールが必 要 バージョン管理サーバー App V1.0 バージョン管理ツールがアプリケーションを バージョン管理し、DMノードに配置する必要 App V1.1 反映 DMノードにアプリを配置 WAS管理ツール 更新の指示 マシン AS DMノード App V1.1 反映 App V1.1 マシン AS App V1.1 考慮点 – 前バージョンの情報はWASには残らない – 別途バージョン管理ツールから前バージョンのアプリケーションを配置する必要 60 WAS V7 アプリケーション・デザインWorkshop Part2 アプリケーションの切り替えや切り戻しは通常、アプリケーションの削除と再導入に より行われます。しかし、WASはアプリケーションをバージョン管理する機能は持っ ていませんので、アプリケーションのバージョン管理は、別途バージョン管理ツール を用意し、DMノードに適切なバージョンのアプリケーションを配置し、WAS管理 ツールを用いてデプロイを行う必要があります。 アプリケーションを更新した際、WASは以前のバージョンのアプリケーションの情報 を残せません。そのため、アプリケーション更新後に以前のバージョンに切り戻しを 行いたい場合は、バージョン管理ツールから前バージョンのアプリケーションを再 度配置し、再度デプロイを行わなければなりません。 60 06. アプリケーション開発管理 WASで行うアプリケーションのバージョン管理 WVE、OSGiの機能としてアプリケーションやモジュールのバージョン管理を 実施 削除・再導入ではなく、バージョンの切り替えで対応 アプリケーション単位のバージョニング – WVEによるアプリケーションのエディション・コントロール – HTTPレベルのディスパッチ 部分的なモジュール単位のバージョニング – OSGi FPを用いたバンドルのバージョン管理 – Javaクラスレベルのディスパッチ 61 WAS V7 アプリケーション・デザインWorkshop Part2 このような考慮点に対しては、WVEやOSGiのバージョン管理機能が有効です。 WVEはアプリケーションをエディションとして管理する機能を有しています。また OSGiはバンドルと呼ばれるモジュールをバージョニングする機能を持ち、OSGi FPを導入することでWAS上でもOSGiが扱えるようになります。これらのバージョニ ングにより、アプリケーションの更新を削除、再導入ではなく、切り替えによって対応 することが可能です。 WVEのバージョニングとOSGiのバージョニングにはバージョン管理可能な単位に 違いがあります。WVEはアプリケーションをエディションとして制御できますので、ア プリケーション単位の更新に有効であり、HTTPレベルでディスパッチを行うことが できます。それに対しOSGiはバンドルと呼ばれるJavaモジュール単位でバージョ ニングを行いますので、Javaクラスレベルでディスパッチを行います。 61 06. アプリケーション開発管理 アプリケーション単位のバージョニング WVEによるアプリケーションのエディション・コントロール – アプリケーションに「エディション」付けが可能 – 同一アプリケーションを異なるエディションで導入し、共存が可能 • 別途アプリケーション・サーバーを用意する必要（自動作成も可能） – オン・デマンド・ルーターによる割り振り バージョンが異なる 同一アプリケーションが マシンに共存 本番用クラスター マシン1 マシン２ ルールに応じて ODRが割り振り マシン３ 62 AS AS AS App V1 App V1 App V1 検証用クラスター AS AS AS App V2 App V2 App V2 WAS V7 アプリケーション・デザインWorkshop Part2 WVEはアプリケーションに対しエディション付けを行います。アプリケーションに付 けられたエディションにより、同じアプリケーションでもエディションの違いにより区別 することが可能です。エディションを利用すると、同一アプリケーションを異なるエ ディションで導入し、それらを共存させることも可能です。ただし同一のアプリケー ション・サーバーで起動させることはできませんので、別途アプリケーション・サー バーを用意する必要があります。なお別途アプリケーション・サーバーをWVEに自 動で生成させることもできます。 エディション別のアプリケーションは、定められたルールに応じてオン・デマンド・ ルーターが割り振りを行います。そのため、新バージョンへの切り替えはオン・デマ ンド・ルーターが割り振りのみで制御でき、全エディションのアプリケーションに戻し たい時も、割り振りを制御するだけで対応可能です。 62 06. アプリケーション開発管理 部分的なモジュール単位のバージョニング OSGiのバンドルによるバージョニングを利用 OSGiとは – アプリケーションのライフサイクルの管理を行うためのJavaの仕様 – OSGiでは、アプリケーションを「バンドル」と定義 • メタデータが記載されたマニフェストファイルをもったJarファイル • OSGiフレームワークの上で動作 Bundle Bundle Bundle OSGi Framework Java VM WAS V7 Feature Pack for OSGi application and JPA 2.0 – OSGiのアプリケーションをWebアプリケーションとしてWAS上で動作可能 – WAS NDに追加で導入 63 WAS V7 アプリケーション・デザインWorkshop Part2 部分的なモジュール単位での更新には、OSGiのバンドルによるバージョニングが 有効です。OSGiとは、アプリケーションのライフサイクルの管理を行うためのJava の仕様であり、アプリケーションを「バンドル」と定義しています。バンドルの正体はメ タデータが記載されたマニフェストファイルをもったJarファイルであり、 OSGiフレー ムワークの上で動作し、インストール・アンインストールもバンドルの単位で行われま す。 2010年5月、新たなFeature PackとしてWAS V7 Feature Pack for OSGi application and JPA 2.0がリリースされました。これはOSGiのアプリケーションを WebアプリケーションとしてWAS上で動作することを可能としたもので、WAS NDに 対し追加で導入することで、OSGiに対応したWebアプリケーションがWAS ND上 で動作できるようになります。 63 06. アプリケーション開発管理 OSGi FPを用いたバンドルのバージョン管理 OSGiバンドルを用いたバージョン管理 – バンドルはバージョニングが可能 – OSGiリポジトリーによりバンドルは一括管理され、複数バージョンの同名 バンドルの存在も可能 – OSGi対応のWebアプリケーションの管理画面 • 特別なツールを別途用意しなくても、WASの管理ツールからバンドルのバー ジョン変更と管理が実施可能 アプリケーションに内包された、 各バンドルの名前とバージョンが表示 アプリ外に登録された共有バンドルを 使用している場合、 そのバンドル、バージョンも表示 64 WAS V7 アプリケーション・デザインWorkshop Part2 OSGiのバンドルは、WVEのアプリケーションのエディション同様にバージョニング が可能です。OSGiは固有のOSGiリポジトリーを持ち、バンドルはそのOSGiリポジ トリーで一括管理されます。複数バージョンの同名バンドルもリポジトリーで扱うこと が可能であるため、アプリケーションで複数バージョンの同名バンドルを使い分ける こともできます。 OSGi対応のWebアプリケーションを導入し、WASの管理コンソールで見た画面が 上図になります。上図では、アプリケーションに内包されたバンドルの名前とデプロ イ済みのバージョンが表示されています。また、アプリケーション外に登録された共 有バンドルをアプリケーションから使用している場合でも、そのバンドルとバージョン が表示されています。OSGi対応のWebアプリケーションの特長は、このように特別 なツールを別途用いなくても、WASの管理コンソールからバージョン変更と管理が 行えることです。 64 06. アプリケーション開発管理 OSGi FPを用いたバンドルのバージョン管理 バンドルの更新は、管理画面からバージョンを切り替えることで実行 – WASの内部リポジトリーに新バージョンのバンドルを追加 – アプリケーションのバンドル管理画面から新バージョンのバンドルを選択、コミット – ロールアウトによる順次再起動 – 前バージョンのバンドルは削除されずに保管されているため、切り戻しも切り替えで実行 65 WAS V7 アプリケーション・デザインWorkshop Part2 OSGiバンドルの切り替えは、管理画面からバージョンを切り替えることで実行しま す。 まずWASの内部リポジトリーに新バージョンのバンドルを新規追加します。追加す ると、先程のアプリケーションのバンドル管理画面の右にあるバージョンの選択箇 所から追加したバンドルのバージョンが選択できるようになりますので、新規バー ジョンを選択し、コミットを実行します。最後にWAS NDのロールアウト機能を用い て順次再起動を行い、変更を反映させます。再起動は必要となりますが、前バー ジョンのバンドルは削除されずに保管されてますので、切り戻しを行いたい場合で も、WAS管理ツールから適切なバージョンを選択し、再起動することで変更を反映 させられる点が、バンドルによる更新の大きな特長です。 OSGiの詳細については、以下の資料も合わせてご覧下さい。 参考資料）WAS v7 InfomationCenter Feature Pack for OSGi Applications and JPA 2.0 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.jp afep.multiplatform.doc/info/ae/ae/welcome_fepjpa.html WebSphere Application Server 技術文書 エンタープライズOSGi入門 http://www.ibm.com/developerworks/jp/websphere/library/was/was7_fep_osgi/1.html developerWorks:Developing enterprise OSGi applications for WebSphere Application Server http://www.ibm.com/developerworks/websphere/techjournal/1007_robinson/1007_robinson.h tml?ca=drsdeveloperWorks:Best practices for developing and working with OSGi applications http://www.ibm.com/developerworks/websphere/techjournal/1007_charters/1007_charters.ht ml?ca=drs- 65 06. アプリケーション開発管理 切り替え時間の最小化 通常の更新はアプリケーション単位 – アプリケーション（earファイル）はサイズが大きく なりがち – 更新にかかる時間も増加 Application.ear EJBModule.jar アプリケーション単位よりも小さな範囲での更新 – 切り替えにかかる時間を小さく WebModule.war FileA FileC FileB – アプリケーションのファイル単位での更新 • WAS NDによるFine-Grained アップデート – OSGi FP環境であれば、バンドル（jarファイル）単 位での更新も切り替え時間短縮の効果 – WVEはエディションはアプリケーション単位であ るため、更新はアプリケーション単位を想定 – Fine-Grained アップデートを使うことも可能だが、 エディション管理にWVEは使用できない 66 FileD アプリケーション全体よりも 小さい単位で更新することで、 更新時間を削減 WAS V7 アプリケーション・デザインWorkshop Part2 通常、アプリケーションの更新はearファイルの単位で実行されます。大規模なアプ リケーションではearファイルも大きくなりますので、アプリケーション全体の更新を 実行すると、earファイルのサイズが大きくなるにつれ、更新にかかる時間も増加す ることになります。 そのような懸念がある場合は、アプリケーション単位ではなく、より小さな範囲で更 新を行うことで、切り替えにかかる時間を抑えることが可能です。対応策としては、 WAS NDによるFine-Grained アップデートを用いる方法が考えられます。また、 OSGi FP環境上であれば、バンドル（jarファイル）単位での更新も切り替えにかか る時間を抑える効果があります。なお、WVEはエディションをアプリケーション単位 で付けるため、更新はアプリケーション単位を想定しています。別途Fine-Grained アップデートを使うことも可能ですが、その場合WVEのエディション管理は用いるこ とができません。 66 06. アプリケーション開発管理 単一ファイル単位での更新 Fine-Grainedアップデート – アプリケーションの部分的な追加・更新・削除 管理コンソール A. 全アプリケーション 更新(A) Application.ear EJBModule.jar 更新(B) WebModule.war B. 単一モジュール 更新(C) C. 単一ファイル 更新(D) FileA FileB FileC D. アプリケーションの一部 67 WAS V7 アプリケーション・デザインWorkshop Part2 WAS NDのFine-Grainedアップデートは、アプリケーションの部分的な追加・更新・ 削除を行う機能です。更新の範囲はアプリケーション全体だけではなく、モジュー ル単位、ファイル単位、またはアプリケーションの一部を指定して更新することが可 能です。 67 06. アプリケーション開発管理 バンドル（jarファイル）単位での更新 OSGi FPを用いたバンドル単位での更新 – アプリケーション外部の共有ライブラリーの変更にも対応 Application.eba BundleA.jar 更新(A) BundleB.jar A. アプリケーション内のバンドル BundleC.jar BundleD.jar B. アプリケーション外部の 共有ライブラリーのバンドル サーバー内のOSGiレポジトリー 更新(B) BundleE.jar 68 WAS V7 アプリケーション・デザインWorkshop Part2 OSGiのバンドルもWASの管理画面からバージョンを切り替えることで対応できます。 また、OSGi対応のWebアプリケーションは、アプリケーション外部に登録された共 有ライブラリーのバンドルの変更にも対応できる点が大きな特長です。 68 06. アプリケーション開発管理 アプリケーション運用における考慮点のまとめ サービス継続に対する影響 – システム無停止での更新が必要か • 必要な場合は、WAS NDのロールアウト • 垂直クラスター、新旧バージョンの考慮が必要な場合は、WVEのアトミック・ ロールアウトが有効 切り替え、切り戻しの容易性 – バージョン管理ツールによる管理が別途必要か • WASで行えるバージョン管理には、WVEかOSGi FPの機能が有効 • 切り替え対象がアプリケーション単位かJavaクラス単位かで判断 切り替え時間の最小化 – アプリケーション単位より詳細な単位での更新が必要か • アプリケーション単位より詳細な単位には、WAS NDのFine-Grainedアップ デート、OSGi FPのバンドル更新が有効 69 WAS V7 アプリケーション・デザインWorkshop Part2 この章では、更新時のサービス継続に対する影響、切り替えと切り戻しの容易性、 切り替え時間の最小化の3つの運用上の考慮点についてご紹介しました。それらを まとめると上記のようになります。 69 06. アプリケーション開発管理 まとめ 70 WAS V7 アプリケーション・デザインWorkshop Part2 70 06. アプリケーション開発管理 まとめ 1. アプリケーション開発管理の機能要件 – 2. アプリケーション開発の各フローにおける発生しうる問題、決定すべき事項と決定フェーズ アプリケーション開発におけるツールの選択指針 – ソースコード管理 – ビルド管理 – テスト – 問題管理 • • • • 3. FindBugs / JUnit / jcoverage / IBM Rational AppScan / IBM Rational Functional Tester IBM Rational ClearQuest / Trac / Redmine RTCは構成管理、ビルド管理、ワークアイテム管理に加え、チーム開発に有用な機能を保有 それらの管理を一括させることで、導入や設定のコストを削減 デプロイ後のモジュール管理 – サービス継続に対する影響 – 切り替え、切り戻しの容易性 – 切り替え時間の最小化 • • • 71 IBM Rational BuildForge / Ant / Maven IBM Rational Team Concertによるチーム開発 – – 4. Subversion / IBM Rational ClearCase システム停止時間内での更新 / WAS NDのロールアウト / WVEのアトミック・ロールアウト WVE（アプリケーション単位） / FP for OSGi(モジュール単位)の切り替えによる対応 WAS NDのFine-Grainedアップデート / OSGi FPのバンドル更新 WAS V7 アプリケーション・デザインWorkshop Part2 当セッションで紹介しました内容のまとめになります。 71 06. アプリケーション開発管理 参考文献 Rational製品 – IBM Support Portal －Rational brand support • http://www947.ibm.com/support/entry/portal/Overview/Software/Rational/Rational_brand_support_%28general%29 – developerWorks ： Rational • http://www.ibm.com/developerworks/jp/rational/ – Rationalツール ここからはじめよう！シリーズ • http://www.ibm.com/developerworks/jp/rational/library/cms/start/ WebSphere製品 – IBM Support Portal －WebSphere Application Server • http://www947.ibm.com/support/entry/portal/Overview/Software/WebSphere/WebSphere_Application_Server – WAS v7 Feature Pack for OSGi Applications and JPA 2.0 • http://www-01.ibm.com/software/webservers/appserv/was/featurepacks/osgi/index.html オープンソースソフトウェア – 各公式サイト • • • • • • • • • 72 http://subversion.apache.org/ http://ant.apache.org/ http://maven.apache.org/ http://cruisecontrol.sourceforge.net/ http://findbugs.sourceforge.net/ http://www.junit.org/ http://www.jcoverage.com/ http://trac.edgewall.org/ http://www.redmine.org/ WAS V7 アプリケーション・デザインWorkshop Part2 72