どのように構築しましたか

はじめに

プロジェクトが成長し、多くのモジュールと依存関係を取得すると、プロジェクトアセンブリを手動でセットアップするのが非常に難しくなる場合があります。 さらに、開発者、テスターから管理者まで、プロジェクトのすべての技術的な参加者が構成に関与するため、時間の無駄です。



さらに、開発およびテストシステムを絶えず更新する必要があり、混乱することさえありません。 これには、 継続的な統合の実践がないわけではありません。





この記事では、Mavenを使用してアセンブリを実装した経験について説明しているため、Mavenの基本的な知識が必要です。 クイックスタートのために、サイトのhttp://www.apache-maven.ruを勉強するだけで十分です。トピックのより詳細な開発については、元のソースhttp://maven.apache.orgを参照してください。



この記事の目的は、Mavenの使用方法を教えることではなく、ポジティブなソリューションとネガティブなソリューションを使用した実装の経験を示すことです。 この知識があれば、チームにMavenアセンブリを簡単かつ迅速に展開できます。

なぜアリではないのですか？

そのような質問を予想して、私たちはantを使用すると言いますが、アセンブリ自体ではなく、技術的な機能のために以下で詳しく説明します。



Mavenのもう1つの重要な利点は、使用するコードのみを収集できることです。他のすべては夜間に別のサーバーで収集されます。

環境

まず、プロジェクトの構造と開発アプローチについてお話しする価値があります。 このプロジェクトは長年にわたって開発されてきており、 maven-webapp-artifactに対応しない構造を持っているため、これは非常に重要です。



したがって、1つのSVNリポジトリに多くのモジュールが保存されています。 各モジュールには、メインの開発ブランチ（トランク）と、必要に応じてタグ（タグ）およびブランチ（ブランチ）があります。 ほとんどのモジュールには、javaクラスとjspページ、スクリプト、グラフィックスなどの両方が含まれています。ほとんどのモジュールはスタンドアロンのWebアプリケーションであり、独立して動作できます。 モジュールの例：コア、石鹸、ワークフロー、アドオン、共通...私はそれらの約100を数えました。



ほとんどの場合、プロジェクトは個別のモジュールで構成され、Javaクラスの特定のリソースとロジックをホストします。 時には、そのようなモジュールがありません。 プロジェクトの最終的なアセンブリは、単一のWebアプリケーションの形式の一連のモジュールで構成されます。



モジュールに必要なライブラリは、リポジトリのlibフォルダーに直接保存されます。Webリソースには、独自のsx-warフォルダーがあります。 標準のsrcおよびtestフォルダーと同様に。







必然的に、ほとんどすべてのモジュールはコアに依存し、必要に応じて相互に依存します。



メタ情報を含むデータベースもあります。 それに基づいて、モジュールが相互作用し、ユーザーとのすべての作業が構築されます。 たとえば、公開ブロックもメタ情報の単位であり、データベースに保存されます。 つまり、データ自体に加えて、データベースにはこのデータを操作するための設定が保存されます。 これらはコンソールでも構成されます。コンソールは、公開ユニットにも基づいています。 サービスパックを使用してメタ情報を転送することが可能です。



理想的には、各モジュールにはメタ情報を持つ独自の共通パッケージがあります。 コアのデータベースは最軽量のデータベースであり、どのモジュールでも拡張できます。 カーネルはほとんどアプリケーションサーバーであり、多機能モジュールを動的にロード/アンロードする機能はありません。 すべてのモジュールに個別のメタがあるわけではありませんが、このために努力しています:)

BC

そのようなフレーズがあります。 つまり、「これ」は、会社での作業が開始される前であっても、かなり前のことでした。 アセンブリのセットアップがどのように進んだかを説明します。 また、初めてのセットアップに多くの時間を費やす必要がありました。



そして、あなたは私たちと一緒に仕事を得ました。 二日目があります。 最初のサブシステムは、サブシステムのスクリーンキャストを表示し、メタ情報を操作しました。 アセンブリを構成する必要があります。 さて、プロジェクトのナレッジベースにプロジェクトに必要なモジュールに関する情報が含まれている場合。 多くの場合、この情報は関係ありません（更新を忘れたり、ケースごとに更新したりする）。 モジュール自体の依存関係に関する情報は見つかりません。その情報も時代遅れになっています。



必要なすべてのモジュールのトランクバージョンがSVNから抽出され、IDEでプロジェクトが作成されます。 そして最も難しい部分：必要なすべてのライブラリとモジュール接続のインポートを構成します。 一部のモジュールからライブラリの一部のバージョンを除外し、他のモジュールを使用する必要がある場合は、依然として複雑です。 1つのフォルダー内のすべてのモジュールのアセンブリを構成します。 次に、Webアプリケーションサーバーを構成します（tomcatを使用）。



これでプロジェクトが構成されました。次に、最初のバージョンの2番目、3番目のバージョンを構成する必要があります（エラーを処理するにはブランチを使用します）。 開発者は不安になります。



依存関係が変更され、すべてのアセンブリが壊れています。 また、管理者はantを使用して製品アセンブリを作成します。すべてが故障します。 多くの場合、管理者と開発者の間の異なるアセンブリに起因する問題があります。

最初の試み

集会を担当する特別な人もいなかったし、mavenについての知識もなかった。 したがって、プロジェクトにMavenを実装する最初の試みは失敗しました。



親pom.xmlは別のリポジトリフォルダーに配置されています。 その後、別のプロジェクトフォルダーで、 svn-externalsが構成され、プロジェクトに必要なすべてのモジュールと、別のフォルダーの親pom.xmlが含まれました。







単一のSVN構造でモジュールの階層を使用する従来のアプローチは、各モジュールが多数のプロジェクトで使用されるため、私たちには適していませんでした。 そして、1つのシングルだけではありません。 また、プロジェクトで親POMを操作することは望ましくありません。 さらに、モジュールのバージョンを修正すると、すべてのプロジェクトに自動的に影響します。



必要なすべてのライブラリはhttp://search.maven.orgで検索されませんでした。多くのライブラリがあり、それらはすべてリポジトリ内に存在しません（バージョンのないライブラリはlibフォルダーに格納されます。たとえばaxis.jar、jtds.jar、velocity.jar）。 スクリプトを使用して、すべてのライブラリをNexusにロードしました。 GroupIdおよびArtifactIdは、マスクsx。<ライブラリ名>（sx.axis）を使用して設定されました。



典型的なpom.xmlモジュールは次のようになります。





各プロジェクトについて、その中のモジュールのリストを変更する必要があることがわかります。



アセンブリ中に、各モジュールは個別の戦争でアセンブルされ、 maven-overlayを使用して共通のデプロイに展開されました。

失敗の理由

svn-externalsを使用したMavenアプローチの利点を完全に打ち消しました。 このプロパティでは、svnフォルダーのプロパティを手動で編集せずに、すべてのモジュールのコードを明確に修正することはできません。 これは、10〜15個のモジュールが存在し、特定のバージョンのパッチがリリースされると、ほぼ不可能になります。 そして、私は本当にMavenリリースプラグインを使用したかったのです。

長所

• すべてが「今ここ」で起こっています。 開発者は、SNAPSHOT依存関係（メインの開発ブランチからのビルド）の更新期間に依存しません。
• 開発者は複数のモジュールを一度に変更できます（モジュールのカプセル化に違反しているため、疑わしい点です）。
• 必要なモジュールのセット全体が表示されます。

短所

• すべてのモジュールの完全な組み立てには時間がかかります。
• コードバージョンを適切にロックできません。
• すべてのライブラリはパブリックリポジトリから取得されるわけではありません。新しいライブラリを追加するのは別の手順です。
• Jar-hellは、誰かがパブリックリポジトリのライブラリを使用することを決定し、それが既に企業のリポジトリにある場合に可能です（両方のバージョン、または3つも展開になります！）。 これは、GroupId：ArtifactId：バージョンが変更されたために発生します。
• コードは1つのSVNフォルダーに格納されているようで、（svn-externalsを使用して）完全に異なるものをチェックアウトする必要があります。 透明ではない-麻酔薬;

二度目の試み

数回の反復で開発されたアセンブリを実装する2回目の試み。

反復1

まず、個々のモジュールと製品全体の両方のコードを修正するメカニズム（バージョンのリリース）を取得する必要がありました。 これを行うために、svn-externalsの使用を取り除きました。 各モジュールは独立していることが判明し、個別に組み立てられました。 モジュールが最終アセンブリに組み込んだすべての依存関係。



親pom.xmlもタスクに従って変更されています。 すべてのモジュールがそれをベースとして使用します。

反復2

バージョンリリースプラグインは、すべてのプロジェクトモジュールに実装されています。 これを行うために、各モジュールにブロックが追加されました。





この構成を基本pom.xmlに取り込み、ArtifactId-Versionプロパティを使用することを検討しましたが、すべてのプロジェクトではこの値はリポジトリ内のフォルダーの名前と一致しません。 したがって、アイデアはより良い時代まで延期されました。 最初のバージョンは、すべてのpom.xmlモジュールの基本を受け取りました。



新しいプロファイルがベースpom.xmlに追加されました：production。 アセンブリを企業のFTPにアップロードし、後でプロジェクトに拡張できます。

反復3

jar-hellとの不愉快な衝突の後、すべてのアセンブリでライブラリを整理することが決定されました。 カーネルには100を超えるライブラリがあり、ほとんどすべてのバージョンがなかったため、簡単ではありませんでした。 各バージョンは、バージョンを「計算」するために、公開リポジトリで見つける必要がありました。 「サプライズ」のライブラリは、内部アセンブリとパッチ、修正バージョンで開かれました。 アーティファクトの座標は保持しますが、バージョンではpostscript _customを使用して、Mavenリポジトリに慎重に配置しました。



Nexusをリポジトリとして使用します。 キャッシュ付きのパブリックリポジトリへのゲートウェイが設定されました。 単一のエントリポイントがあります。コーポレートMavenリポジトリです。 それ以前は、ライブラリ、リリース、デイリービルド、その他のパブリックリポジトリの3つ以上がありました。 すべての必要な承認。 各pom.xmlの3つの同様のリポジトリ、さらにsettings.xmlのアクセス設定でさえ、常に混乱を引き起こしました。



ベースのpom.xmlにのみリポジトリへのリンクを残そうとしました。 これは非常に現実的ですが、モジュールの最初のアセンブリ中に、Mavenはリポジトリからベースモジュールをロードする必要があり、その座標は不明です。 すべてが正常に動作した後、手動で行うことができます。 このアクションの不透明度により拒否されました。

反復4

Hudsonの継続的インテグレーションシステムで、すべての基本モジュールと設計モジュールのナイトリービルドをセットアップしました。 モジュールは完全に独立しているため、問題はありませんでした。 パブリックライブラリでもプロジェクトモジュールでも違いはありません。 Mavenベースのビルドは、SVNでコードが変更されるたびに実行され、成功したアーティファクトがNexusリポジトリに入ります。



時間が経つにつれて、タスクのモジュールのカスケードアセンブリ、および開発用アセンブリとテスト用アセンブリへの展開を構成しました。 展開は、かなり単純なantスクリプトを使用して実行されます。 Nexusから最新のモジュールアセンブリ（ 依存関係：get ）を抽出し、サーバーで解凍してアプリケーションサーバーを再起動します（スクリプト自体は記事の最後にあります）。

長所

• 各モジュールを個別に使用できます。
• すべての依存モジュールのバージョンを修正することにより、プロジェクトコード全体をコミットできます。
• 継続的な統合により、日常的な作業が不要になり、機能を生産的な環境と顧客に迅速に移行できます。
• モジュールバージョンのリリースは完全に制御され、非常に簡単です。
• これで、特定のモジュールを1つだけ使用して開発できます。 実際、いくつかのモジュールの一般的な展開は、コードの最終的な動作に影響を与える可能性があります。
• ハドソンのおかげで、誰がアセンブリを破ったのかを常に確認できます。
• プロジェクトを設定する必要はまったくなく、IDEはすべてを単独で行います。 アセンブリを開始するだけで十分です（mvnパッケージで十分です）。
• モジュールが依存するコードは常に明確です。 そして以前は、トランクは常にエラー、壊れたコミットなどを行っていました。

短所

• IDEにはすべてのモジュールに共通のプロジェクトがないため、一度に複数のモジュールを変更するには、各モジュールで個別に作業する必要があります。 モジュールは自給自足である必要があるため、これは確かにあまり便利ではありませんが、概念的に正しいです。
• メイン製品をリリースするときに、カスケードですべてのバージョンのコンポーネントをリリースすることはできません
• ...

ソリューションを開発します

このプロセスでは、アセンブリが編集されます。 「昔ながらの方法」をまだ組み立てている人のために、ナレッジベースのページが開かれ、そこにはモジュールの依存関係が含まれています。 この情報は、Homsonの個別のタスクとしてpom.xmlモジュールに基づいて毎晩更新されます（ DRYを忘れないでください）。



モジュールのアセンブリを高速化するために、アセンブリ中の不要な作業は除外されました。 たとえば、コアに依存するsoapモジュールを構築します。 コアコードは最終的なSOAPアセンブリになります。 次は、コアと石鹸に依存するプロジェクトです。 soapは個別には使用されないため、コアはアセンブリから除外され、プロジェクトに含まれます。 したがって、アセンブリを高速化します。 依存コアを含むSOAPを構築するために、必要に応じて開始されるコンテキストプロファイルが追加されました。



すべてのモジュールがpom.xmlで2回検出されることに気付くことができます。1つのレコードがコンパイル中に使用され、2番目のレコードはモジュールがデプロイメントで終了することを意味します。 pom.xml全体でモジュールのバージョンを置き換えないために、企業モジュールのすべてのバージョンは個別のプロパティに移動され、ファイルの先頭に配置されています。 これにより、別のバージョンに切り替えるときにエラーが発生する可能性が低くなります。







Mavenアーティファクトを操作するためのantスクリプト

おわりに

そのため、継続的な統合がプロジェクトに導入されました。 サーバーでコードを手動で更新する必要はなくなりました。 RSS経由で送信されるアセンブリの結果は常に表示されます。 アセンブリ監視の大画面はまだ設定されていません。



新しい開発者は、アセンブリのセットアップにあまり時間をかけません。 そしてこれは楽しいだけです。



コードバージョンのリリースが調整され、このプロセスはほぼ完全に自動化され、それほど時間はかかりません。 以前にリリースされたバージョンの保守がはるかに簡単になりました。



新しい開発は、日中は開発コンテキストに分類されます。つまり、顧客により早く届きます。 難しい統合エラーも発生し始めました。つまり、より迅速に修正できます。



更新：コメンテーターからの実装経験に関する有用な記事： http : //bazhenov.me/blog/2011/04/09/build.html