| Oracle® Fusion Middleware継続的統合によるアプリケーションの開発 12c (12.2.1.1) E77233-01 |
|
 前 |
 次 |
Oracle Fusion Middleware 12cでは、ビルド自動化および継続的インテグレーションの新機能を導入しています。継続的インテグレーションは、旅程と目的地の両方を意味します。前もってビルド・プロセスを自動化していない場合、旅程は始まったばかりです。この章では、継続的インテグレーションの達成に必要なステップの理解に役立つロードマップを提供します。
ビルド自動化および継続的インテグレーションをすでに理解している場合、この章は、Oracle Fusion Middleware 12cで提供される機能のまとめとなり、自分の経験に関連付けるのに役立ちます。
この章では、継続的インテグレーション環境参照についても説明します。これは、このガイドで説明している継続的インテグレーション・アプローチ、ツールおよび技術の採用後に環境がどのようになるかを視覚化するための例として提供されます。
この章のトピックは、次のとおりです:
表2-1では、継続的インテグレーションを実装するために実行する必要がある一般的ステップについて説明し、各ステップの詳細情報の参照先も示します。
表2-1 継続的インテグレーションを達成するためのロードマップ
| 手順 | 作業 | 詳細情報 |
|---|---|---|
|
1. |
バージョン・コントロール計画の実装 |
第3章では、Subversionを使用してバージョン・コントロール環境を設定する方法について説明します。 開発環境でバージョン・コントロールを現在使用していない場合は、第3章で説明しているリポジトリ・レイアウト、Subversionワークフロー、およびタグ付けと分岐に特に注意します。 Subversionを使用したバージョン・コントロールの詳細は、次を参照してください。 |
|
2. |
バイナリ・リポジトリ計画の実装 |
第4章では、Apache Archivaを使用してバイナリ・アーティファクト(自分がビルドするアーティファクト、およびビルドが依存しているアーティファクトの両方)用のリポジトリを設定する方法について説明します。複数のリポジトリの必要性の理解、スナップショットと他のリポジトリとの間の相違の理解、およびリポジトリに必要な管理とメンテナンスに特に注意します。 |
|
3. |
ビルド自動化および依存性管理計画の実装 |
第5章では、Mavenおよびインストールと構成ステップについて簡単に説明します。これまでMavenを使用したことがない場合は、Mavenを理解するためにその資料を参照してください。次の公式Maven Webサイトにある「What is Maven?」をまず読んでください。
次を含む多数のリソースをオンラインで使用することもできます。
これらのリソースは、Mavenの使用方法、その設計の背後にある原理の一部、およびMavenを使用してどのような種類の作業を実行できるかについて包括的理解を形成するのに役立ちます。 |
|
4. |
リポジトリへのOracleアーティファクトの移入 |
5.3項では、MavenリポジトリにOracle提供アーティファクトを移入する方法について説明します。Oracle Maven同期プラグイン、Oracleランタイム環境にパッチを適用した場合の影響、ビルド環境でパッチを実行する意味、および原型の役割を理解することに特に注意します。 |
|
5. |
Mavenバージョン番号を理解していることを確認 |
第8章では、Mavenバージョン番号の重要な意味合いについて説明します。Mavenバージョン番号の使用方法、依存性を指定するためのバージョン番号範囲、およびバージョン番号の指定方法に基づいてMavenで依存性を解決する方法について理解していることを確認してください。 |
|
6. |
Mavenを使用してWebLogic Server用のJava EEアプリケーションをビルドする方法の学習 |
第10章では、Oracle WebLogic Maven原型を使用してJava EEアプリケーションを作成する方法、およびアプリケーションをコンパイル、パッケージ化して、WebLogic Serverにデプロイする方法について説明します。 |
|
7. |
Mavenを使用してCoherenceアプリケーションをビルドする方法の学習 |
第11章では、Oracle Coherence Maven原型を使用してCoherence GARアプリケーションを作成する方法、およびアプリケーションをコンパイル、パッケージ化して、WebLogic Server上のCoherenceコンテナにデプロイする方法について説明します。 |
|
8. |
Mavenを使用してその他のタイプのアプリケーションをビルドする方法の学習 |
Mavenを使用してその他のタイプのアプリケーションをビルドする方法の詳細は、次を参照してください。 |
|
9. |
Mavenを使用してアプリケーション全体をビルドする方法の学習 |
第15章では、これらの多くの概念をまとめてより現実的なアプリケーションをビルドする方法について説明します。アプリケーション例には複数のコンポーネント部品が含まれ、それぞれが異なるOracle Fusion Middlewareランタイム環境を対象としています。コンポーネント間の依存性、およびカスタム・パッケージ化要件もあります。 |
|
10. |
Maven POM継承を使用してビルド・プロセスをカスタマイズする方法の学習 |
第9章では、Oracle Fusion Middleware 12cに含まれるMaven POM階層について説明します。一般的なOracleの親POMでは、ビルド・システムを簡単にカスタマイズする方法が提供されます。 |
|
11. |
継続的インテグレーション計画の実装 |
第7章では、継続的インテグレーションを実行する環境を作成するようにHudsonを設定する方法について説明します。第16章では、継続的インテグレーション環境を確立および運用するための重要な考慮事項の詳細について説明します。 |
この章では、Subversion、Maven、HudsonおよびArchivaに基づいた継続的インテグレーション環境の参照実装について説明します。
図2-1に、推奨される開発環境の概要を示します。
次に、環境の説明を示します。
Mavenの中央リポジトリおよびOracle Mavenリポジトリ: これらは、ビルドに必要となる場合があるオープン・ソースおよびOracle依存性を保持する外部Mavenリポジトリです。Mavenリポジトリ・マネージャは、独自のリポジトリに存在しない依存性をこれらのリポジトリ内で検索し、使用可能な場合はその依存性を取得できます。
Mavenリポジトリ・マネージャ: ビルドされたすべてのアーティファクトと依存性(自分の環境で作成された場合とソースが外部である場合の両方)用のリポジトリ。通常は、次のように目的に応じて異なるリポジトリが存在します。
バイナリ・リポジトリ・マネージャは、外部Mavenリポジトリ(Mavenの中央リポジトリおよびOracle Mavenリポジトリなど)のミラーまたはプロキシとして機能します。これらのリポジトリからのアーティファクトがビルドに必要な場合は、ダウンロードされ、Mavenリポジトリ・マネージャによって管理されているリポジトリに格納されます。
アーティファクト(WAR、JAR、SARファイルなど)をビルドすると、Mavenリポジトリ・マネージャによって管理されるリポジトリに公開されます。多くの場合、SNAPSHOT(作業中)アーティファクト用およびリリース(最終)アーティファクト用に個別のリポジトリがあります。
Subversionサーバー: 開発者が作成したソース・アーティファクトのリポジトリです。通常は、複数のリポジトリがあります。たとえば、プロジェクトごとに1つ存在する場合があります。
Hudson継続的インテグレーション(マスター)サーバー: 継続的インテグレーション・ビルドを管理するサーバーです。ビルドの実行、およびこれらのビルドの結果の収集とレポートを担当します。
Hudsonスレーブ・サーバー: 追加機能を提供するために使用される、オプションの追加Hudsonサーバーです。多数のビルドを実行する場合、一部のビルドを共有または実行するように複数のHudsonスレーブ・サーバーを設定できます。
ファイル・サーバー: Hudsonビルド・サーバーで必要となる製品バイナリのコピーをホストする、ストレージ・エリア・ネットワーク(SAN)やネットワーク・アタッチ・ストレージ(NAS)などです。たとえば、Oracle ADFアプリケーションをビルドするにはojdeployが必要です。すべてのHudsonサーバーが、このファイル・サーバーにアクセスできます。
テスト・サーバー(図示されていません): 統合テストを実行する場合は、WAR、JAR、SARなどのビルド済アーティファクトをデプロイし、統合テストを実行する一連のテスト・サーバーも存在する場合があります。
開発者のマシン: 各開発者はワークステーションを保有し、そこで統合開発環境(Oracle JDeveloper)を実行して、Javaコード、デプロイメント・ディスクリプタ、BPELプロセス、ADFユーザー・インタフェース・プロジェクトなどのソース・アーティファクトを作成します。JDeveloperにはSubversionクライアントが含まれています。これにより、開発者はSubversionサーバー上でのコードのチェックインやチェックアウト、相違のチェック、マージの実行、競合の解決などのアクションを実行できます。各開発者のマシンには、それぞれのワークステーション上のローカルMavenリポジトリも含まれており、このリポジトリには、開発者が自分のワークステーションで実行する必要があるローカル・ビルドの実行に必要な依存性が保持されています。たとえば、開発者は、共有Subversionサーバーにコードをチェックインする前に、ビルドをチェックし、ユニット・テストをローカルで実行する必要がある場合があります。
環境のサイズによっては、これらのコンポーネント(外部コンポーネントおよび開発者のマシンは除く)が単一サーバー上にあるか、または複数のマシンに分散している場合があります。
共有ディスクを使用する予定がある場合は、Subversion、Maven、Hudsonデータおよび製品バイナリをすべて共有ディスクに保持することを検討します。
図2-2は、推奨されているディレクトリ構造を示します。この構造では、確実に作成すると考えられる概要レベルのディレクトリのみを示しています。
製品バイナリの場合、環境(本番、開発およびQAなど)ごとに1つのコピーを保持する必要があることに注意してください。製品バイナリは同じバージョンのソフトウェアですが、異なるパッチがインストールされている場合があります。デプロイ先の環境として、常に同じ(パッチ適用済の)アーティファクトのセットを使用してビルドできるようにします。
図2-2の例のように開発環境が12.1.3まで移行している場合であっても、依然として12.1.2に対するビルドを実行できる必要があります。本番またはQAでバグが見つかった場合は、これらの環境にインストールしたのと同じバージョンのアーティファクトを使用してビルドできる必要があります。
Mavenリポジトリ・マネージャ(この場合はArchiva)のリポジトリを次に示します。
内部: 開発環境でビルドした最終アーティファクトを格納します。
スナップショット: 開発環境でビルドした作業中のアーティファクトを格納します。
ミラー: 外部リポジトリからダウンロードした依存性を格納します。
開発、テスト、QA、本番: 必要な依存性を格納するために、ターゲット環境ごとに1つのリポジトリを準備します。このようにするのは、2つの環境に同じバージョンのアーティファクト(12.1.3-0-0など)があるが、一方の環境ではそのアーティファクトにパッチが適用されているため、相違が発生することがあるためです。この要件の詳細は、5.3.7項を参照してください。
共有ディスク・サーバーは、製品バイナリ、Subversionリポジトリ、Archivaリポジトリ、Mavenバイナリ、Hudsonバイナリ、構成およびファイル記憶域用に十分な領域を提供する必要があります。少なくとも、40GB以上を割り当てることをお薦めします。Archivaスナップショット・クリーンアップ・ルール、ソース・コントロール・システムへのバイナリのチェックインを許可するかどうかなどの要因によって、必要な領域が増える場合があります。
