| Oracle® Fusion Middleware継続的インテグレーションによるアプリケーションの開発 12c (12.1.2) E48004-02 |
|
 前 |
この章では、単純なビルド自動化から継続的インテグレーション環境への移行に際して考慮する必要がある重要事項について、簡単に概要を説明します。
このマニュアルに記載されている各例に従って読み進めてきた場合は、Oracle Fusion Middleware環境でのデプロイメントを目的としたプロジェクトのビルド・プロセスを、Mavenを使用して管理する方法について理解できています。
次の論理的なステップとしては、継続的インテグレーション・アプローチに移行し、すべてのプロジェクトのビルドを中心となる1つの場所からトリガー、管理および監視できるようにします。
継続的インテグレーションの利点は、アプリケーションのコンポーネント化と、それらのコンポーネントが、多くの場合異なる開発者グループによって個別に変更されながら、継続的に統合されることによってもたらされます。Mavenプロジェクトは、これらのコンポーネントとそれらの相互関係を表すのに使用されます。HudsonではMavenのプロジェクト関係モデルが認識されるため、影響を受けるコンポーネントを、必要なビルドの順序に従って自動的に再ビルドおよび再テストできます。Hudsonによってコードベースに対する変更が検出されると、影響を受けるコンポーネントは、アプリケーション全体が適切に機能するように、正しい順序でビルドおよび再統合されます。
この章では、Hudsonを使用した継続的インテグレーション環境への移行の際に考慮すべき重要事項について説明します。この章の内容は次のとおりです。
依存性管理はMavenの主要機能であり、Fusion Middlewareで当面サポートされるANTなどの他のビルド自動化テクノロジとMavenを区別化する機能です。この項では、依存性管理の重要項目について説明します。
この章の内容は次のとおりです。
スナップショットのバージョニングについては、第7章で詳細に説明されています。自動化された継続的インテグレーション・システムが正しく動作するには、開発中のコンポーネントのスナップショットを使用することが必要です。修正バージョン、つまりスナップショットではないバージョンのアーティファクトは変更および置換しないように注意してください。ベスト・プラクティスは、アーティファクトのリリース後にこれらのアーティファクトを更新しないようにすることです。これは、Mavenアプローチの中心となる前提です。ただしここで注目されるのは、多くの場合、企業のソフトウェア開発においてこの前提が適切でないという点であり、ベンダーやエンド・ユーザーは、バージョン番号を変更せずに、たとえば該当場所にパッチを適用することによって、最終的なアーティファクトを更新することがあります。このルールに違反することが可能であっても、インテグレーションの安定性を確実にするために、最大限の努力をしてこのルールに従うことが必要です。
大部分のプロジェクトは他のアーティファクトに対する依存性を備えています。ビルド時にMavenは構成済のアーティファクト・リポジトリからこれらのアーティファクトを取得し、これらを使用してコンパイル、ランタイム、およびテストにおける依存性を解決します。
POMに明確に一覧されている依存性には、それら自身の依存関係が含まれている場合もあります。これを一般に推移的な依存性と呼びます。スコープやバージョンなどの依存属性を基に、Mavenはルールを使用して、ビルドで利用する必要がある依存性を決定します。この解決プロセスの重要な部分は、バージョン競合と関係しています。プロジェクトは、同じアーティファクト(同一のgroupIdおよびartifactId)の複数バージョンに対して推移的な依存性を持つ場合があります。この場合、Mavenは最も近い定義を使用します。つまり、依存性のツリーにおいてプロジェクトに最も近い依存性を持つバージョンを使用します。プロジェクトのPOMで特定のバージョンを明示的に宣言すると、常にそのバージョンを保証できます。
|
注意: 依存性のツリーの同じ深さに2つの依存性バージョンが存在する場合、Maven 2.0.8まではどちらが優先されるか定義されていませんでしたが、Maven 2.0.9以降は宣言の順序で決定されます。つまり、最初に宣言されたバージョンが優先されます。 |
依存性では必要に応じてスコープを指定できます。スコープは、特定のビルド・フェーズで依存性をクラスパスに対して使用可能にするかどうかを決定するだけでなく、推移的な依存性がクラスパスに伝播される方法にも影響を与えます。
6つのスコープが使用可能です。
コンパイル: これがデフォルトのスコープで、スコープの指定がない場合はこれが使用されます。コンパイル依存性は、プロジェクトのすべてのクラスパスで使用可能です。さらに、これらの依存性は依存プロジェクトに伝播されます。
提供済: これはコンパイルとよく似ていますが、ランタイムの依存性の提供にJDKまたはコンテナを期待していることを示します。たとえば、Java Enterprise EditionのWebアプリケーションをビルドする場合、Webコンテナでこれらのクラスが提供されるため、サーブレットAPIおよび関連するJava EE APIに対する依存性を提供済スコープに設定できます。このスコープはコンパイルおよびテスト・クラスパスでのみ使用可能であり、推移的ではありません。
ランタイム: このスコープは、依存性がコンパイルには不要で実行には必要であることを示します。ランタイムおよびテスト・クラスパスで使用されますが、コンパイル・クラスパスでは使用されません。
テスト: このスコープは、アプリケーションの通常使用では依存性が不要であり、テスト・コンパイルおよび実行フェーズでのみ使用可能であることを示します。
システム: このスコープは提供済と似ていますが、このスコープを含むJARを明示的に提供する必要があります。アーティファクトは常に使用可能であり、リポジトリ内で検索されることはありません。
インポート: (Maven 2.0.9以降でのみ使用可能)このスコープは、タイプPOMの依存性においてのみ使用されます。これは、指定したPOMをそのPOMの依存性で置き換える必要があることを示します。このように置き換えられるため、インポートのスコープを持つ依存性は実際には依存の推移性の制限に関与しません。
アプリケーションなどの一連の非依存プロジェクトは、複数モジュールのPOMで集約できます。これを、継承された構成を提供する親POMと混同しないようにしてください。複数モジュールのPOMは、サブモジュール・プロジェクトへの継承の親になる場合もあります。Mavenビルドが複数モジュールのPOMで実行されると、Mavenはサブプロジェクトのツリーを調べて、モジュールをビルドするための正しい依存順序を決定します。
複数モジュールのPOMは、Hudsonでの複数コンポーネント・ビルドの編成に役立ちます。
この項では、継続的インテグレーション環境への移行の際に考慮する必要があるMavenのいくつかの局面について説明します。
この章の内容は次のとおりです。
継続的インテグレーションに含まれるすべてのプロジェクトで、そのPOMのdistributionManagementセクションを指定する必要があります。このセクションは、ビルド・プロセスの最後にアーティファクトがどこにデプロイされるか、つまりどのリポジトリ(ローカルまたはリモート)にデプロイされるかをMavenに指示します。このマニュアルの例では、Archivaリポジトリを使用します。アーティファクトをリポジトリにデプロイすると、それらを他のプロジェクトで依存関係として使用できるようになります。
distributionManagementセクションを定義して、スナップショットをデプロイするリポジトリを示し、リリースする必要があります。distributionManagement構成は、第8章で説明しているように、Oracle共通のPOMなど、すべてのプロジェクトで共有される共通継承POMに配置することをお薦めします。
次に、distributionManagement構成の例を示します。
<distributionManagement>
<repository>
<uniqueVersion>false</uniqueVersion>
<id>releases</id>
<name>Releases</name>
<url>http://server:port/archiva/repository/releases/</url>
<layout>default</layout>
</repository>
<snapshotRepository>
<uniqueVersion>true</uniqueVersion>
<id>snapshots</id>
<name>Snapshots</name>
<url>http://server:port/archiva/repository/snapshots</url>
<layout>default</layout>
</snapshotRepository>
</distributionManagement>
Mavenがリポジトリにアクセスする方法とそのタイミングを管理する重要な設定があります。
更新ポリシー: これは、Mavenがリモート・リポジトリに対して、すでにローカル・リポジトリにあるアーティファクトの更新を確認する頻度を制御します。Hudsonのsettings.xmlで、updatePolicyをalwaysとして使用するようにスナップショット・リポジトリを構成します。updatePolicyの設定は、各自の開発システムに影響します。デフォルト値はdailyです。Hudsonで変更が行われたときにその変更を統合する場合は、それらのupdatePolicyを適宜に変更する必要があります。依存性は、警告なしで突然変更される場合があります。継続的インテグレーション・システムで、不具合の発生を削減するために適所で十分なテストを行う必要がある間、開発時の最新のスナップショットによっては、さらに問題が発生する可能性があります。このような例の1つとしてAPIの変更があげられます。
すべてのプロジェクトのスナップショットの依存性を最新の状態にして、チェックインの前に、デプロイされているコードベースの現在の状態がローカル・ビルドに反映されるようにする必要があります。
サーバー資格証明: これは、リモート・リポジトリへのアクセスに必要な資格証明をMavenに通知します。一般的にMavenリポジトリでは、たとえば新規アーティファクトの公開などのリポジトリの変更を行えるようになる前に認証を行う必要があります。Archivaゲスト・ユーザーにグローバル・アップロード権限を付与する場合を除いて(これはお薦めできません)、serversセクションにスナップショット・リポジトリの正しい資格証明を指定する必要があります。スナップショット・リポジトリのアップロード権限を持つ一意のHudsonユーザーを設定する必要があります。ユーザーおよびロール構成の詳細は、第4章を参照してください。
パスワード値にはMavenのパスワード暗号化を使用します。パスワード暗号化に関するMavenのマニュアルは、http://maven.apache.org/guides/mini/guide-encryption.htmlで参照できます。
次に、Hudsonユーザー向けのsettings.xml構成の例を示します。
<settings>
...
<servers>
...
<server>
<id>snapshots</id>
<username>hudson</username>
<password>{COQLCE6DU6GtcS5P=}</password>
</server>
...
</servers>
...
</settings>
この項では、Hudsonでのビルド・ジョブの設定方法を説明します。Mavenプロジェクトのビルドに使用できる様々なオプションがあります。この項では、Oracleによって推奨されているアプローチについて説明します。
先に進む前に、第6章の説明に従って、Hudsonが構成済であることを確認してください。
この章の内容は次のとおりです。
基本的なMaven Hudsonジョブを作成するには:
Hudson Webインタフェースを開き、必要に応じてログインします。
新しいジョブを作成します。
右側のメニューから「New Job」を選択します。
一意の名前を指定し、「Build a free-style software project」を選択します。
「OK」をクリックします。
ソース・コード管理を構成します。
SSH公開鍵および秘密鍵の構成を含め、Subversionサーバーの構成が完了していることを確認します。
「Source Code Management」で、「Subversion」を選択します。
プロジェクト・ディレクトリのリポジトリURLを指定します。たとえば、svn+ssh://subversion-server/ciroot/subversion/repository/trunk/projects/my-projectなどです。
|
注意: この例では、SSHを使用してSubversionにアクセスする HudsonによってURLの検証が試行され、次のようなエラー・メッセージが返される場合があります。 Unable to access svn+ssh://hostname/ciroot/subversion/repository/trunk : svn: E200015: authentication cancelled(show details) (Maybe you need to enter credential?) このようなエラー・メッセージが表示された場合は、次の手順を実行します。
|
Mavenビルド・ステップを追加します。
「Build」セクションで、「Add Build Step」ドロップダウン・メニューから「Invoke Maven 3」を選択します。
「Maven 3 home」を選択します。必要なゴールおよびプロパティを適切なテキスト・フィールドに追加します。
SNAPSHOT継続的インテグレーション・ビルド環境が整っている場合は、クリーン・デプロイを実行するようにゴールを構成します。
必要に応じて、Hudsonの構成時に、「Advanced」設定を開き、Settingsエントリが、Hudson Webインタフェースで作成したMaven設定を指していることを確認します。
構成を保存します。
ページの下部にある「保存」をクリックします。
Hudsonでは、Hudsonでの継続的インテグレーション・ビルドのトリガーを管理する方法を多数提供しています。これらには、手動および自動によるトリガーが含まれています。手動でビルドを開始するオプションは、あらゆるジョブに対して常に使用可能です。自動トリガーを選択した場合は、プロジェクトの構造、ソース・コードの場所、分岐の有無などの要因を考慮します。
この章の内容は次のとおりです。
ビルドのトリガー方法に関係なく、ジョブは保留ジョブ・キューに追加され、リソースが使用可能になったときに実行されます。
すべてのジョブをユーザー・インタフェースから「Build Now」リンクを使用して開始できます。
このタイプのビルド・トリガーは、正常な継続的インテグレーション・ビルドの構築に不可欠です。プロジェクト・ソースに対する変更が行われると、Hudsonは関連するHudsonジョブのビルドをトリガーします。トリガーは、関連するSubversion URLの変更を定期的に確認することによって、これを実行します。
このトリガーを有効にするには、「Poll SCM」オプションを選択します。次に、Hudsonがリポジトリのポーリングに使用するスケジュールを決定するcron式を指定する必要があります。
ジョブ・タイプによっては、スケジュールに基づいてこれらをトリガーできます。長期間実行しているシステム・インテグレーション・テストは、定期的に実行するビルドの一例であり、これは、テスト・ソースが変更されるたびに実行するビルドとは対照的です。
スケジュール・ベースのトリガーは、Poll SCMトリガーと非常によく似たcron式を使用して構成します。
小さなプロジェクトに複数のビルドが含まれ、これらのビルドで、相互に依存性を持つ一意のアーティファクトが作成される場合があります。トリガー・タイプの結果としてHudsonでアーティファクトを再ビルドする場合は、インテグレーションが引き続き有効になるように、依存するアーティファクトもビルドおよびテストする必要があります。このHudsonサーバーでビルドされた依存関係が正常に完成すると、Hudsonは自動的にこれらの関係を認識し、ビルドをトリガーします。このトリガーが機能するには、依存性で、ビルド後のアクション「Notify that Maven dependencies have been updated by Maven 3 integration」を有効にすることも必要です。
同時に開発され、共通のMavenリポジトリでスナップショットとして管理されている依存関係が存在する場合、Hudsonインスタンスでこれらを管理する必要があります。この方法が実用的でない場合、SNAPSHOT依存性トリガーを使用して、このような依存性における変更についてMavenリポジトリを監視できます。更新されたSNAPSHOT依存性が検出されると、ビルドがトリガーされ、インテグレーションのために新しい依存関係がダウンロードされます。
このトリガーでは、cron式を使用してポーリング間隔も構成します。
ビルド依存性を正しく管理するには、各プロジェクトを別々のHudsonビルドとして追加し、依存性トリガーを手動で構成するか、または、複数モジュールのMaven POMを親Hudsonジョブとして構成します。複数モジュールのソリューションでは、手動で依存性を結びつける際の誤りを減らすことができます。また、Maven構成での依存性の変更にあわせて最新の状態に保つことができます。
複数モジュールのビルドの構成は、通常のプロジェクトの構成と同じです。コンポーネント・プロジェクト・ビルドの結果を調べるために、Hudsonでは「Maven 3 Build Information」リンクのビルド結果ページにタブが用意されています。ページの一番上にある「Modules」タブに、コンポーネント・ビルドの結果の要約が表示されます。
任意のサブプロジェクト・ビルドのログを確認するには、「Console Log」リンクを使用します。すべてのプロジェクトおよびサブプロジェクト・ビルドが実行順にログに記録されます。
ビルドが中断した場合に適切なパーティに通知を送信するように、Hudsonを構成する必要があります。継続的インテグレーション・システムでは、変更でビルドおよびテスト・プロセスが中断されないようにする必要があります。このようなことが発生した場合は、中断に関する通知を受信して、可能なかぎり迅速に問題に対処する必要があります。Hudsonでは、各ユーザーを一意のユーザーとして登録します。Hudsonユーザー名は、通常コミットに使用するSubversionユーザー名と一致している必要があります。Hudsonはこの名前に基づいて、適切な連絡先電子メールを検索し、通知を送信します。
一般的な電子メール通知構成は、「Manage Hudson」→「Configure System」→「E-mail Notification」で参照できます。
また、ユーザー管理のいくつかのフォームが有効になっていることを確認する必要もあります。これは、「Configure System」パネルから「Enable Security」を選択することで実行できます。ユーザー管理には多数の選択肢があり、LDAPなど、他の大多数の一般的なソリューションをサポートする追加のサード・パーティ製プラグインがあります。最適なオプションは、「Hudson's own user database」を使用することです。この選択肢は「Access Control」セクションから選択します。特定のユーザーおよびグループに対する許可を制限するための追加オプションがあります。
新規ユーザーを追加する場合は、Hudsonホーム・ページの一番上にある「sign up」リンクに従い、必要な情報を入力するだけで追加できます。ユーザー名は対応するSubversionユーザー名と一致している必要があります。
