1 継続的インテグレーションの概要

この章では、継続的インテグレーションの主要な概念について説明し、Oracle Fusion Middlewareのコンテキスト内での継続的インテグレーション環境の作成に使用できる一連のツールについて説明します。

この章の構成は、次のとおりです。

• 1.1項「Oracle Fusion Middlewareの継続的インテグレーションの概要」

• 1.2項「Subversionを使用したバージョン・コントロール」

• 1.3項「Mavenを使用したビルド自動化および依存性管理」

• 1.4項「Archivaを使用したリポジトリ管理」

• 1.5項「Hudsonを使用した継続的インテグレーション」

• 1.6項「まとめ」

1.1 Oracle Fusion Middlewareの継続的インテグレーションの概要

企業がそのビジネス・ニーズをサポートするためのアプリケーションを開発する場合、通常は開発者のチームを採用しますが、開発者は多くの場合小さなチームで共同で作業し、各チームがアプリケーションの一部をビルドします。次に、これらの部分がアセンブルされてアプリケーション全体が作成されます。

現代の多くのアプリケーションは、サービス指向アーキテクチャ(SOA)に基づいています。これは、開発者がビジネス・アプリケーションのニーズを満たすために様々な方法でアセンブルできるサービス(ビジネス機能の小さな部分)をビルドすることを意味します。SOAの今日の人気をもたらしたSOAの機能の一部を次に示します。

• 変更の影響を軽減する、アプリケーションのコンポーネントの緩やかな結合

• 情報技術開発の長年の目標である、サービスの再利用

• ビジネス・ニーズの変更に応じてアプリケーションの動作を簡単に変更できる柔軟性と俊敏性

この新しいパラダイムでは、多数の開発組織が、古いウォーターフォールスタイル手法を置き換える反復開発手法も採用しています。俊敏で反復的な開発手法では、従来のウォーターフォール・アプローチよりも頻繁に機能の小さな増分を提供することに焦点を当てています。新しいアプローチの支持者は、エラーがすぐに見つかるためエラーによる影響が一般に少ないこと、ビジネス要件が常時かつ急速に変化する今日の環境にこのアプローチが特に適していることを主張しています。

これらの手法の多くには、継続的インテグレーションの採用という特徴もあります。組織はソフトウェアのビルドとテストの自動化に強い関心を持っていますが、継続的インテグレーションは、これを実現するのに役立ちます。

継続的インテグレーションは、小規模かつ頻繁な品質管理を行うことにより、品質の向上およびソフトウェア提供時間の短縮を試みるソフトウェア・エンジニアリング・プラクティスです。次の主要なプラクティスで特徴付けられます。

• バージョン・コントロール・システムを使用して、変更を追跡します。

• すべての開発者が、主なコード行、ヘッドおよびトランクに毎日コミットします。

• 製品は、すべてのコミット操作でビルドされます。

• ビルドは自動化され高速である必要があります。

• 本番に類似した環境に自動的にデプロイされる必要があります。

• 自動化されたテストが有効になっている必要があります。

• すべてのビルドの結果が公開され、ビルドが中断されたかどうかをすべての人が確認できるようにします。

• 開発者、テスターおよびその他のステークホルダーが成果物を簡単に使用できます。

Oracle Fusion Middleware 12cでは、Oracle Fusion Middlewareプラットフォームでアプリケーションを開発するための継続的インテグレーション手法を採用する企業へのサポートを提供しています。具体的には、次のことを提供しています。

• 開発ツールOracle JDeveloperでの一般的なバージョン・コントロール・システムとの統合

• ビルドをスクリプト化および自動化できるように、ビルドおよびプロジェクト管理システムであるMavenを使用してコマンドラインからプロジェクトをビルドする機能

• Maven原型から新規プロジェクトを作成する機能

• Mavenリポジトリから必要な依存性をダウンロードする機能

• 様々な環境(テスト、QA、SIT、本番など)を対象としたビルドを実行できるように、プロジェクトをパラメータ化する機能

• プロジェクトのテストをMavenビルド・ライフ・サイクルに含める機能

• 既存のローカルOracleホーム・ソフトウェア・インストール・ディレクトリからOracle提供の依存性をMavenリポジトリに移入する機能

• Hudsonなどの継続的インテグレーション・サーバーの管理下でMavenビルドを実行する機能

• Oracle Fusion Middlewareで使用するための、ビルドまたは継続的インテグレーション環境あるいはその両方の設定に関する包括的ドキュメント

バージョン・コントロール、継続的インテグレーション、および企業がこの種の環境で通常使用するその他のコンポーネントには選択肢があります。これらのコンポーネントの多くは無料のオープン・ソースであり、その他に市販の製品もあります。このガイドでは、次の一連のコンポーネントに基づく参照環境を示します。

• バージョン・コントロール用のApache Subversion

• ビルドまたはプロジェクト管理用のApache Maven

• Mavenリポジトリ・マネージャとしてのApache Archiva

• 継続的インテグレーション・サーバーとしてのApache Hudson

使用可能な選択肢はこれらに限定されないことに注意してください。たとえば、異なるバージョン・コントロール・システムや異なる継続的インテグレーション・サーバーを使用できます。一般的な選択肢のほとんどでは、それほど苦労せずにこのガイドの例を適応させることができます。

1.2 Subversionを使用したバージョン・コントロール

Subversionは、よく使用されているバージョン・コントロール・システムです。元々は、今日でも依然として広く使用されているConcurrent Versioning System (CVS)の論理的継承として作成されました。Subversionは、次の理由により、このガイドの例でバージョン・コントロール・システムとして使用されています。

• Oracle Fusion Middlewareプラットフォーム用アプリケーションのビルドに最もよく使用されている開発ツールであるOracle JDeveloper、およびその他の一般的な開発ツールと緊密に統合されています。

• 仮想プライベート・ネットワークやHTTPプロキシなど、様々なネットワーク環境で正常に動作します。このため、企業、およびそのパートナやサプライヤがよく遭遇するネットワーク環境に十分適合しています。

• 証明書を使用する厳密認証など、様々な認証オプションをサポートしています。

• Oracle SOA Suiteを使用するプロジェクトの場合、開発者が単一のチェックインまたはコミット操作の一部として複数のファイルを更新できるようにするアトミック・コミットを提供します。

標準的なSubversion環境は、ソース・コード・アーティファクトを格納する1つ以上のSubversionリポジトリで構成されています。これらには、(統合開発環境に含まれているか、またはスタンドアロン・クライアントとしての)Subversionクライアントを使用する開発者がアクセスします。開発者は、アーティファクトをリポジトリにコピーしたり、リポジトリからコピーできます。開発者がアーティファクトを変更すると、新しいバージョンのアーティファクトがリポジトリに作成されます。開発者は、アーティファクトのバージョンを表示および比較して、変更内容や変更者を確認できます。

1.3 Mavenを使用したビルド自動化および依存性管理

Mavenは、プロジェクト管理およびビルド管理システムです。Mavenでは、次の点に関するプロジェクト管理を提供します。

• 命名およびバージョン採番方法

• 依存性

• ソース・コードの格納場所

• ビルドの格納場所

• プロジェクト・タイプのテンプレート

• リリース・プロセス

Mavenでは、次の点に関するビルド管理を提供します。

• ビルドの実行方法

• 各フェーズでの実行内容

• ビルドのパラメータ化

• 拡張可能なフレームワーク

Mavenは、ビルド・ライフ・サイクルの主要な概念に基づいています。特定のアーティファクトまたはプロジェクトをビルドおよび配布するプロセスが明確に定義されています。

Mavenを使用する開発者の場合、任意のMavenプロジェクトのビルドを可能にする小さなコマンド・セットを学習する必要があります。Mavenプロジェクト・オブジェクト・モデル(POM)により、プロジェクトが適切にビルドされます。

次の3つの定義済の主要なライフ・サイクルがあります。

• プロジェクトをビルドするためのデフォルト

• 生成されたすべてのアーティファクトをプロジェクトから削除するためのクリーン

• プロジェクトのドキュメントをビルドするためのサイト

ビルド・ライフ・サイクルは、一連のビルド・フェーズでさらに定義されます。ビルド・フェーズは、ライフ・サイクルのステージを表します。ビルド・フェーズは、ライフ・サイクルを完了するために順に実行されます。ビルド・フェーズは、実際のタスクを実行するゴールで構成されます。標準のライフ・サイクル・フェーズにはデフォルトの一連のゴール・バインディングがあります。Mavenプラグインにより、プロジェクトにゴールを追加できます。次の表に、ビルド・フェーズおよび各フェーズの目的を示します。

ビルド・フェーズ	目的
validate	プロジェクトが適切で、必要な情報がすべて使用可能であることを確認します。
compile	プロジェクトのソースをコンパイルします。
test	適切なユニット・テスト・フレームワークを使用してコンパイル済ソース・コードをテストしますが、テストではコードをパッケージ化またはデプロイする必要はありません。
package	コンパイル済コードを取得し、配布可能な形式(JAR、WAR、EAR、SAR、GARファイルなど)にパッケージ化します。
integration-test	必要に応じて、統合テストを実行できる環境でパッケージを処理およびデプロイします。
verify	パッケージが有効で、品質基準を満たしていることを確認するチェックを実行します。
install	他のプロジェクト内の依存性としてローカルに使用するために、パッケージをローカル・リポジトリにインストールします。
deploy	最終リリースの場合は、他の開発者およびプロジェクトと共有するために、最終パッケージをリモート・リポジトリにコピーします。

標準的なMaven環境は、各開発者のローカル・マシン上のMavenインストール、企業内の共有Mavenリポジトリ・マネージャ、および依存性が格納されている1つ以上のパブリックMavenリポジトリで構成されます。主要なMavenリポジトリは、Mavenの中央リポジトリと呼ばれます。このリポジトリには、開発プロジェクト時に依存性としてよく使用される無料のオープン・ソース・ライブラリが数多く格納されています。例として、JUnitユニット・テスト・フレームワーク(Spring、Struts、その他の一般的なユーザー・インタフェース・ライブラリ)およびコード・カバレッジとスタイル・チェック・ライブラリ(CoberturaやPMDなど)があります。

1.4 Archivaを使用したリポジトリ管理

1つのプロジェクトで複数の開発者が作業する場合、企業にとって、独自の内部Mavenリポジトリを次の2つの目的で設定すると有用です。

• Mavenの中央リポジトリのように、外部バイナリ・リポジトリのプロキシまたはキャッシュとして機能することで、依存性が1回だけダウンロードされてローカルにキャッシュされ、すべての開発者がそれらを使用できるようになります。

• 開発者がビルドしたアーティファクトを格納して、他の開発者またはプロジェクトと共有できるようにします。

Mavenリポジトリは、特定のレイアウトのファイル・システム(ディレクトリ構造)と同様に単純な場合もありますが、多くの組織では、Mavenリポジトリ・マネージャと呼ばれるタイプのソフトウェアを使用するとさらに便利になります。これは、前にリストした目的に対処する際に役立ちます。このガイドでは、Mavenリポジトリ・マネージャとしてApache Archivaが使用されています。ほかにも、無料で提供されているものや市販のものを使用できます。

Archivaを使用する一般的な企業では、Archivaは開発者およびビルド・マシンがアクセス可能なサーバー上に設定されます。企業では、このサーバー上に次のリポジトリを定義します。

• Mavenの中央リポジトリのミラー

• 完了または公開された内部開発済アーティファクトを格納する内部リポジトリ

• 開発中でまだ完了していない内部開発アーティファクトを格納するスナップショット・リポジトリ

ニーズに応じて追加のリポジトリが存在する場合もあります。たとえば、特定のプロジェクト用として、または異なるライフ・サイクル・ステージに必要な様々なバージョンの依存性用として、追加リポジトリが存在する場合があります。たとえば、本番に対するバグ修正では、開発中の現在のバージョンとは異なる依存性を使用する場合があります。

すべての開発者は、外部リポジトリではなくこれらの内部リポジトリを指すようにMavenインストールを構成して、開発者が内部リポジトリにすでに格納されているアーティファクトを使用できるようにし、ダウンロード時間とビルド時間を短縮できるようにする必要があります。また、これにより、すべての開発者が様々な依存性で同じバージョンを確実に使用するようになります。

Archivaは、スナップショット・リポジトリのアーティファクトの期限切れを管理する機能も提供します。ビルドを実行するたびに、アーティファクトが作成され、スナップショット・リポジトリに格納されます。継続的インテグレーションを使用している場合は、1日に数回ビルドを実行する必要がある場合があります。ベスト・プラクティスは、これらの格納済アーティファクトを一定時間(1週間など)経過後に削除するようにArchivaを構成することです。または、各アーティファクトに関して最新のn個のバージョンのみを保持するようにArchivaを構成することもできます。いずれのアプローチも、スナップショット・アーティファクトの期限切れおよび削除を自動的に管理するのに役立ちます。

1.5 Hudsonを使用した継続的インテグレーション

Hudsonは、ビルド・プロセスの自動化を可能にする、一般的な継続的インテグレーション・サーバー製品です。通常、この自動化には次のステップが含まれます。

• 開発者がバージョン・コントロール・システムにコミットすると常にビルドを開始

• バージョン・コントロール・システムからのコードのチェックアウト

• コードのコンパイル

• ユニット・テストの実行および(多くの場合JUnitを介した)結果の照合

• デプロイ・アーカイブ形式へのコードのパッケージ化

• ランタイム環境へのパッケージのデプロイ

• 統合テストの実行および結果の照合

• Mavenスナップショット・リポジトリへのビルドのトリガー

• あらゆる問題を電子メール経由で開発者に警告

ただし、ビルド・システムを使用して、企業の標準およびベスト・プラクティスへの準拠を強制適用することもできます。たとえば、企業では、次のステップをビルド・プロセスに含めることができます。

• コード・カバレッジを実行して、適切な数のユニット・テストが存在し、実行されていることを確認

• コード品質チェックを実行して、一般的な問題を検索

• 命名規則、ネームスペースなどとの準拠を確認するためのチェックの実行

• ドキュメントがコードに含まれていることを確認するためのチェックの実行

• 承認されたバージョンの依存性が使用され、承認されていないその他の依存性は使用されていないことを確認するためのチェックの実行

HudsonではWebベースのコンソールを提供しており、ビルド・マネージャはこれを使用してビルドを定義、実行および監視できます。ビルドは、1つ以上のビルド・サーバーで実行されます。通常、ビルド・サーバーの数は、ビルドのボリューム、およびビルド完了までに予測される時間に基づいて定義されます。Hudsonは、APIも提供し、プラグイン・メカニズムを通じて拡張できるため、必要に応じて機能を追加できます。

1.6 まとめ

このガイドでは、Oracle Fusion Middleware 12cプラットフォーム上でアプリケーションを開発する大規模開発者チームをサポートする継続的インテグレーション環境を確立する方法を説明しています。この環境には、バージョン・コントロール、ビルド自動化および依存性管理用のMaven、MavenリポジトリとしてのArchiva、ビルド・プロセスを自動化するHudsonなどの継続的インテグレーション・サーバーの使用が含まれます。

このガイド内のすべての例で、Apacheツール(Subversion、Maven、ArchivaおよびHudson)を使用しています。ただし、その他の市販およびオープン・ソースの代替ツールを使用することもできます。ここでの意図は、参照可能で、他のツールに簡単に適応できる例を提供することです。たとえば、バージョン・コントロールにgitを使用したり、リポジトリ・マネージャとしてNexusを使用できます。このドキュメントでのツールの選択は、他のツールが同等の結果をもたらさないことを示唆するものではありません。