9

多くの共有コードを持ち、いくつかのバージョンを維持する必要がある製品がいくつかあります。

これを処理するために、多くの Eclipse プロジェクトを使用します。一部にはライブラリ jar が含まれており、一部には共有ソース コードが含まれています (いくつかのプロジェクトでは、多数の依存関係を持つ巨大なヒープを取得することを回避しながら、すべてをゼロからコンパイルして、ソースとバイナリが確実に実行されるようにします)。一貫性のある）。これらはすべてのプロジェクトを CVS から直接引き出して、完全に準備されたワークスペースを残すことができるため、projectSet.psf でそれらを管理します。Ant ビルドを直接行ったり、maven を使用したりすることはありません。

これらすべてのプロジェクトとそのさまざまなバージョンを継続的インテグレーション ツールに配置できるようにしたいと考えています。私は Hudson が好きですが、これは単なる好みの問題です。つまり、プロジェクトを自動的にチェックアウトして、新しいワークスペースを作成し、各プロジェクトのプロジェクト ファイルで説明されているようにソース フォルダーをコンパイルします。ハドソンはプロジェクトを構築するためのそのようなアプローチを提供していないので、私はこれにアプローチする最善の方法は何かを考えてきました。

アイデアは

  • projectSet.psf を理解し、cvs-checkout およびコンパイル タグにマップする ant プラグイン/コンバーターを検索または記述します。
  • Eclipse 内から build.xml ファイルを作成し、それらを使用します。これを試してみたところ、結果が冗長で絶対的な場所であることがわかりました。これは、ファイルを必要な場所に配置する自動ツールには適していません。
  • projectSet.psf を理解して構成を取得し、それを構築する Hudson プラグインを作成します。
  • 弾丸を噛んで、何かが壊れたときはいつでも CI 構成を手動で作成および更新するだけです-私はこれが好きではありません:)

他の人の経験について聞きたいので、これにどのようにアプローチするかを決めることができます.

編集: 別のオプションは、Eclipse プロジェクトやプロジェクト セットについてよく知っている CI を使用することです。私たちは宗教的ではありません。これは、自分ですべてを行う必要がなく、実行するだけの問題です。クルーズコントロールはおそらくより良いオプションでしょうか? その他？

編集: ant4eclipse には「チーム プロジェクト セット」機能があることがわかりました。 http://ant4eclipse.sourceforge.net/

編集: ant4eclipse および ant-contrib ant 拡張機能を使用して、Eclipse 3.5M6 の Runnable Jar 機能と同様の sjgned 実行可能 jar ファイルとして完全なワークスペースを構築しました。最初の空のワークスペースを作成し、ProjectSet を抽出するために、まだ Eclipse に依存しているので、それが次のハードルになります。

編集: デュアル構成、つまり、ハドソンが CVS (同じタグを持つ必要がある) から ProjectSet.pdf ファイルにリストされているのと同じモジュールのセットを抽出し、それらを隣り合わせに配置することになりました。次に、ant4eclipse は、メイン モジュールに埋め込まれた projectSet.psf ファイルとうまく連携します。警告: Hudson のモジュール リストは手動で更新する必要があります。その後、Hudson が以前よりも多くのプロジェクトがあることを「発見」できるように、手動でワークスペースをクリーンアップする必要があるようです。これで数か月は問題なく動作しましたが、ant ファイル内ですべてを動作させるのは非常に面倒でした。

編集: Hudson の CVS プロジェクトで ant4eclipse と Ctrl-A、プロジェクト パネルの Ctrl-C と Ctrl-V を使用した「チーム プロジェクトの使用」は、私たちが一緒に暮らすのに十分にうまく機能することが判明しました (成熟したプロジェクトの場合、これは変更されることはほとんどありません）。私は ant4eclipse 1.0 のリリースを待っています - http://www.ant4eclipse.org/、現在マイルストーン 2 にあります - 自家製の機能を ant4eclipse のものにどれだけ置き換えることができるかを確認します。

編集: ant4eclipse は M4 の 20100609 の時点であるため、http ://www.ant4eclipse.org/node?page=1 のスケジュールは多少ずれています。

編集: ant4eclipse アプローチを長期間使用した後の私の結論は、ビルド スクリプトが非常に危険になり、維持するのが難しいということです。また、Team ProjectSet 機能 (ant4eclipse がプロジェクトを見つけるために使用する) は、CVS ベースのリポジトリではうまく機能しますが、git に移行した後では機能しません (これはそれ自体が大きなことです)。新しいプロジェクトは、Jenkins で十分にサポートされているため、maven に基づいている可能性が最も高いでしょう。

4

3 に答える 3

3

問題を完全に理解しているかどうかはわかりませんが、根本的な問題は、多くのプロジェクトがあり、その一部が他のプロジェクトに依存していることにあるようです。依存関係ツリーの「リーフ」に近いプロジェクトの一部は、より「コア」なプロジェクトの「安定した」(または以前に「リリースされた」) バージョンを使用できる必要があります。

Hudson、ant、およびivyを使用して、この問題を正確に解決します。私はPragmatic Project Automationで Clark が示したパターンに従います(彼は依存関係の問題と解決策を示しておらず、hudson ではなく CruiseControl を使用しています)。

手書きの ant ビルド ファイルがあります (CruiseControl のルートであるため、"cc-build.xml" と呼びます)。参照。次に、各プロジェクトの開発者が提供する別の手書きの ant ビルド ファイル (build.xml) に制御を渡します。このプロジェクトは、従来のビルド手順 (コンパイル、パッケージ化など) を担当します。インストール可能なアーティファクト、単体テスト レポートなどを Hudson アーティファクト ディレクトリに吐き出す必要があります。私の経験では、(Eclipse または他の同様の IDE によって) 自動的に生成されたビルド ファイルは、CI シナリオで使用するのに十分な堅牢性を得るには決して近づきません。

さらに、アイビーを使用して独自の依存関係を解決します。Ivy は、正確に指定された依存バージョン (「バージョン 1.1 を使用」など) をサポートし、「ファジー バージョン」 (「バージョン 1.1+ を使用」または「統合ステータスの最新バージョンを使用」など) をサポートします。進行中の開発中の内部プロジェクトの「あいまいな」バージョンであり、リリースポイントに近づくと、依存関係のバージョンを「フリーズ」して、その下のものが動かなくなるようにします。

非リーフ プロジェクト (他のプロジェクトの依存関係にあるプロジェクト) も ivy を使用して、成果物を内部の ivy リポジトリに公開します。そのリポジトリは依存関係の過去のビルドをすべて保持するため、どのプロジェクトも常に他の以前のバージョンに依存できます。

最後に、Hudson の各プロジェクトは、依存プロジェクトのいずれかが正常にビルドされたときに再ビルドを引き起こすビルド トリガーを持つように構成されています。これにより、(おそらく) 新しい ivy 依存バージョンで再度ビルドされます。

これを起動して実行すると、自動化されたビルドの入力の一貫した自動化された「ラベル付け」または「タグ付け」が重要になることに注意してください。そうしないと、ビルド後の問題をトラブルシューティングするために、スズメバチの巣を調べて元のソースを見つけます。

私たちの環境でこのすべての設定を行うにはかなりの労力がかかりました (主に ivy リポジトリと ant ビルド ファイルの設定に) が、依存関係を手動で管理する際の頭痛の種がなくなり、トラブルシューティングの労力が減ったことで、何倍も元が取れました。

于 2009-02-02T16:31:00.017 に答える
1

CI ソリューションとして、Cruise Control (CC) と Hudson の両方を試しました。私たちは（会社として）ハドソンに決めました。しかし、「CC は Eclipse プロジェクトのビルドをサポートしていますか」という質問に対しては、私の知る限り、答えはノーです。CC は、さらに多くのさまざまなビルド ツールとソース管理システムをサポートしていますが、構成と使用が少し難しくなっています。ハドソンに関しては、構成と使用がより簡単です。CC と Hudson の両方で、そのままでは提供されないビルド サイクルの部分用にカスタム プラグインを開発しました。プラグイン開発に関しては、Maven を知っている/使用している場合は、Hudson も簡単です。ただし、Maven に慣れていない場合は、まず Maven の基本的な使用法を習得して、Hudson プラグインを適切に開発する必要があります。しかし、maven の基本的な使用法を理解すれば、プラグインの開発、テスト、さらにはデバッグさえ Hudson の方が簡単です。

あなたの特定の問題については、Eclipse プラグインを利用するソリューションも考えられます。たとえば、(構成可能な) フォルダーから psf ファイルを取得する独自の Eclipse プラグインを開発し、Eclipse 内部を使用してこれらの psf を処理することができます。つまり、psf ファイルを取得し、そのプロジェクト定義をチェックアウトして、これらのプロジェクトをコンパイルする既存の Eclipse ソース コードを使用できるということです。この Eclipse プラグインには設定ページ (Eclipse -> Window -> Preferences でアクセスできます) があり、psf ファイルの検索に使用するフォルダーを設定できます。Eclipse プラグインには、ユーザーの操作なしで psf 処理を開始する方法も必要です。このために、ipc を使用してプロセスをトリガーできます。つまり、Eclipse プラグインはポートをリッスンできます。このポートを介してプラグインに接続し、そのプロセスをトリガーする別の Java アプリケーションを作成できます。CI 部分に関しては、CC または Hudson のいずれかを使用でき、それらの外部プロセス実行サポートを使用できます。Windows を使用している場合は、プラグインがインストールされている Eclipse を最初に起動するバット ファイル (Linux の sh ファイルの場合) を作成できます。次に、Eclipse プラグインと通信してプロセスをトリガーする Java アプリケーションを起動します。CI ツールから、bat / sh ファイルを実行してプロセスをトリガーする必要があります。次に、Eclipse プラグインと通信してプロセスをトリガーする Java アプリケーションを起動します。CI ツールから、bat / sh ファイルを実行してプロセスをトリガーする必要があります。次に、Eclipse プラグインと通信してプロセスをトリガーする Java アプリケーションを起動します。CI ツールから、bat / sh ファイルを実行してプロセスをトリガーする必要があります。

于 2009-02-04T08:44:37.417 に答える